Comodogate part 2

Updated:

Had a conversation with Dan Kaminsky via twitter (@dakami) this afternoon, and after much back and forth, we can assert the following:

Either the EFF's statement:

" One cert was for "global trustee" — not a domain name. That was probably a malicious CA certificate that could be used to flawlessly impersonate any domain on the Web."

Is wrong -- and there is no CA certificate in the wild. _OR_

Microsoft shipped a patch for this which provides NO protection to its users.

One of these two conditions is _certainly_ true.

We have also determined that the revocation is done entirely by Certificate Serial numbers and not certificate hashes, and there is no technical assurances that the Comodo hacked certificates were not re-signed and re-issued to convert a CA:TRUE to a CA:FALSE -- save for the fact that MS relies on these hacked certificates as published to protect their users -- either leaving Windows certificates entirely un-patched to this issue (firefox would be patched based on certificate serial number) or these certificates are the 'real deal' and for some unknown reason the hacker chose to include Google's tech department as the O and OU fields in his original CSR.

Original after the break.

--

So 19 days ago I wrote on comodogate, and if you're reading about it for the first time, start at my prior article.

So this is take-two. I hadn't intended to continue to research on comodogate, but I've been so completely disappointed with the results from Google and others on this extremely serious topic, that when I was investigating the crypto api for a cloud-storage prototype this week I happened to run into the way firefox was handling the dis-trusting of these hacked certificates.

I appologize, but this post is going to get extremely technical extremely fast. Browser, firefox4 on ubuntu linux.


To follow along you'll need the package libnss3-tools installed, which will give you the commands certutil and modutil -- which you'll need to read the Firefox key stores.

 

Find your firefox profile directory. Usually .mozilla/firefox/abc123.default/

Now, issue the command:

certutil -L -h nss -d .

Near the end of the list of valid CA certs etc, you should see...

Builtin Object Token:Bogus Mozilla Addons                    p,p,p
Builtin Object Token:Bogus Global Trustee p,p,p
Builtin Object Token:Bogus GMail p,p,p
Builtin Object Token:Bogus Google p,p,p
Builtin Object Token:Bogus Skype p,p,p
Builtin Object Token:Bogus Yahoo 1 p,p,p
Builtin Object Token:Bogus Yahoo 2 p,p,p
Builtin Object Token:Bogus Yahoo 3 p,p,p
Builtin Object Token:Bogus live.com p,p,p
Builtin Object Token:Bogus kuix.de p,p,p

Which is the entries for all the bogus certs.... to view a bogus cert summary issue:

certutil -L -n "Builtin Object Token:Bogus live.com" -d .

Which will get you

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            00:b0:b7:13:3e:d0:96:f9:b5:6f:ae:91:c8:74:bd:3a:
            c0
        Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
        Issuer: "CN=UTN-USERFirst-Hardware,OU=http://www.usertrust.com,O=The
            USERTRUST Network,L=Salt Lake City,ST=UT,C=US"

        Validity:
            Not Before: Tue Mar 15 00:00:00 2011
            Not After : Fri Mar 14 23:59:59 2014
        Subject: "CN=login.live.com,OU=PlatinumSSL,OU=Hosted by GTI Group Cor
            poration,OU=Tech Dept.,O=Google Ltd.,OID.2.5.4.9=Sea Village 10,L
            =English,ST=Florida,postalCode=38477,C=US"

        Subject Public Key Info:
            Public Key Algorithm: PKCS #1 RSA Encryption
            RSA Public Key:
                Modulus:
                    f3:fc:2b:2f:ef:e1:ad:59:f0:42:3c:c2:f1:82:bf:2c:

And a bunch more data...

Here's where it gets interesting -- Notice the subject. These blacklisting certs (say for login.live.com) are subject organization = Google Ltd, organization unit=Tech Dept. and the address information is invalid (at least according to google maps at time of writing)... Sea Village 10 does not appear to exist. Then L=English for this cert, but L is supposed to be the city... and for many of the certs it is set to Tampa.... where that postal code also exists.

Question #1: What is Sea Village 10, Tampa, Florida, US, 38477?

Next, note that the cert is issued by UTN-UserFirst-Hardware, which appears to be a comodo-related trust root - but if you try to load usertrust.com it appears to be dead. Curious of a CA root without a website loading.

Next, if you take a look at the Global Trustee cert... its subject looks like

Subject: "CN=global trustee,OU=PlatinumSSL,OU=Hosted by GTI Group Cor
            poration,OU=Global Trustee,O=Global Trustee,OID.2.5.4.9=Sea Villa
            ge 10,L=Tampa,ST=Florida,postalCode=38477,C=US"

Same Sea Village 10, but no Google this time. Now here's where it gets realllllly interesting. The size of the modulus for this certificate is huge, double the others, and the certificate is larger too appearing to be paired with a 4096 bit RSA key. This key is larger than any other keys in the browser. Even the "VeriSign Class 3 Extended Validation SSL CA" doesn't have a key that big, and it's doing EV certification. Which begs the question, why is this certificate key so large. Is it this large to reflect the same key size as the original certificate.

A 4096 size key would tend to discount (though not rule out) the EFF's CA-Certificate theory... but I have a better one. What if its a high-security client certificate? Who uses a 4k client cert key named 'Global Trustee'? A 4096 bit crypto key is more secure than a 2048 bit key, but also slower, so it's use is unlikely for web-traffic where scaling is important. A client certificate however, where maximum security is required, makes total sense to be generated at that key length... the question is then:

Question #2: Who uses a 4096 bit client certificate, and who would name it "Global Trustee"?

My mind goes to systems like international banking transfers like SWIFT or EFT... or even to intelligence networks. But then, you'd expect that client certificate to be self-signed and the servers configured to verify the ssl peer depth to first-party-only. Which begs the question as to whether there is an improperly deployed client-certificate network out there with a known vulnerability.

Any high-security folks who read this, if you're using client certs and apache, make sure you have SSLVerifyDepth 1 configured properly.

So with Google's tech dept the subject of these certs (and these certs are the same that are added to untrusted certificates in ms windows certificate store) the question becomes what is Google's role in Comodogate? They've been extremely secretive about this release, not disclosing any sort of user-warning, but quietly releasing a patch and adding a related, but non-warning post to the google security blog. Clearly however, they appear to be intimately involved in this incident and its response.

I asked Google's Policy Council in Canada, Jacob Glick for a comment this morning, so far, I have not received a reply.