Compromised Comodo SSL certificates put users at risk
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
Medium
|
|||
firefox (Ubuntu) |
Undecided
|
Unassigned | |||
Hardy |
Undecided
|
Unassigned | |||
Karmic |
Undecided
|
Unassigned | |||
Lucid |
Medium
|
Micah Gersten | |||
Maverick |
Medium
|
Micah Gersten | |||
firefox-3.0 (Ubuntu) |
Undecided
|
Unassigned | |||
Hardy |
Medium
|
Micah Gersten | |||
Karmic |
Undecided
|
Unassigned | |||
Lucid |
Undecided
|
Unassigned | |||
Maverick |
Undecided
|
Unassigned | |||
firefox-3.5 (Ubuntu) |
Undecided
|
Unassigned | |||
Hardy |
Undecided
|
Unassigned | |||
Karmic |
Medium
|
Micah Gersten | |||
Lucid |
Undecided
|
Unassigned | |||
Maverick |
Undecided
|
Unassigned |
Bug Description
Binary package hint: firefox
Please see: https:/
And: http://
|
#6 |
Created attachment 519863
Bad certs (.cer) zipped
|
#7 |
Revocation is in this CRL:
http://
Here is the relevant section of the CRL:
openssl crl -text -inform DER -in UTN-USERFirst-
Serial Number: 047ECBE9FCA55F7
Revocation Date: Mar 15 19:04:03 2011 GMT
Serial Number: F5C86AF36162F13
Revocation Date: Mar 15 19:04:24 2011 GMT
Serial Number: E9028B9578E415D
Revocation Date: Mar 15 19:05:26 2011 GMT
Serial Number: 9239D5348F40D16
Revocation Date: Mar 15 20:15:20 2011 GMT
Serial Number: D7558FDAF5F1105
Revocation Date: Mar 15 20:15:26 2011 GMT
Serial Number: 392A434F0E07DF1
Revocation Date: Mar 15 20:15:38 2011 GMT
Serial Number: 3E75CED46B69302
Revocation Date: Mar 15 20:15:47 2011 GMT
Serial Number: B0B7133ED096F9B
Revocation Date: Mar 15 20:16:03 2011 GMT
Serial Number: D8F35F4EB7872B2
Revocation Date: Mar 15 20:19:04 2011 GMT
This OCSP responder, which is embedded in the certs, should also return "revoked":
http://
Gerv
|
#8 |
The idea to explicitly add the bad certs to the roots module is a good idea, but I don't know how to make this work. I don't see a way to make a cert as "explicitly not trusted". All I know of is "no explicit trust", but this is not sufficient, as the cert will still be trusted, if it can be chained to a trusted root.
The idea to use a CRL is problematic, because:
- I don't know an easy way to preship a CRL with binary NSS, because NSS reads CRLs from the database
- the approach might require that the applications ships the CRL and imports it at runtime. I think this approach is more work than the following one.
I'd like to propose the following approach (which, in a discussion with Gerv and Dan, we're currently favoring):
- block the certs at the application level
(PSM = all mozilla apps = all SSL sockets)
- embed the certs into PSM
- extend PSM's existing code for SSL_AuthCertifi
http://
- compare the server cert with our embedded blacklist
- in order to embed the blacklist, use
"issuer name" and "serial number" as the primary key to
decide about rejection
Implementation details:
I already have a tool that dumps this ID information for a given cert.
(I'm using this tool to extract the information that we need to grant the EV status to a root).
At runtime, when we arrive at the function, we have available:
- the full binary blob of the cert
- the ascii (utf8?) presentation of the issuer name
- the binary encoding of the serial number
I think it's tricky to store binary encoding into sourcecode.
It's better to use base64 encoding.
This has a minimal performance disadvante, we must convert the site's serial number from binary to base64. (But really, this little cpu overhead shouldn't be worrisome, there are many more expensive operations involved in processing certificates than this, anyway)
In theory, in order to be 100% sure we're checking the correct certificates, we ought to compare the binary encoding of the issuer name.
However, in this particular scenario, we are able to simplify, IMHO. The certificates to be blocked all use an issuer name that consists of pure ASCII characters. I propose we save CPU cycles, and do a standard string comparison for the issuer name.
When we find a match, we'll set error code SEC_ERROR_
The user will see the existing error page "site of cert is revoked".
The user will NOT be able to override.
|
#9 |
Created attachment 519872
example patch
Demonstration patch.
This patch blocks the certificate currently being used at https:/
With this patch applied, I can't connect to the server anymore.
I will soon attach a patch that blocks all 7 problematic certs from Comodo.
|
#10 |
I have received a test certificate from comodo for the host kuix.de
I have installed the test certificate on a SECONDARY port at my server,
https:/
Gerv has suggested, we could avoid the runtime conversion from binary-to-base64, by encoding the binary encoding of the serial numbers using hexadecimal characters \x00. Thanks to Gerv for that good idea.
I've enhanced the patch in bug 421989, and I now have a tool that prints such information, that can be easily copied to C source code.
|
#11 |
Created attachment 519892
text dump of certificate identies
This text file contains a dump of the identifying information of 8 certs:
- the 7 affected certs
- the test certificate from the same issuer
This information could be used for review purposes.
|
#12 |
Created attachment 519897
Proposed patch (my v3)
|
#13 |
Test instructions:
(a)
Go to a site that uses a cert from the blacklist:
https:/
Expected:
ERROR, revoked
(b)
Go to a site that uses a good cert:
https:/
Expected:
Site should display fine
(c)
Go to a site that was issued from a different CA:
https:/
Expected:
Site should display fine
FYI, (a) and (b) use certs that were issued from the same root CA.
If (a) fails and (b) works, this proves that we correctly distinguish between separate serial numbers of the same issuer.
If (c) works, this proves that our blacklist doesn't hurt other CAs.
|
#14 |
I would like to note, I'm confident in the encoding of this patch, because I didn't do it manually.
The sourcecode of that static list was automatically produced from the DER encoded certificates, and the code it produced for the test certificate at https:/
|
#15 |
I've tested the patch with 4.0 (2.0), 3.6 (1.9.2) and 3.5 (1.9.1), and it worked in all versions.
1.9.1 branch requires a slightly merged patch, but only because a neighbourhood function is different.
|
#16 |
Gerv noted that my code dumps some certificates with a leading zero, and produces thereby 17 bytes long serial numbers.
I believe this is correct, I think the binary encoding of those serial numbers is indeed 17 bytes.
When dumping such certs with NSS pp tool, it prints a leading 00:
I imported such a cert, using Firefox and cert manager, to a server tab, and then clicked "view", and it displays a 17 bytes serial number with leading 00:
|
#17 |
And the reason why I wrote comment 11, because Gerv noticed that the text dumps we have received, all serial numbers were 16 bytes long.
I believe those text dumps were produced using openssl. It appears that openssl strips initial 00: in the human readable dump.
|
#18 |
> The idea to use a CRL is problematic, because:
> - I don't know an easy way to preship a CRL with binary NSS, because NSS reads
CRLs from the database
NSS reads CRLs from tokens. adding a CRL to the builtins should work.
> - the approach might require that the applications ships the CRL and imports it
> - block the certs at the application level
> (PSM = all mozilla apps = all SSL sockets)
> - embed the certs into PSM
do you think this is the last time we are going to have this problem? It seems
to me if we can't block the certs in builtins, we should modify NSS so that we
can.
bob
Bob: should we ask Comodo to produce for us a special CRL with the seven certs in it? Their current CRL is 113k, even compressed.
Gerv
|
#21 |
On the NSS call, we decided speed was more important than pretty. That we'd keep this bug open for the 'pretty' fix, but the fastest way to solve this is kai's patch.
NOTE: kai's patch only turns off SSL. Since these certs are only valid for SSL, that should be sufficient for these certs.
bob
|
#22 |
Comment on attachment 519939
Patch v4
r+ rrelyea
|
#24 |
Comment on attachment 519939
Patch v4
I want to chemspill this
Robin Alden at Comodo (now CCed) tells me:
- Microsoft are aware of the problem.
- Opera are looking at options; they may add the roots to their "untrusted" store. Or, because they always check revocation status, they may rely on OCSP.
- Chrome are writing a patch; there is a stable version due to ship next week, and they could add the patch to that, but they may do an even earlier release for this problem.
Comodo are also discussing the matter with law enforcement.
Gerv
|
#26 |
Can I get a summary of the risk inherent in this code, please, and what QA would need to be revalidated if we took it in an RC2?
|
#27 |
Mike,
this code path is executed each time we do a handshake with any SSL server.
However, the test starts with a simple string comparison.
If the issuer name is not matching, then all remaining code is skipped.
This alone eliminates the risk for all CAs that are not connected to this issue.
If the issuer name matches, we will compare certificate serial numbers, of the server cert, against our blacklist.
The rest of the code is skipping initial zeros, and looping through our blacklist, then a final memory comparison.
This isn't risky code, no memory allocation etc., but simple iteration, looping and comparison, and code review shows we carefully deal with boundaries. I don't see risks for side effects.
I made it easy for testing.
We received a test certificate, that I installed on a server, and that we will keep around for testing the QA candidate, and longer.
The test instructions are described in comment 8.
In my opinion, the only work that needs to be repeated, if you want to: Test that you can still connect to a variety of https/SSL sites.
If you still can connect, and are not being blocked, all is fine.
(In reply to comment #22)
> I made it easy for testing.
> We received a test certificate, that I installed on a server, and that we will
> keep around for testing the QA candidate, and longer.
That is to say: we asked Comodo to issue us another certificate from the same root the bogus ones were issued from, but for a domain Kai controls. We then added that cert's serial number to the blacklist (which is why it's 8 certificates long rather than 7). This means we don't need to set up a server using one of the compromised certs (which is impossible, as we don't have the private keys) in order to test the blocking. Instead, we can use https:/
Gerv
|
#29 |
Comment on attachment 519939
Patch v4
FWIW, the patch looks good to me.
|
#30 |
Filed bug 642503 on moving a more generic version of this blacklist functionality into NSS proper for a future version.
|
#32 |
I'm not familiar with this area, and don't understand the leading zeroes thing (or why the leading zeros are kept in the literal table only to be stripped out with an extra loop). But it looks okay, and low risk.
|
#33 |
the tests from comment 8 all work fine in Fennec with this patch
|
#34 |
(In reply to comment #27)
> I'm not familiar with this area, and don't understand the leading zeroes thing
> (or why the leading zeros are kept in the literal table only to be stripped out
> with an extra loop). But it looks okay, and low risk.
Sorry, the code in the static list was automatically created using a tool. I wanted to avoid the risk of manually tweaking it, because manual tweaking has the risk of human error. Also, if I tweaked it now, I might forget about that later, if there's ever a need to recreate or extend the list.
This filtering was a late addition, suggested during code review, to make sure we always make a correct match, regardless of leading zeros.
|
#35 |
we are going to wait for bsmith's review
|
#36 |
The tool I'm refering to is NSS "pp" tool, plus the patch attached to bug 421989.
It produced attachment 519892 (which contains the leading zeros).
|
#37 |
Comment on attachment 519939
Patch v4
This seems reasonable to me, provided the leading 0s can be ignored (that is, that there are never serial numbers that are the same except one has more leading zeros than the other).
Is that the case?
|
#38 |
I'm also not quite sure why the auto-generated serial numbers have leading zeros for 6 of the certs, but not the other two...
|
#39 |
Bob would be able to explain the issue with the leading zeros better, I'll try to repeat what he said.
It depends on whether using a signed vs. an unsigned variable to the decoding of the serial number. The serial number is DER encoded. The raw encoding sometimes takes up 17 bytes, when having a 16 bytes serial number with the highest bit set.
(Don't ask me why that is, it appears to be an implementation detail/behaviour of the encoders/decoders used.)
We see a leading zero for all serial numbers that start with hex 8 or higher. No leading zero for 7 or lower.
While discussing/
Since Bob is the expert with properties of certificates and serial numbers, I also conclude he is sure that stripping leading zeros is fine. The answer to comment 32 is yes. Serial numbers are really numbers, not byte arrays.
|
#40 |
Another supporting point, when the "openssl x509" tool dumps one of those certificates, and prints the serial numbers in human readable form, it strips away leading zeros, too.
|
#67 |
verified FIXED in build 3 of RC1 for Fennec 4 based on the test instructions listed in comment #8:
Mozilla/5.0 (Android; Linux armv7l; rv:2.1) Gecko/20110318 Firefox/4.0b13pre Fennec/4.0 ID:20110318114419
(In reply to comment #62)
> verified FIXED in build 3 of RC1 for Fennec 4 based on the test instructions
> listed in comment #8:
>
> Mozilla/5.0 (Android; Linux armv7l; rv:2.1) Gecko/20110318 Firefox/4.0b13pre
> Fennec/4.0 ID:20110318114419
also double checked ssl sites for comment 0 on fennec. all good.
|
#69 |
(In reply to comment #20)
> Robin Alden at Comodo (now CCed) tells me:
> - Microsoft are [...]
> - Opera are [...]
> - Chrome are [...]
Robin: what about Apple/Safari? Have they been informed?
|
#70 |
Let's not forget to land the additional patch into 1.9.1 and 1.9.2
|
#71 |
(In reply to comment #64)
> (In reply to comment #20)
> > Robin Alden at Comodo (now CCed) tells me:
> > - Microsoft are [...]
> > - Opera are [...]
> > - Chrome are [...]
>
> Robin: what about Apple/Safari? Have they been informed?
Yes. I had a positive response and a follow up request for more information from <email address hidden>.
|
#72 |
mozilla-1.9.1
-------------
GECKO19117_
http://
http://
default:
http://
http://
mozilla-1.9.2
-------------
GECKO19214_
http://
http://
default:
http://
http://
|
#73 |
Verified for 1.9.2.16 and 1.9.1.18 using repro steps in comment 8.
|
#74 |
Created attachment 520887
fix a leak
The patch introduced a small leak. When we detect a blacklisted cert, we exit the function early and don't clean up the cert.
The fix is to move the C++ cleanup variable further up, which I have missed when moving up the line to obtain the cert.
I filed bug 643694 to fix it. I propose to do it in the nex regular update cycle. I'm attaching the patch here, as this issue is not yet public.
Comment on attachment 520887
fix a leak
As mentioned on IRC, this:
> + CERTCertificate
> CERTCertificate *serverCert = SSL_PeerCertifi
should be:
> CERTCertificate *serverCert = SSL_PeerCertifi
> + CERTCertificate
|
#76 |
The updates (not the blog post yet) should be live for 3.6 and 3.5 users.
|
#79 |
I reiterate my objection to Mozilla allowing the included certification authorities to outsource to third-party registration authorities.
description: | updated |
|
#80 |
May I ask why this bug (and the whole issue) has been kept secret for over a week? To spare my time, let me quote The Register [1] since it exactly reflects my thoughts:
<snip>
The decision by Google, Microsoft, Mozilla and Comodo to keep the world in the dark for eight days comes as a slap in the face to their users.
“The attackers had all they needed,” said Marsh Ray, a researcher and software developer at two-factor authentication service PhoneFactor. “Knowing which certificates have been compromised gives an immediate step people can take to secure their systems.”
None of the companies would explain why they waited so long to disclose the attack.
</snip>
If there is some policy due to which this was kept under the hood, then it's completely flawed and needs to be rethinked ASAP.
[1] http://
Jamie Strandboge (jdstrand) wrote : | #1 |
Thank you for using Ubuntu and reporting a bug. These packages have already been prepared, are now built and will be published soon. You can see them here: https:/
visibility: | private → public |
Changed in firefox (Ubuntu): | |
assignee: | nobody → Micah Gersten (micahg) |
status: | New → Fix Committed |
Micah Gersten (micahg) wrote : | #2 |
Natty already had this fix in Firefox 4.
affects: | firefox (Ubuntu) → ubuntu |
affects: | ubuntu → firefox (Ubuntu) |
Changed in firefox (Ubuntu): | |
assignee: | Micah Gersten (micahg) → nobody |
status: | Fix Committed → Invalid |
Changed in firefox-3.0 (Ubuntu): | |
status: | New → Invalid |
Micah Gersten (micahg) wrote : | #3 |
This update went out to all supported Stable releases about 8 hours ago.
Changed in firefox-3.0 (Ubuntu Karmic): | |
status: | New → Invalid |
Changed in firefox-3.0 (Ubuntu Hardy): | |
assignee: | nobody → Micah Gersten (micahg) |
importance: | Undecided → Medium |
status: | New → Fix Released |
Changed in firefox-3.0 (Ubuntu Maverick): | |
status: | New → Invalid |
Changed in firefox-3.5 (Ubuntu Karmic): | |
assignee: | nobody → Micah Gersten (micahg) |
importance: | Undecided → Medium |
status: | New → Fix Released |
Changed in firefox (Ubuntu Lucid): | |
assignee: | nobody → Micah Gersten (micahg) |
importance: | Undecided → Medium |
status: | New → Fix Released |
Changed in firefox (Ubuntu Maverick): | |
assignee: | nobody → Micah Gersten (micahg) |
importance: | Undecided → Medium |
status: | New → Fix Released |
Changed in firefox (Ubuntu Karmic): | |
status: | New → Invalid |
Changed in firefox-3.0 (Ubuntu Lucid): | |
status: | New → Invalid |
Changed in firefox-3.5 (Ubuntu): | |
status: | New → Invalid |
Changed in firefox (Ubuntu Hardy): | |
status: | New → Invalid |
Changed in firefox-3.5 (Ubuntu Maverick): | |
status: | New → Invalid |
Changed in firefox-3.5 (Ubuntu Lucid): | |
status: | New → Invalid |
Changed in firefox-3.5 (Ubuntu Hardy): | |
status: | New → Invalid |
Jonathan Riddell (jr) wrote : | #4 |
I'm tracking the Qt issue in bug 742377
Mozilla has made a more detailed statement about the Comodo misissuance incident:
http://
Please continue discussion in the mozilla.
https:/
Gerv
|
#82 |
Created attachment 522155
fix for 1.8.1(.24)
backport to 1.8.1.24.
If anyone has time to take a look at it, I'd be very grateful
|
#83 |
Comment on attachment 522155
fix for 1.8.1(.24)
Looks OK to me.
|
#84 |
Created attachment 522228
Hacker claim
Found a hacker's claim of responsibility at http://
Could be BS, but there are some testable claims
- the name of the RA
- the ceo's account
- the "comodo username"
- did the RA really have a trustdll.dll
- was it C#
- did it really hardcode in their password/username?
This is all depressingly plausible. Is trustdll.dll something Comodo distributes, or was that winning idea solely the RAs? Does it really take only a name and password, and do RAs typically leave those hardcoded into internet-connected systems?
Found a similar (unverified) claim in response to a Heise article on the subject, guy claiming to be a reseller (presumably restricted by DV checks at the RA or Comodo level?) who could get around that by calling the APIs directly and bypassing the app they were given.
http://
|
#85 |
(In reply to comment #79)
> Created attachment 522228
> --> https:/
> Hacker claim
>
> Found a hacker's claim of responsibility at http://
>
> Could be BS, but there are some testable claims
> - the name of the RA
> - the ceo's account
> - the "comodo username"
> - did the RA really have a trustdll.dll
> - was it C#
> - did it really hardcode in their password/username?
There's also http://
|
#86 |
Created attachment 522249
decompiled TrustDLL
(In reply to comment #80)
> There's also http://
> decompiled source code to trustdll.dll. This can also be tested.
Attached (pastebins suck].
|
#87 |
> guy claiming to be a reseller (presumably restricted by DV checks at
> the RA or Comodo level?) who could get around that by calling the APIs
> directly and bypassing the app they were given.
That claim should be easy to verify, somebody just needs to enroll as reseller and try it.
|
#88 |
I've heard the same claims from intermediate CAs using the API.
Changed in firefox: | |
importance: | Unknown → Medium |
status: | Unknown → Fix Released |
summary: |
- Compromised Comodo SSL certificates puts users at risk + Compromised Comodo SSL certificates put users at risk |
|
#89 |
> Hacker claim
One wonders why he didn't just post some data signed with one of the private keys he generated. He seems particularly anxious to prove he was the one who pulled this off.
bob
|
#90 |
Does that help? http://
|
#91 |
(In reply to comment #85)
> Does that help? http://
Since pastebins suck, here's the content:
For some real dumbs, I bet they don't have IQ above 75, WHO STILL thinks I'm not the hacker, here is mozilla addon's certificate, check it's serial with one published on all the internet:
http://
I really worry about you guys (people who still have doubts) even for surfing in internet, have you ever visited a doctor?
Private key for above certificate:
http://
@ioerror, when I say you have relations with intelligence agencies and you pass traffic, I have my reasons: http://
Thanks to Robert Graham for pointing out that private key is encrypted with a passphrase, here is private key without passphrase, I don't want to give away my passphare:
-----BEGIN RSA PRIVATE KEY-----
MIIEowIBAAKCAQE
RQCqSbc1Nwxq70d
zMZKxZc+
zFBBetA9KgxVcBQ
AOWMNVS/
OIFQvpihbLgkrfO
thiZL7jEATCNd4P
ao25aprcu2PnNA+
Zry+29DpmIN/
q+8TTjStaMbh+
ScAPCiXFUKTzY3H
591n3x3hAoGBAOO
FKdoJh3JwJzHEDX
B0laE5ISRH4Occs
jEFkr/JCRe2RWUS
cSF6Xecm3mUGqn8
jClX91heSCigwhC
3ynnx3ZQYj/
6B2E67D1Rv9w7br
gsGI2WJn3fRP7ck
bCeLGn+
Goumrw8x+
iL+yMQKBgFjXcmi
3RlshoItDQLW1RO
8jq7epvZsq5vjOC
-----END RSA PRIVATE KEY-----
And the private key has been verified as matching the public key attached to this bug:
http://
So this guy either did it, or is part of the group that did it.
Gerv
(In reply to comment #69)
> Created attachment 520887 [details]
> fix a leak
This was landed as part of bug 644012.
Presumably comment 8 can be morphed into a test, either automated or Litmus, or both. Setting flags.
|
#95 |
(In reply to comment #89)
> Presumably comment 8 can be morphed into a test, either automated or Litmus, or
> both. Setting flags.
Litmus testcase has been added -- please review:
https:/
|
#96 |
(In reply to comment #90)
> (In reply to comment #89)
> > Presumably comment 8 can be morphed into a test, either automated or Litmus, or
> > both. Setting flags.
>
> Litmus testcase has been added -- please review:
> https:/
This test presupposes that https:/
|
#97 |
(In reply to comment #91)
> > Litmus testcase has been added -- please review:
> > https:/
>
> This test presupposes that https:/
> bogus test cert is keyed to that site, we cannot move the testcase to our QA
> server.
Correct. As far as I understand it, the purpose is to test a certificate which has been revoked by the CA. Is there a way that we can spoof a revoked certificate? If we can, then we could create a test on the QA server...
|
#98 |
Testing is tricky.
Do you want to test the blacklist mechanism?
The test cert on kuix.de:9449 will expire soon. I'm not sure what will happen then. You might get EITHER error expired OR error revoked. Only if the error REVOKED then you can continue to use this blacklist test. If EXPIRED has higher precendece and is the error that will be reported, this test ability will be gone. You must test this probably around April 20.
If you want to test revocation mechanisms in general, that's another story, and I agree, that could be automated, but it would also require to have someone permanently operate a server with a revoked cert.
|
#99 |
(In reply to comment #93)
> If you want to test revocation mechanisms in general, that's another story, and
> I agree, that could be automated, but it would also require to have someone
> permanently operate a server with a revoked cert.
QA has a public facing server we can use for SSL work now.
|
#101 |
Kyle, it doesn't. If someone wanted to craft an automated test, that would be great in my opinion.
|
#102 |
Yeah, we should be able to test this through automation.
(In reply to comment #97)
> Yeah, we should be able to test this through automation.
This should bear bug 617414 in mind. I don't know how SSL tests are currently performed and whether you'd need a couple more certificates from Comodo (one to blacklist and one to not) as this code is only run if the issuer name matches.
Resetting the Litmus flag to indicate that the test still exists in Litmus (and I think it should until it is replaced, or until it is no longer a valid test as per comment 93). Given that this is a security issue, surely a Litmus test is better in the interim? Let me know if I'm wrong.
|
#105 |
ah... we have the private key for the revoked addons certificate!
bob
the litmus test should be reworked to use the addons cert for which we have the private key. in order to do this, the testcase will need to pin <'now'> to be a fixed date (e.g. 2011-03-28), on the client system, and the host will need to be happy to serve an expired certificate (possibly by pinning the date to the same).
Created attachment 519860
Bad certs (text dumps) zipped
According to mail from Comodo to the security alias "A long-term trusted partner of Comodo which has an RA function suffered an internal security breach and the attacker caused 7 certificates to be issued." The bogus certs were revoked within hours.
Unfortunately there are scenarios where the MITM can prevent the victim from contacting the OSCP responder and the certs will continue to be trusted. Given the high profile of the sites involved (including our own addons.mozilla.org) we should explicitly disable these certs if we can.
The CNs involved are
addons.mozilla.org
login.live.com
mail.google.com
www.google.com
login.yahoo.com
login.skype.com
global trustee
Can they be added as untrusted to the built-in certificate store, or does that only work for signing certificates? Can we ship a CRL containing these certs?