You are on page 1of 84

Black Ops of PKI

Or: When I Hear The Word Certificate, I Reach For My Gun

Dan Kaminsky Director of Penetration Testing IOActive, Inc. Len Sassaman & Meredith L. Patterson K. U. Leuven
copyright IOActive, Inc. 2006, all rights reserved.

Introduction
Hi! Im Dan Kaminsky! This is my 10th talk here at Black Hat! Focus of most of my talks has been on foundational elements of Internet Security SSH TCP/IP DNS Web Browser Same Origin Policy DNS Visual Pattern Recognition In Binary Data DNS SSL

The Crisis Of Authentication


Vulnerabilities / 0-day get all the press, but According to Verizon Business, 60% of actual real world data losses are traced not to software vulnerabilities, but to failed authentication technology No passwords Bad passwords Default passwords Stolen passwords My passwords Passwords are used because they scale well, one at a time Passwords fail because they fail to scale, as a group

The Two Schools Of Thought


We can make passwords workbarely Machine generated Rapidly cycled l33tpaZ$ As Schneier has noted, still trivially vulnerable to keysniffing We can eliminate passwords entirely, if only we can find a way to get the human out of the memory business PKI with X.509 was supposed to do this If only we cared enough, we could stop using passwords. Smartcards for everyone!

Reality Check
Business has cared enough about PKI to invest hundreds of millions of dollars in it over the last ten years Something is not working I believe that something is X.509, the technology at the core of present-day PKI We have learned so much about real-world security since the 90s, when X.509 was developed. If were to get past passwords, we have to start putting that knowledge to use with DNSSEC.

Rethinking The Foundations Of Internet Security


There are those who think we should create a New Internet, which would just not have any of these security problems This is hopeful, but nave Similar to building cities without roads or highways in the middle of a forest But it will have great mass transit doesnt make up for that However: What we are doing now, the way we are doing it, is not working. Lets talk about why.

Warning
The first fifteen minutes of this talk arent that l33t, so as a preview

DEFCON
Yes, thats a real certificate
No, Im not going to tell you who issued it Jeff Moss knows

Alex Sotirov knows


Yes, I could have just as easily gotten a cert for *\00.doxpara.com

Intro to X.509 (the really, REALLY simple version)

X.509 is the identity system behind PKI Used for SSL, IPSec, pretty much everything except SSH X.509 allows creation of systems where public keys and subject names of individuals are signed by certificate authorities trusted by many people, such that if you have a specific private key, other people may validate your identity via its matching certificate Private Key: Your face Public Key: Your passport photo Subject Name: Your name Certificate Authority: The country you live in Certificate: Passport Validation: If you have the face thats in the photo, and its on a card issued by your country, then you have the name of the person on the passport. X.509 is just the digital version of this

X.509 In The Real World: SSL


X.509 has only one real success story: SSL
This is the technology used to secure HTTPS, i.e. the web

Early on, SSL = Can Provide Credit Card #


Probably the single best thing that ever happened to consumer crypto Only about ~1M SSL endpoints People are arguing about whether cloud applications require SSL!

Walkthrough: Acquiring An X.509 Certificate For A Website [0]


1) Register a name in DNS, providing an email address as the canonical user behind the domain name 2) Generate a public and private keypair. Face, and Passport Photo 3) Provide the public key to a Certificate Authority, along with the name of the website we registered in DNS This is done with whats called a PKCS#10 Certificate Signing Request, or CSR

Walkthrough: Acquiring An X.509 Certificate For A Website [1]


4) The Certificate Authority, or CA, asks DNS for the email address of the user who administers that website, and then emails the user making sure its OK to bind that website to that public key Heh, is this passport photo actually you? Technically, asks the WHOIS database 5) Click the link provided in the email to the canonical address. 6) Receive a certificate, which can be loaded into your web server to prove it is the real www.whatever.com

Im Oversimplifying, Arent I?
What I just described is called Domain Validation there are many CAs that offer much more stringent validation
DUNS lookups Phone calls Lawyers who show up at the door and take a blood sample Just kidding Doesnt matter, because of flaw #1

