Fraudulent SSL certificates in the wild [LWN.net]

The just-released Firefox update announcement includes the note that "Firefox 3.6.16 and Firefox 3.5.18 blacklist a few invalid HTTPS certificates." Mozilla's separate release on the subject is rather terse, but it does at least use the word "fraudulent" instead of "invalid." Much more information can be found in the Tor blog. "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." There is still quite a bit of uncertainty about what happened, but updating seems like a good thing to do regardless.

(Log in to post comments)

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 14:59 UTC (Wed) by tbrownaw (guest, #45457) [Link]

So is this a good time to reiterate that the public CA model with many dozens or a couple hundred absolutely-trusted authorities is fundamentally broken in the sense of "if anyone screws up, everyone is compromised", and suggest something like Perspectives ( http://www.networknotary.org/ ) instead?

replacing the CAs

Posted Mar 23, 2011 23:27 UTC (Wed) by tialaramex (subscriber, #21167) [Link]

I would prefer that a trust hierarchy be an actual trust system following a hierarchy that people already have some grasp of.

DNSSEC fits that bill. The only people who can plausibly mess with, or accidentally give hackers control of, foo.bar.baz in DNSSEC are those in control of foo, bar and baz. No matter how badly Verisign screw up managing .com or how horrible China is to owners of .cn domains, your .fi domain is between you and the Finnish authorities.

I think that's more understandable (certainly better than today's situation whwere random organisations currently have the authority to issue a Google.com SSL cert) and more secure. It might also encourage banks to migrate out of the cess pool that is .com

The single point of failure in this plan would be the root, which (a) carries out very few changes, making it easier to secure than any major Certificate Authority today let alone all of them together and (b) has lots of smart people with beards who already worry about this stuff rather than three interns and an accountant.

SSH is already able to rely on DNSSEC to prove that server X has key K, we need to start integrating the equivalent capability into web browsers by default.

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 15:12 UTC (Wed) by endecotp (guest, #36428) [Link]

Interesting quote from the Tor article:

[Mozilla and Google (chrome)] both expressed that the CA
in question had done something quite remarkable by disclosing
this compromise. The incentives may not be in the favor of
the CA for disclosure. Many CAs may fall to similar attacks
and simply refuse to disclose.

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 16:13 UTC (Wed) by joey (subscriber, #328) [Link]

Also interesting that the information was embargoed despite the bad certificates presumably being in an attacker's hands and in use in the wild. Something smells..

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 19:33 UTC (Wed) by ballombe (subscriber, #9523) [Link]

I agree. In contrast with vulnerability where releasing details can help an attacker to exploit it, here the embargo only help the attacker. This is very fishy. I'd like to see the rationale for that absurd decision.

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 16:48 UTC (Wed) by Hawke (subscriber, #6978) [Link]

Shouldnt the fix be simply to revoke the certificates in question?

Yes, I know the infrastructure to handle revocation is essentially untested, but isnt that the right way to do it rather than blacklisting it on the client side?

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 17:10 UTC (Wed) by cortana (subscriber, #24596) [Link]

The infrastructure isn't untested--it is broken. Revoking the certificates has already happened (check the Tor blog)... but it's useless unless every single client on your system that wants to validate a certificate is configured to insist on OCSP, and to fail hard if OCSP validation is unavailable for some reason.

Fraudulent SSL certificates in the wild

Posted Mar 24, 2011 1:26 UTC (Thu) by kevinm (guest, #69913) [Link]

...and the attacker didn't steal themselves a certificate for the OCSP server at the same time.

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 18:33 UTC (Wed) by sumC (subscriber, #1262) [Link]

From a MS security advisory that came today.
http://www.microsoft.com/technet/security/advisory/252437...

"Executive Summary

Microsoft is aware of nine fraudulent digital certificates issued by Comodo, a certification authority present in the Trusted Root Certification Authorities Store on all supported versions of Microsoft Windows. Comodo advised Microsoft on March 16, 2011 that nine certificates had been signed on behalf of a third party without sufficiently validating its identity. These certificates may be used to spoof content, perform phishing attacks, or perform man-in-the-middle attacks against all Web browser users including users of Internet Explorer.

These certificates affect the following Web properties:

mail.google.com

www.google.com

addons.mozilla.org

"Global Trustee"

Comodo has revoked these certificates, and they are listed in Comodos current Certificate Revocation List (CRL). In addition, browsers which have enabled the Online Certificate Status Protocol (OCSP) will interactively validate these certificates and block them from being used."

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 21:37 UTC (Wed) by PO8 (guest, #41661) [Link]

Most important paragraph in the article IMHO:

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 youre visiting. However, they are nullified by the fact that OCSP checking is enabled by default on Firefox at least; it simply doesnt provide any security gains for the end user because when it fails, it fails open!

Fraudulent SSL certificates in the wild

Posted Mar 24, 2011 8:47 UTC (Thu) by alanjwylie (subscriber, #4794) [Link]

From the Comodo Report, Our interpretation ... The perpetrator can only make use of these certificates if it had control of the DNS infrastructure.

A perpetrator with control of DNS can prevent the browser from resolving OCSP domains. It is very important for OCSP checking to fail safely, rather than the Firefox default.

about:config / security.OCSP.require = true

Fraudulent SSL certificates in the wild

Posted Mar 25, 2011 0:49 UTC (Fri) by welinder (guest, #4699) [Link]

> From the Comodo Report, Our interpretation ... The perpetrator can only
> make use of these certificates if it had control of the DNS infrastructure.

Such as... China?

(I don't have any information saying that this is the case -- I just
want to point out that there are entities that are perfectly capable
of using the certificates.)

Fraudulent SSL certificates in the wild

Posted Apr 6, 2011 11:23 UTC (Wed) by robbe (subscriber, #16131) [Link]

No need to reach that high. Your friendly neighbourhood access point will do.

Actually, it's hard to think of a scenario where the attacker is able to MITM http, but *not* DNS.

So talking about your https PKI "only" being broken when DNS spoofing takes place is a bit like saying "our door lock is fine as long as nobody touches the door".

FWIW, does somebody know about these certificates being used in the wild? AFAICT this was detected by some internal revision, not by a sighting of the certs.

Fraudulent SSL certificates in the wild

Posted Mar 23, 2011 23:52 UTC (Wed) by endecotp (guest, #36428) [Link]

It has been suggested by e.g.

http://www.theregister.co.uk/2011/03/23/gmail_microsoft_w...

that the recent "SecureID" hardware crypto token compromise could be related, e.g. perhaps the cert reseller was using these tokens as part of the protection of their network.