1. copyright IOActive, Inc. 2006, all rights
reserved.
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

2. Introduction
• Hi! I’m 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

3. 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

4. The Two Schools Of Thought
• “We can make passwords work…barely”
– 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!”

6. 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 90’s, when X.509 was
developed. If we’re to get past passwords, we
have to start putting that knowledge to use – with
DNSSEC.

7. 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 naïve
– Similar to building cities without roads or
highways in the middle of a forest – “But it will
have great mass transit” doesn’t make up for
that
• However: What we are doing now, the way we are
doing it, is not working. Lets talk about why.

8. Warning
• The first fifteen minutes of this talk aren’t
that l33t, so as a preview…

9. DEFCON
• Yes, that’s a real certificate
• No, I’m 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

10. 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 that’s in the photo, and it’s 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

11. 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!

12. 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 what’s called a “PKCS#10
Certificate Signing Request”, or CSR

13. 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 it’s
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

14. I’m Oversimplifying, Aren’t I?
• What I just described is called Domain Validation
– there are many CA’s that offer much more
stringent validation
– DUNS lookups
– Phone calls
– Lawyers who show up at the door and take a
blood sample
• Just kidding
• Doesn’t matter, because of flaw #1…

15. X.509 Cannot Exclude (without great
pain)
• There are dozens and dozens of CA’s 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 doesn’t
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 CA’s out there. X.509 does not allow them to
provide a more secure solution than their competitors
– Technical term: “Race to the bottom”

16. 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 – won’t 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 TLD’s had a real problem with
malware. The registry behind that TLD
recognized the problem and cleaned it up.

17. 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

18. X.509 Exclusion Is Painful
• Possible to exclude “untrusted CA’s”
– Can run a private CA
– Very expensive
– Very difficult to maintain
– What happens when you need to interoperate with other
individuals behind other private CA’s?
• Federal Bridge CA
• The people who made this work deserve a medal
• This problem shouldn’t require awarding medals the
few times its actually solved

19. 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.

20. 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 can’t buy this from anyone
• Can also fix with wildcards, which aren’t a great idea either
– Every node can read traffic from every other node?!

21. 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

22. 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
– Can’t do this securely without Name Constraints
– Solution: Do this anyway
• Forget hacking CA’s. Prove you’re 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
• It’s not that the companies don’t take security seriously.
It’s that the technology doesn’t allow them to offer
anything better.

23. 2008: Not A Good Year For X.509
CA’s
• Mike Zusman: Bypassed Thawte’s security
checks by claiming www.live.com was the “name
of an internal server” and thus not subject to
validation at all
– Also bypassed Startcom’s checks via a web
interface hack
• Me: Bypassed almost all CA’s 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

24. 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 it’s too difficult to find
another file with the same hash
– Second: Sign the hash with the CA’s private key
• Problem: RapidSSL was using MD5 as its hashing algorithm
– MD5 is not secure
– We’ve known this since 1996
– We’re still using it 

25. 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

26. There’s More Where That Came
From
• X.509 is remarkably fragile
• At pretty much every depth it’s 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

27. Shouldn’t 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
• There’s nothing signing with MD2RSA
anymore, so everything should be OK,
right?

28. The Final Destination Theory of
Cryptographic Vulnerabilities
• Cryptographic vulnerabilities tend to be subtle, and
telegraphed years, sometimes decades in
advance
• We don’t know how they’ll burn us
• We don’t know when they’ll burn us
• We do know we’re 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

29. So it turns out that one of Verisign’s 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

30. 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 we’ll
sign them…it’s harmless, right?
• But why sign with MD2?

31. It was the 90’s.
• 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.

32. 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.

33. Attack #1: VeriSign’s 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 root’s signature across its own MD2 hash
– The signature was the root’s self-signature (useless
cruft), but now it’s actually doing something (validating a
malicious intermediate)
– Does depend on there actually being a MD2 preimage
attack

34. MD2 Is The Only Production Hashing
Algorithm To Suffer From Preimage
Threat
• 2004: Frédéric Muller, 2^104 complexity
• 2005: Lars Knudsen, 2^97 complexity
• 2008: Søren S. Thomsen, 2^73 complexity
• Largest known computational efforts, 2^63
complexity