X.509 Cannot Exclude (without great pain)


There are dozens and dozens of CAs out there trusted by everyone Every CA can issue certificates for every single name Zimbabwe can issue American passports Even if your CA runs you through the wringer, that doesnt mean every other one will Security of the whole is equal to security of the weakest link Anything more is, unfortunately, security theatre There are many very good, very responsible, very responsive CAs out there. X.509 does not allow them to provide a more secure solution than their competitors Technical term: Race to the bottom

DNS Is Very Good At Excluding


DNS has three layers The root: There is only one root. Classic quote: The CA system is only as secure as the money they refuse to take. The root as is, anyway wont take your money. Root is part of State system. The Registries: Verisign has exclusive control over .com. Afilias has exclusive control over .org. One of the TLDs had a real problem with malware. The registry behind that TLD recognized the problem and cleaned it up.

DNS Is Very Good At Excluding [2]


The Registrars: I have registered www.doxpara.com through Network Solutions. Network Solutions has exclusive control over my domain. If they screw up, I can move that domain to eNom, who will then have exclusive control.
When my domain is controlled by eNom, no other registrar can mess it up I can manage my risk with DNS, I cannot manage my risk with X.509 There are elite registrars that are able to provide a higher level of security MarkMonitor

X.509 Exclusion Is Painful


Possible to exclude untrusted CAs Can run a private CA Very expensive Very difficult to maintain What happens when you need to interoperate with other individuals behind other private CAs? Federal Bridge CA The people who made this work deserve a medal This problem shouldnt require awarding medals the few times its actually solved

Interop: Not actually optional


Theory: You only need to authenticate to your own organization how often is your house key used in other homes? Reality: Cross-organizational authentication is the rule and not the exception Partnerships with other companies Interactions with other groups There are many organizations in each company Software As A Service / Cloud Services Passwords interoperate well.

X.509 Cannot Delegate (without great pain)


Each time I need a new certificate for a node in my organization, I must interact with an external CA, to get a certificate for that particular node Expensive Operationally inconvenient Potential information disclosure issues Integrates very poorly with devices Almost all of which end up with self-signed certificates Name Constraints were supposed to fix that You were supposed to be able to get a certificate that allowed you to sign for *.doxpara.com or whatnot Very weak support in field, so you cant buy this from anyone Can also fix with wildcards, which arent a great idea either Every node can read traffic from every other node?!

DNS Delegates Very Well


The root delegates to Verisign for .com
.com delegates to my servers for doxpara.com I add and remove servers from doxpara.com all I want, never talking to the root, Verisign, or Network Solutions

X.509 Delegation Is Painful


Serious demand for being able to issue a certificate using your Private CA, that is valid outside your own organization Cant do this securely without Name Constraints Solution: Do this anyway Forget hacking CAs. Prove youre a business of some size, and sign an insurance policy, and you get an intermediate certificate that allows you to sign for any name on the planet At least two companies offer this, probably more No way of knowing how many intermediates are out there Its not that the companies dont take security seriously. Its that the technology doesnt allow them to offer anything better.

2008: Not A Good Year For X.509 CAs


Mike Zusman: Bypassed Thawtes security checks by claiming www.live.com was the name of an internal server and thus not subject to validation at all Also bypassed Startcoms checks via a web interface hack Me: Bypassed almost all CAs validation mechanisms by hijacking the DNS query used for the Domain Validation email Pilosof: Showed that any node with BGP access could silently sniff SSL validation emails as well

The Big SSL Hack Of 2008: Stevens and Sotirov v. MD5 [0]
When a Certificate Authority (country) deems you worthy of a Certificate (passport), it signs (creates a passport with a hologram) your public key (your photo) Signing requires two steps First: Securely Hash the certificate, summarizing it down to a small number of bits A hash is considered secure if its too difficult to find another file with the same hash Second: Sign the hash with the CAs private key Problem: RapidSSL was using MD5 as its hashing algorithm MD5 is not secure Weve known this since 1996 Were still using it

