Detecting Certificate Authority compromises and web browser collusion | Hacker News Reader

Detecting Certificate Authority compromises and web browser collusion

blog.torproject.org

88 pointsadulau23 comments

This account buries the lede in investigation details.

The key points (if I understand correctly) are:

Fraudulent SSL certificates, trusted by all but the very latest browser versions, were obtained by unauthorized parties for 7 hostnames: 'addons.mozilla.org' and 6 others not yet known (but possibly 'high-value' sites like "Facebook, Skype, Google, Microsoft, Mozilla").

The possessor(s) of these rogue certificates could plausibly impersonate those sites in HTTPS traffic, except with regard to the very latest browser releases. (The latest Chromium/Chrome and Firefox for the first time include a certificate blacklist in their source code, and noticing this change began the author's investigation.)

Traditional certificate-revocation methods are supposed to prevent this, but can be made to fail silently, indefinitely, by the same sorts of attackers who can intercept and alter other traffic. Thus older browsers may continue to be subject to such impersonation indefinitely.

All the compromised certificates appear to have been issued by a company called USERTRUST from Utah, a reseller/delegated-authority via Comodo. It is speculated that a "state level adversary" could have been responsible for the creation of the illegitimate certificates. There's been no official statement by the Certificate Authorities; the above was deduced from the source code changes and data in the EFF's 'SSL Observatory'. Mozilla has issued a statement on their security blog:

https://blog.mozilla.com/security/2011/03/22/firefox-blockin...

Could this possibly be the Chinese government, what with their attempts to compromise gmail in the last week or so?

It could certainly possibly be the Chinese government, but there's no evidence linking them and there seem to be easier ways for the Chinese to get their hands on a CA. (They already have one, and are you really willing to bet that no other CA is willing to give out a copy of their key for "law enforcement purposes" and a big pile of money?)

I wonder if comodo is an RSA secureid customer. Odds are they are.

Comodo revoked the certificates on the 15th, RSA announced their compromise on the 17th, but presumably rsa et al. were aware some days before the announcement.

Sooooo.. why keep it a secret until the patch? And why not disclose the targets? If the attacker already has the bogus certs then the damage is done.. or is it?

The CA in question would likely prefer not to have their name all over this fiasco. Which is why the browsers blacklist something as opaque as serial numbers...

Why are the browser makers indulging them on this?

Because trust in the CA system is essential for the web as an application platform? Google wouldn't be happy if people started making native clients with hardcoded public keys because they didn't trust the CA system... (cf. cperciva's tarsnap.)

I can't see all the browser vendors being complicit in what would essentially be a cover-up just to make the internet look good.

And anyway, they didn't cover it up, they just waited for the patch. But they checked it in to the public repos days ago, so they weren't trying to hide it from the attacker, just keep it low profile. That doesn't make sense for this type of vulnerability, unless there is something interesting we don't know about.

My best guess is that we are waiting for audits of the target sites to finish, and I guess addons.mozilla.com is already done.

EDIT: Nevermind, here is the list of affected sites: http://www.microsoft.com/technet/security/advisory/2524375.m...

Hey, I'm not the one talking about cover-ups. See my other comments in this thread.

A loss of trust in the CA system by the general public would likely lead to a loss of trust in the internet in general.

So the solution to "the CA system is not trustworthy" is "tell the public the CA system is trustworthy"?

Edit: I mean, I can see how it's in the browser's interests to convince people that the system is reliable. And I can see how it's in web companies' interests to convince people that the system is reliable. But trying to convince people that the system is reliable when it is known not to be reliable strikes me as ethically questionable, at best.

I don't think we're disagreeing here, I was just trying to point out what the browser vendors motivations might be. It is also quite possible that law enforcement etc. requested a delay in the announcement to aid what has to be a significant ongoing investigation.

The public wasn't lied to, or even spoken to - some browser makers just slapped a band-aid on a broken system to prevent it from visibly falling apart. People (but not necessarily Mozilla et al. - think cryptographers) should arguably be fixing the system instead, but it's a hard problem and immediate fixes would be needed anyway.

Thanks to ioerror for conducting this important investigation! Without people like him keeping watch we'd all be much worse off.

It was noted in the blog post that there has been some speculation of state actors being involved. Could anyone point me towards any discussions along those lines?

Forged certs are for these domains:

mail.google.com

www.google.com

addons.mozilla.org

"Global Trustee"

http://www.microsoft.com/technet/security/advisory/2524375.m...

Spies!

EDIT: from Iran!

http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

Yes, because a state agent capable of doing this would so not use a proxy...

Id put my money on this list of "state" agents - usa - china - script kiddies

This is great news. Security experts have been trying to beat everyone over the head with how fundamentally broken and untrustworthy this system is. Now that the theoretical has been proven, maybe we can take a more serious look at moving on to something that works.

I think this hardcoded revocation list will grow out of control pretty soon. Are any browser vandors working on a more secure protocol than TLS/SSL that is not as vulnerable to a single point of failure? Not exactly trivial, though it seems direly needed...

This isn't a weakness in the protocol, but in the way certificate trust is handled. This is a bug in policy, not code.

The policies are implemented in code, in this case. But, let's rephrase my question then: are they working on a better way of handling certificate trust, in which a random compromised CA cannot do as much damage? The current model is clearly broken security-wise, and I'm sure this is only the start of the abuse.

I don't know if there's such an effort underway, but I hope so. Unfortunately, the entrenched players don't really have much of an incentive to change things, they're making billions from the current certificate model. The CAs don't even need to be compromised, there are quite a few that are maybe not 100% trustworthy (China's CNNIC is one that springs to mind) that are trusted by browsers by default. I agree it's a huge problem. I was merely pointing out that the problem does not lie within TLS/SSL.

The PGP "web of trust" is an existing distributed trust model; it never really caught on, though.

Alternate designs have lots of issues. The most prominent alternative, PGP's web-of-trust, quietly failed in the market (seriously, even most of my cryptographer colleagues don't have (up-to-date) keys).

There is some talk of using DNS to authenticate servers - just stuff a public key into DNSSEC authenticated records - but it'll be a while before that is actually ready. And someone will still have the key to the DNS root, and all of this stuff only works if DNS fails closed (i.e. breaks if there are no signatures), which won't happen anytime soon.

Reply on news.ycombinator.com