Matching entries in the list look like this:
Serial Number: 392A434F0E07DF1F8AA305DE34E0C229
Revocation Date: Mar 15 20:15:38 2011 GMT
An interesting note is that this date is a bit earlier than the above patches. The CA knew to revoke it on March 15th and the above patches were worked into software a few days later. If the attacker was targeting specific users, the damage to those users may have already been inflicted.
All three of the CRLs in question belong to the same CA:
issuer=/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
This appears to be a reseller or something similar for the Comodo CA company when the trust chain for USERTRUST is inspected:
CN = COMODO High Assurance Secure Server CA
We appear to have no initial matches for the following Mozilla specific serials from the data that I gathered during the initial crlwatch data population run:
00b0b7133ed096f9b56fae91c874bd3ac0
00d7558fdaf5f1105bb213282b707729a3
00d8f35f4eb7872b2dab0692e315382fb0
00e9028b9578e415dc1a710a2b88154447
00f5c86af36162f13a64f54f6dc9587c06
Those serial numbers appear to not match, right? Nope. Mozilla appears
to deal with certificate serial numbers in a slightly different manner – Chrome does the same internally but Mozilla exposes a weird quirk of certificate encoding directly in the source. The human readable data does not contain this quirk. Thus if you remove the prefix of ‘00’ from those serial numbers and search for the sixteen byte values, we find what we'd expect:
Looking for 9239d5348f40d1695a745470e1f23f43 in parsed CRLs…
Match! Serial Number: 9239D5348F40D1695A745470E1F23F43
Match! Serial Number: 9239D5348F40D1695A745470E1F23F43
Match! Serial Number: 9239D5348F40D1695A745470E1F23F43
Looking for b0b7133ed096f9b56fae91c874bd3ac0 in parsed CRLs…
Match! Serial Number: B0B7133ED096F9B56FAE91C874BD3AC0
Match! Serial Number: B0B7133ED096F9B56FAE91C874BD3AC0
Match! Serial Number: B0B7133ED096F9B56FAE91C874BD3AC0
Looking for d7558fdaf5f1105bb213282b707729a3 in parsed CRLs…
Match! Serial Number: D7558FDAF5F1105BB213282B707729A3
Match! Serial Number: D7558FDAF5F1105BB213282B707729A3
Match! Serial Number: D7558FDAF5F1105BB213282B707729A3
Looking for d8f35f4eb7872b2dab0692e315382fb0 in parsed CRLs…
Match! Serial Number: D8F35F4EB7872B2DAB0692E315382FB0
Match! Serial Number: D8F35F4EB7872B2DAB0692E315382FB0
Match! Serial Number: D8F35F4EB7872B2DAB0692E315382FB0
Looking for e9028b9578e415dc1a710a2b88154447 in parsed CRLs…
Match! Serial Number: E9028B9578E415DC1A710A2B88154447
Match! Serial Number: E9028B9578E415DC1A710A2B88154447
Match! Serial Number: E9028B9578E415DC1A710A2B88154447
Looking for f5c86af36162f13a64f54f6dc9587c06 in parsed CRLs…
Match! Serial Number: F5C86AF36162F13A64F54F6DC9587C06
Match! Serial Number: F5C86AF36162F13A64F54F6DC9587C06
Match! Serial Number: F5C86AF36162F13A64F54F6DC9587C06
Here's sample from one of those CRLs:
Serial Number: D7558FDAF5F1105BB213282B707729A3
Revocation Date: Mar 15 20:15:26 2011 GMT
Ironically, after all of this work, the Mozilla patch also leaks the CA name and confirmed my suspicions without question.
In the end, when the lists are merged, we find eleven certificates with two certificates probably acting as testing certificates for the two vendors involved:
047ecbe9fca55f7bd09eae36e10cae1e
392a434f0e07df1f8aa305de34e0c229
3e75ced46b693021218830ae86a82a71
72032105c50c08573d8ea5304efee8b0
9239d5348f40d1695a745470e1f23f43
b0b7133ed096f9b56fae91c874bd3ac0
d7558fdaf5f1105bb213282b707729a3
d8f35f4eb7872b2dab0692e315382fb0
e9028b9578e415dc1a710a2b88154447
f5c86af36162f13a64f54f6dc9587c06
This is evidence of a rather serious event and one that cannot be ignored. If I had to make a bet, I'd wager that an attacker was able to issue high value certificates, probably by compromising USERTRUST in some manner, this was discovered sometime before the revocation date, each certificate was revoked, the vendors notified, the patches were written, and binary builds kicked off – end users are probably still updating and thus many people are vulnerable to the failure that is the CRL and OCSP method for revocation. Even after users update, I'm guessing they may be unequally protected. Mozilla and other browsers should force OCSP verification by default as part of their next release and remove CAs that are unable to handle this requirement. Users of Mozilla Firefox that are concerned about this issue should enable security.OCSP.require in the about:config dialog. The surveillance concerns of enabling OCSP are serious – a CA learns what sites you’re visiting. However, they are nullified by the fact that OCSP checking is enabled by default on Firefox at least; it simply doesn’t provide any security gains for the end user because when it fails, it fails open!