The Big SSL Hack Of 2008: Stevens and Sotirov v. MD5 [1]
Stevens (with Lenstra) contribution: Chosen Prefix Collision Attacks Given two different beginnings, create a blob that when appended gives them the same hash Hash(aabbcc + X) == Hash(xxyyzz + X) Attack CA signs a certificate that looks innocent Attacker shifts out the innocent content, replaces with the intermediate certificate that can sign for anything Hash(innocent + X) == Hash(intermediate + X) so signature from one is transferable to the other Required some really interesting timing work to manage the CA serial number, which had to be accounted for

Theres More Where That Came From


X.509 is remarkably fragile At pretty much every depth its examined, ambiguities and risks are found Consider hashing functions MD5 is not the only insecure hash function supported by validators MD2 is also supported Predecessor function to MD5, known now to be even less secure than it If a certificate is signed with MD2RSA, everything (except GnuTLS) will accept it

Shouldnt This Not Matter?


Stevens and Sotirov required a CA to actively sign specially formed blobs with MD5RSA, in order to exploit the insecurity of MD5
Theres nothing signing with MD2RSA anymore, so everything should be OK, right?

The Final Destination Theory of Cryptographic Vulnerabilities


Cryptographic vulnerabilities tend to be subtle, and telegraphed years, sometimes decades in advance
We dont know how theyll burn us We dont know when theyll burn us We do know were going to get burned It will probably be epic The relationship to the Final Destination series of movies is left as an exercise to the reader

So it turns out that one of Verisigns core root certificates is self-signed with MD2
$ openssl x509 -in VeriSign.cer -inform der -text Certificate: Data: Version: 1 (0x0) Serial Number: 70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf Signature Algorithm: md2WithRSAEncryption

Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority


Validity

Not Before: Jan 29 00:00:00 1996 GMT Not After : Aug 1 23:59:59 2028 GMT Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (1024 bit) Modulus (1024 bit): Exponent: 65537 (0x10001)

Signature Algorithm: md2WithRSAEncryption

The Mystery That Is Self-Signatures


In normal X.509, your public key and subject name are signed by the Certificate Authority In self-signed X.509, you sign your own public key and subject name with your own private key. Why? Assertion: I am me, says I. This is a meaningless assertion! Presumably there only for consistency X.509 Certificates are supposed to be signed, so well sign themits harmless, right? But why sign with MD2?

It was the 90s.


Peter Guttmann: VeriSign were, as of March 1998, still issuing certificates with an MD2 hash, despite the fact that this algorithm has been deprecated for some time. This may be because they have hardware (BBN SafeKeypers) which can only generate the older type of hash.
RFC 2313 (March 1998): MD2, the slowest of the three, has the most conservative design. No attacks on MD2 have been published.

On The Subject Of Insecure Hashes


There are many ways a hash can fail Collision: Create two things with the same hash What Xiaoyun Wang did to MD5, caused my MD5 To Be Considered Harmful Someday paper Chosen-Prefix Collision: Create something that, when appended to two things with different hashes, causes them to have the same hash What Stevens and Sotirov did to MD5, caused their MD5 To Be Considered Harmful Today paper Preimage: Given a hash, create something new with that hash SHA-1 has no problems here. MD5 has no problems here. MD4 has no problems here. MD2 has problems here.

Attack #1: VeriSigns MD2 Root Can Be Exploited By Creating A Malicious Intermediate With The Same MD2 Hash As Its Parent and Transferring The Signature From The Root To The Malicious Intermediate

1) Generate a new Intermediate certificate, allowing any name to be signed for, claiming to be signed by the Verisign root 2) Use a preimage attack to give this Intermediate certificate the same MD2 hash as the root certificate 3) Transfer the self-signature from the parent to the Intermediate 4) The Intermediate will now appear to be signed by the root, since it has the roots signature across its own MD2 hash The signature was the roots self-signature (useless cruft), but now its actually doing something (validating a malicious intermediate) Does depend on there actually being a MD2 preimage attack

MD2 Is The Only Production Hashing Algorithm To Suffer From Preimage Threat