35. I Can Haz Trend?
MD2 Cracking Complexity
0
20
40
60
80
100
120
2004 2005 2006 2007 2008
Date
Complexity
Theory
Warning Line

36. 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?

37. 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

38. 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 

39. And Blow Up It Will: Client
Authentication Bypass

40. 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 doesn’t matter if
your CA runs you through the wringer, if some other CA can
make the same assertions
– Check CTL’s!

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

42. This Wasn’t Just Verisign’s 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 2000’s – and as Stevens/Sotirov
showed, if you can corrupt a server cert, you can create an
Intermediate with absolute power
– Doesn’t matter that they’ve all expired; you can change
the date
– DOES matter that they’re almost all off the Internet.
– Only one left.

43. 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

44. Doesn’t 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 Sassaman’s 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 wouldn’t see (for
example) a flood of requests into existing CA’s

45. Manipulating Existing CA’s: HOWTO
• MD2 attack has no link to present-day CA
operations
– Verisign hasn’t been signing with MD2
for years
• Is it possible to bypass protections in
present-day CA operations?

46. How We Got Here
• Meredith L. Patterson: “I’m 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)

47. 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

48. 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

49. “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

50. “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

51. “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

52. Problem…

53. 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
CN’s
– Multiple CN’s actually something of an open problem

54. Attack 2A: Multiple Common Names in
one X.509 Name are handled differently
by different API’s.
• 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

55. 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

56. “Usually?”
• Possible to use OpenSSL API to return all CN’s 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 */
}

57. 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

58. 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 – they’re only
accepted two labels in (*.xxx.yyy)
• Three CN’s in one PKCS#10 Request
– CN=www.attacker.com // for OpenSSL
– CN=www.bank.com // for IE
– CN=* // For Netscape

59. 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 there’s random
custom code all over the place out there

60. Warning: Also a channel for SQL
Injection
• Apparently, XKCD’s 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;--'
– : }

61. 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?

62. ASN.1 OIDs
• ASN.1 BER (Basic Encoding Rules) is a TLV (Tag-
Length-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 there’s another digit coming

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

64. 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

65. Subattack 1: Leading 0’s
• 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 we’re using it semantically now
• Suppose we added “2.5.4.03 == www.bank.com”
to an X.509 Subject Name. What would be seen?

66. Leading 0’s 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

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

68. Leading 0’s v. IE: We have CN!

69. 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

70. 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

71. Netscape: Overflows, but not
exploitably

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

73. That Being Said
• Realistically, most CA’s extract a CN and
throw away the rest
– Good!
• Is there anything malicious we could get
into the CN?
– Can’t throw that out, that’s what we’re
actually validating

74. So What’s 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)

75. Some Extra Special Magic We Can
Do Because It’s 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

76. Code Snippet
• while(p != q) { // DK: Stop reading once we’re 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 – doesn’t write any memory after
overflowing, so it eventually just reads off into unallocated
space
– Fixed anyway, quietly
• There’s some other fun stuff with strings, I’ll talk about it later

77. 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.orgx00www.ohexohoh.com
• “This is part of the ohexohoh.com domain!”
• Domain Validation thus goes to
ohexohoh.com

78. WIN (again)
• Yes, that’s a real
certificate
• No, I’m not going to
tell you who issued it
• Yes, I could have just
as easily gotten a cert
for *00.doxpara.com

79. Null In CN Being Fixed In Browsers
as CVE-2009-2408
• Genuinely worried about this bug
– Most CA’s 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”

80. So What Am I Suggesting
• Move everyone to DNSSEC and get rid of the CA’s?
– No. The Certificate Authorities are actually really useful –
they’re 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 that’s 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”)

81. 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 couldn’t deploy EV without
disabling all DV SSL includes, nobody
would be running EV besides Paypal

82. 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 CA’s 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

83. 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 DNS’s 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 CA’s to perform their semantic assertions

84. 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
CA’s in CAB Forum
– Everybody has been very responsive
– People working this hard deserve a better base
on which to build