oss-security - please verify unusual x.509 constraints are handled

Follow @Openwall on Twitter for new release announcements and other news

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120627131318.GA30758@cmpxchg8b.com>
Date: Wed, 27 Jun 2012 15:13:18 +0200
From: Tavis Ormandy <taviso@...xchg8b.com>
To: oss-security@...ts.openwall.com
Subject: please verify unusual x.509 constraints are handled

List, just an FYI, I've noticed a Korean CA appears to always set the cA
bit in the X.509 basicContraints, then uses pathLenConstraint and
keyUsage bits to restrict the results.

I have no idea what crazy software they're using that generates these
certificates, but they're in the Microsoft trusted certificate
store on all Windows machines, and are therefore possibly (probably?)
cross-signed from other CAs. Maybe someone can check the EFF corpus if
there is interest.

While arguably the X.509 specifications permit this, I find it hard to
believe that these bits are checked consistently by all implementations.
AFAICT, GnuTLS does not check these constraints, but OpenSSL does.

I've produced an example from one of the weaker certificates, hopefully
you can use this to check whatever implementation you're using handles
this correctly. If you get an error about pathLen exceeded, or improper
usage, then it's probably good. If you get a message about revokation or
some other error about canonicalization*, then you might have a problem.

$ cat local-cert.pem Mengsk.pem sms.hallym.ac.kr.pem CA134040001.pem GPKIRootCA.pem | certtool -e
Certificate[0]: C=KR,O=Tanaris,CN=localhost
        Issued by: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk Certificate Authority
        Verifying against certificate[1].
        Verification output: Verified.

Certificate[1]: C=KR,ST=Koprulu Sector,O=Terran Dominion,CN=Mengsk Certificate Authority
        Issued by: C=KR,O=Government of Korea,OU=Group of Server,OU=,CN=sms.hallym.ac.kr
        Verifying against certificate[2].
        Verification output: Verified.

Certificate[2]: C=KR,O=Government of Korea,OU=Group of Server,OU=,CN=sms.hallym.ac.kr
        Issued by: C=KR,O=Government of Korea,OU=GPKI,CN=CA134040001
        Verifying against certificate[3].
        Verification output: Verified.

Microsoft asked them to revoke these certificates earlier this month,
but they publish CRL via ldap, so I don't know if these are really
visible.  Regardless, I think it's important to verify that
implementations handle these combinations of constraints.

Tavis.

* The problem with canonicalization is the subjectName/issuerName DN
  should be canonicalized, but this isnt always implemented. In this
  case the PrintableString doesnt match the UTF8String. If this is the
  only problem with the chain reported, then there is a bug.

-- 
-------------------------------------
taviso@...xchg8b.com | pgp encrypted mail preferred
-------------------------------------------------------

Download attachment "CA134040001.pem" of type "application/octet-stream" (1574 bytes)

Download attachment "GPKIRootCA.pem" of type "application/octet-stream" (1289 bytes)

Download attachment "local-cert.pem" of type "application/octet-stream" (4394 bytes)

Download attachment "Mengsk.pem" of type "application/octet-stream" (3648 bytes)

Download attachment "sms.hallym.ac.kr.pem" of type "application/octet-stream" (4684 bytes)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.