2004: Frdric Muller, 2^104 complexity


2005: Lars Knudsen, 2^97 complexity 2008: Sren S. Thomsen, 2^73 complexity Largest known computational efforts, 2^63 complexity

I Can Haz Trend?


MD2 Cracking Complexity
120

100

80

Complexity

60

Theory Warning Line

40

20

0 2004 2005 2006 Date 2007 2008

Two Options
1) We can wait until the situation is absolutely intolerable
2) We can run faster than the bear We have no major runtime dependency on MD2 signatures. Nothing has needed it for validation for years. How about we fix something in Crypto before it blows up in our face?

Fixes for CVE-2009-2409 [0]


OpenSSL 1.0beta3 disables MD2 0.9.8cvs disables MD2 0.9.8 release in August disables MD2 NSS (core of Firefox) NSS 3.12.3 has MD2 disabled already Used in Firefox 3.5 Firefox 3.0 series getting fixed soon RedHat Already shipped new NSS to RHEL5 RHEL4 and RHEL3 shipping new NSS after talk

Fixes for CVE-2009-2409 [1]


Verisign Reissuing Class 3 Certificate as SHA-1 Nothing is actually using the self-signature, remember? Opera Waiting on Verisign Apple Testing fixes Microsoft Testing fixes Google Android to have MD2 disabled in August/September Windows version of Chrome waiting on Microsoft CryptoAPI GnuTLS Disabled MD2 a while ago

And Blow Up It Will: Client Authentication Bypass

IIS adds Verisign Class 3 Root to CTL (Certificate Trust List) because of EKU
CTL is public knowledge, preauth you can ask a server what roots it accepts to assert arbitrary client names
/C=US/O=First Data Digital Certificates Inc./CN=First Data Digr Ctal Certificates Inc. Certification A uthority /C=ZA/ST=Western Cape/L=Cape Town/O=Thawte Consulting/OU=Certification Services Division/CN=Thawte Personal Basic CA/emailAddress=personal-basic@thawte.com

/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority


/C=US/O=VeriSign, Inc./OU=Class 2 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 1 Public Primary Certification Authority /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network /C=HU/L=Budapest/O=NetLock Halozatbiztonsagi Kft./OU=Tanusitvanykiadok/CN=NetLock Uzleti (Class B) Tanusitvanykiado

Remember what I said about Exclusion: It doesnt matter if your CA runs you through the wringer, if some other CA can make the same assertions Check CTLs!

The MD5 Root Stevens and Sotirov did not have Client Auth EKU

This Wasnt Just Verisigns Problem


VeriSign was the one company to put MD2 into one of their root certs But many companies were signing web server certs with MD2RSA up into the early 2000s and as Stevens/Sotirov showed, if you can corrupt a server cert, you can create an Intermediate with absolute power Doesnt matter that theyve all expired; you can change the date DOES matter that theyre almost all off the Internet. Only one left.

FINAL DESTINATION
Issuer: C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com
Subject: C=US, ST=Tennessee, L=Nashville, O=Rubicon, Inc., OU=Rubicon Research, CN=*.rubic.com

Algorithm: md2WithRSAEncryption

Doesnt This Need To Be Fixed Immediately?


Relax. It needs to be addressed, but not in a panic. Went to talk to Bart Preneel of University of Leuven Len Sassamans advisor Response (paraphased): There is not likely to be a public preimage attack of less than 2^63 complexity within the next six months, even with this knowledge disbursed. Commented specifically that memory requirements must also be addressed As such, not pushing the emergency sync button (makes things much easier) Friendly request: Please try not to publicly break MD2 in the next six months, Xiaoyun Wang That being said, this is an offline attack, so we wouldnt see (for example) a flood of requests into existing CAs

Manipulating Existing CAs: HOWTO

MD2 attack has no link to present-day CA operations


Verisign hasnt been signing with MD2 for years Is it possible to bypass protections in present-day CA operations?

How We Got Here


