内容很长,大家慢慢看.
Detecting Certificate Authority compromises and web browser collusion
Posted March 22nd, 2011 by ioerror
Thanks to Ian Gallagher, Seth Schoen, Jesse Burns, Chris Palmer, and other anonymous birds for their invaluable feedback on this writeup.
The Tor Project has long understood that the certification authority (CA) model of trust on the internet is susceptible to various methods of compromise. Without strong anonymity, the ability to perform targeted attacks with the blessing of a CA key is serious. In the past, I’ve worked on attacks relating to SSL/TLS trust models and for quite some time, I’ve hunted for evidence of non-academic CA compromise in the wild.
I’ve also looked for special kinds of cooperation between CAs and browsers. Proof of collusion will give us facts. It will also give us a real understanding of the faith placed in the strength of the underlying systems.
Does certificate revocation really work? No, it does not. How much faith does a vendor actually put into revocation, when verifiable evidence of malice is detected or known? Not much, and that’s the subject of this writing.
Last week, a smoking gun came into sight: A Certification Authority appeared to be compromised in some capacity, and the attacker issued themselves valid HTTPS certificates for high-value web sites. With these certificates, the attacker could impersonate the identities of the victim web sites or other related systems, probably undetectably for the majority of users on the internet.
I watch the Chromium and Mozilla Firefox projects carefully, because they are so important to the internet infrastructure. On the evening of 16 March, I noticed a very interesting code change to Chromium: revision 78478, Thu Mar 17 00:48:21 2011 UTC.
In this revision, the developers added X509Certificate::IsBlacklisted, which returns true if a HTTPS certificate has one of these particular serial numbers:
d8f35f4eb7872b2dab0692e315382fb0
b0b7133ed096f9b56fae91c874bd3ac0
9239d5348f40d1695a745470e1f23f43
d7558fdaf5f1105bb213282b707729a3
f5c86af36162f13a64f54f6dc9587c06
A comment marks the first as “Not a real certificate. For testing only.” but we don’t know if this means the other certificates are or are not also for testing.
With just these serial numbers, we are not able to learn much about the certificates that Chromium now blocks. To get more information, I started the crlwatch project. Nearly every certificate contains a reference to a Certificate Revocation List (CRL). A CRL is a list of certificates that the CA has revoked for whatever reason. In theory, this means that an attacker is unable to tamper with the certificate to prevent revocation as the browser will check the CRL it finds in a certificate. In practice the attacker simply needs to tamper with the network – this is something they’re already able to do if they are performing a SSL/TLS Machine-In-The-Middle attack. Even if an attacker has a certificate, they generally are unable to modify the certificate without breaking the digital signature issued by the CA. That CA signature is what gives the certificate value to an attacker and tampering takes the attacker back to square zero. So while investigating these serials, we clearly lack the CRL distribution point in the Chrome source. However, the project that I announced on March 17th, crlwatch, was specifically written to assist in finding who issued, and potentially revoked the serial numbers in question. By matching the serial numbers found in the source for Chrome with the serial numbers of revoked certificates, we’re able to link specific serials to specific CA issuers. The more serial numbers we match in revocation lists, the higher our probability of having found the CA that issued the certificates.
About twelve hours (Thursday, March 17, 2011 | 13:00) after the above patch was pushed into source control – Google announced an important Chrome Update that involved HTTPS certificate issues.
This also is mostly uninteresting until we notice that this is not isolated to Google. Mozilla pushed out two patches of interest:
rev-f6215eef2276
rev-55f344578932
The complete changeset is semi-informative. Mozilla references a private bug in that fix that Mozilla will hopefully disclose. Similar to Chromium, the Mozilla patches create a list of certificate serial numbers that will be treated as invalid. However, the serial numbers from the Mozilla patches are different:
d8f35f4eb7872b2dab0692e315382fb0
b0b7133ed096f9b56fae91c874bd3ac0
9239d5348f40d1695a745470e1f23f43
d7558fdaf5f1105bb213282b707729a3
f5c86af36162f13a64f54f6dc9587c06
Thus, both Mozilla and Google shipped similar patches to their code at roughly the same time. The two browsers now have partially overlapping certificate blocklists. Here is the union of the two lists:
00b0b7133ed096f9b56fae91c874bd3ac0
00d7558fdaf5f1105bb213282b707729a3
00d8f35f4eb7872b2dab0692e315382fb0
00e9028b9578e415dc1a710a2b88154447
00f5c86af36162f13a64f54f6dc9587c06
047ecbe9fca55f7bd09eae36e10cae1e
392a434f0e07df1f8aa305de34e0c229
3e75ced46b693021218830ae86a82a71
72032105c50c08573d8ea5304efee8b0
9239d5348f40d1695a745470e1f23f43
b0b7133ed096f9b56fae91c874bd3ac0
d7558fdaf5f1105bb213282b707729a3
d8f35f4eb7872b2dab0692e315382fb0
f5c86af36162f13a64f54f6dc9587c06
Why do the browsers have these blocklists, and why don’t they have the same blocklists?