Meredith L. Patterson: Im going to go home and figure out the precise grammar of a certificate, and see just what I can put in there! This is the quote that spawned this entire talk There are two sorts of parsing vulnerabilities Those that cause the system to misuse memory (traditional exploits) Those that cause the system to parse a different message than was intended (semantic exploits)

Semantics and Language Theoretic Security


A CA and a Browser talk to each other via certificates CA: Browser, I tell you that this public key is linked to that subject name Browser: CA, I hear that this public key is linked to this subject name. How do we know that what the CA says is what the browser hears? Language Theoretic Security is the field that attempts to explore this sort of semantic question Describes how to build parsers that will always parse the same message in the same way, using formal methods Was first used in 2005 as the theory behind Dejector (grammatical SQL injection defense) Formalized by Patterson and Sassaman X.509 was developed long before Dejector / LTS It shows

The CA Pipeline
1) User generates public and private key 2) User submits X.509 Subject Name with public key in a PKCS#10 CSR Subject name contains many things Country, State, City, Organization, Organizational Unit Only element browsers care about: CN, or Common Name 3) If CA approves of Common Name, can do one of two things (More) Secure: Generate a certificate with the validated components of the X.509 Subject Name (just the CN, validated through DNS) Scrubbing Easy: Sign the certificate with the X.509 Subject Name intact

Easy Ways To Use OpenSSL To Build A CA [0]

Sign, and then make sure you approve of the CN before sending
$ openssl x509 -req -in request.pem -CA ca.pem -CAkey ca.key -CAserial ca.srl -out modded.crt Signature ok subject=/O=Foo Inc./CN=www.foo.com Getting CA Private Key

Easy Ways To Use OpenSSL To Build A CA [1]

Dump the PKCS#10 request to text and parse it:


$ openssl req -in request.pem text Certificate Request: Data: Version: 0 (0x0) Subject: O=Foo Inc., CN=www.foo.com

Easy Ways To Use OpenSSL To Build A CA [2]


Dump the generated certificate, then audit the Subject $ openssl x509 -in modded.crt text Certificate: Data: Version: 1 (0x0) Serial Number: 127 (0x7f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=AU, ST=Some-State, O=Internet Widgits Pty Ltd Validity Not Before: Feb 8 23:56:39 2009 GMT Not After : Mar 10 23:56:39 2009 GMT Subject: O=Foo Inc., CN=www.foo.com

Problem

Text Injection Really Easy In This Model


$ openssl x509 -req -in request.pem -CA ca.pem -CAkey ca.key -CAserial ca.srl -out modded.crt Signature ok subject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/CN=www.bank.com Getting CA Private Key OpenSSL Command Line has modes to deal with text injection nameopt option changes output to RFC2233 or Oneline or Multiline, all of which have better filters None of which are on by default Exploitability depends on how text auditor handles multiple CNs Multiple CNs actually something of an open problem

Attack 2A: Multiple Common Names in one X.509 Name are handled differently by different APIs.

An X.509 Subject Name contains multiple entities, only one of which really matters
The Common Name What happens if there are multiple Common Names? It completely depends on the implementation, and even the software using the implementation

So Many Choices
OpenSSL: First CN wins (usually)
CryptoAPI / IE: All-Inclusive any CN in the Certificate is acceptable NSS / Firefox: Last CN wins RFC: Most Specific (which is not defined in RFC) FAIL

Usually?
Possible to use OpenSSL API to return all CNs in Certificate
int loc; X509_NAME_ENTRY *e loc = -1; for (;;) { lastpos = X509_NAME_get_index_by_NID(nm, NID_commonName, lastpos); if (lastpos == -1) break; e = X509_NAME_get_entry(nm, lastpos); /* Do something with e */ }

But Nobody Does It


Most common pattern: X509_NAME_get_text_by_NID (subj, NID_commonName, data, 1024); return data; Seen in Claws, Open1x, Wget, Bacula, Neon, OpenLDAP A CA based on X509_NAME_get_text_by_NID would only see/validate the first CN

So What Would You Do?


Wildcard policy
Netscape has an unlimited wildcard policy if you can get a cert for *, you win

IE has a chicken wildcard policy theyre only accepted two labels in (*.xxx.yyy)
Three CNs in one PKCS#10 Request CN=www.attacker.com // for OpenSSL CN=www.bank.com // for IE CN=* // For Netscape

But What Is A CN, Anyway?


X.509 is written to ASN.1, something of a precursor to XML Designed to be very fast to parse Actually very fast to crash under fuzzing In 2002, the PROTOS project fuzzed SNMP and pretty much destroyed every router on the planet Every CA has an ASN.1 listener via PKCS#10 Should be based on a standard stack, hardened after 2002, but theres random custom code all over the place out there

Warning: Also a channel for SQL Injection


Apparently, XKCDs Little Bobby Tables caused some people to realize this might show up in a certificate (courtesy of Peter Guttmann): 125 40: SET { 127 38: SEQUENCE { 129 3: OBJECT IDENTIFIER commonName (2 5 4 3) 134 31: TeletexString 'Bob';DROP TABLE certificates;--' : }

Names and Numbers


In ASN.1, Common Name is not expressed by text, but by an Object Identifer or OID 2.5.4.3 is the OID for Common Name
How is this encoded?

ASN.1 OIDs
ASN.1 BER (Basic Encoding Rules) is a TLV (TagLength-Value) file format
OIDs Tagged 0x06 have multiple numbers in a row, which may be larger than an individual byte Numbers are encoded in Base 128 if the high bit is set(>0x80) then the next number is part of this subdigit 06 = six 86 = six, and theres another digit coming

Simple OID
2.5.4.3 (Common Name)
T=06 (Object Identifier) L=03 (Length==3) V= 55: 2.5 // Dont ask, really stupid compression 04: .4 03: .3

More Complex OID


RSA Encryption ( 1.2.840.113549.1.1.1 ) T=06 (Object Identifier) L=09 (Length==9) V= 2A: 1.2 86 48: (6 * 128) + 72 = .840 86 F7 0D: (6 * 128 * 128) + (119 * 128) + 13 = .113549 01: .1 01: .1 01: .1 Or, in full: 06 09 2A 86 48 86 F7 0D 01 01

Subattack 1: Leading 0s
T=06 (Object Identifier) L=03 (Length==4) V= 55: 2.5 04: .4 80 03: (0 * 128) + 3 == .3 This has been seen for a couple of LDAP attacks, but were using it semantically now Suppose we added 2.5.4.03 == www.bank.com to an X.509 Subject Name. What would be seen?

Leading 0s v. OpenSSL: Parses to 2.5.4.3, but not CN


$ openssl req -in test.der -inform der -text Certificate Request: Data: Version: 0 (0x0) Subject: O=Badguy Inc, CN=www.badguy.com, OU=Hacking Division/2.5.4.3=www.bank.com $ openssl x509 -req -in modded.pem -CA ca.pem -CAkey ca.key -CAserial ca.srl -out modded.crt Signature ok subject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/2.5.4.3=www.bank.com Getting CA Private Key

Leading 0s v. NSS: Parses to 2.5.4.3, but not CN

Leading 0s v. IE: We have CN!

Subattack 2: Semantic Integer Overflow


One of the most common vulnerabilities in software the Integer Overflow
Programmers forget that if you add too much to a hardware counter, it loops back to zero We have an algorithm that multiplies and adds What if we make it do this past 2^64? 2.5.4.2^64+3 06 0D 55 04 82 80 80 80 80 80 80 80 80 80 03

OpenSSL: Not fooled


OpenSSL has a bignum library it simply cannot overflow
$ openssl x509 -req -in modded.pem -CA ca.pem CAkey ca.key -CAserial ca.srl -out modded.crt Signature ok subject=/O=Badguy Inc/CN=www.badguy.com/OU=Hacking Division/2.5.4.2361183241434822606851=www.b ank.com Getting CA Private Key

Netscape: Overflows, but not exploitably

IE: 2.5.4.2^64+3 == 2.5.4.3 == CN

That Being Said


Realistically, most CAs extract a CN and throw away the rest
Good! Is there anything malicious we could get into the CN? Cant throw that out, thats what were actually validating

So Whats In A Common Name Anyway?


Object Identifier: 2.5.4.3
T: 06 (OID) L: 03 (Length==3 V: 55 (2.5) 04 (.4) 03 (.3)

Printable String: www.doxpara.com


T: 13 (Printable String) L: 0F (Length==15) V: 77 77 77 2E 64 6F 78 70 61 72 61 2E 63 6F (www.doxpara.com)

Some Extra Special Magic We Can Do Because Its ASN.1

ASN.1 has ~13 different string types


Interesting: BMPString (2-byte Unicode, Fixed Length), UniversalString (4-byte Unicode, Fixed Length) Why Interesting? Trivial Read AV in OpenSSL PKCS#10 Parser

Code Snippet
while(p != q) { // DK: Stop reading once were at the end of the string ... case 4: // DK: advance four bytes, even if this extends past the end of the string c = ((unsigned long)*p++) << 24; c |= ((unsigned long)*p++) << 16; c |= ((unsigned long)*p++) << 8; c |= break; Alas, not exploitable doesnt write any memory after overflowing, so it eventually just reads off into unallocated space Fixed anyway, quietly Theres some other fun stuff with strings, Ill talk about it later

Fun With Printable Strings


There are two ways of ending a string of text With an explicit length field (ASN.1) With the 0x00 Null Terminator (C) What happens when you put 0x00 in the middle of a CN? OpenSSL: CN=www.defcon.org\x00www.ohexohoh.com This is part of the ohexohoh.com domain! Domain Validation thus goes to ohexohoh.com

WIN (again)
Yes, thats a real certificate
No, Im not going to tell you who issued it Yes, I could have just as easily gotten a cert for *\00.doxpara.com

Null In CN Being Fixed In Browsers as CVE-2009-2408


Genuinely worried about this bug
Most CAs should be clean, but we really want this client side

NSS 3.2.13 already contains fix, thus Firefox 3.5 is covered


Firefix 3.0 will be moved to NSS 3.2.13 soon Opera should also be covered IE / Safari testing

So What Am I Suggesting
Move everyone to DNSSEC and get rid of the CAs? No. The Certificate Authorities are actually really useful theyre just doing the best they can with a really fragile technology They are the only entities with sufficient local knowledge to be able to handle Semantic Name Collisions like www.bank-of-america.com If you think thats easy, imagine doing it for banks in Turkey and India and China, and not in English DNS does not and cannot provide this service Yes, people keep asking Extended Validation is the mechanism, built via X.509 Extensions, by which special CA knowledge is bubbled up to the user (via Green Bar)

On EV
Extended Validation has gotten some noise lately
If somebody has the DV version of your certificate, they can hijack the EV version of your site This is by design If you couldnt deploy EV without disabling all DV SSL includes, nobody would be running EV besides Paypal

Surprise?
People are unusually surprised by this, even though Collin Jackson and Adam Barth discussed it two years ago and it was in my slide deck last year Some CAs got out of sync with browser makers, told people EV solved the DV problem Mike Zusman and Alexander Sotirov have some really cool demos of exploiting the DV/EV bridge EV only handles semantic collisions and it does it well

What We Do
We get the DNS root signed so DNSSEC development can start in earnest Server work to get hosting stable Client work to get end-to-end trust We use DNSSEC to bootstrap cross-organizational trust for most other protocols SSH, IPSec, PGP, SSL Put the hash of the cert in DNS Since DNSSEC inherits DNSs exclusivity, the existence of the hash of an EV cert in DNSSEC will exclude any corrupt DV cert This is how you end up defending EV from DV, while still allowing CAs to perform their semantic assertions

Summary
X.509 is Messy Operationally, lack of segregation and delegation makes it really expensive to use, forces really painful decisions Technically, the technology is oddly fragile Organizations are doing the best they can Browser manufacturers work very closely with CAs in CAB Forum Everybody has been very responsive People working this hard deserve a better base on which to build