
Detecting Certificate Authority compromises and web browser collusion  - adulau
https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion
======
gojomo
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...](https://blog.mozilla.com/security/2011/03/22/firefox-blocking-
fraudulent-certificates/)

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

~~~
JoachimSchipper
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?)

------
extension
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?

~~~
JoachimSchipper
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...

~~~
extension
Why are the browser makers indulging them on this?

~~~
JoachimSchipper
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.)

~~~
extension
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...](http://www.microsoft.com/technet/security/advisory/2524375.mspx)

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

------
trotsky
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?

------
extension
Forged certs are for these domains:

login.live.com

mail.google.com

www.google.com

login.yahoo.com (3 certificates)

login.skype.com

addons.mozilla.org

"Global Trustee"

[http://www.microsoft.com/technet/security/advisory/2524375.m...](http://www.microsoft.com/technet/security/advisory/2524375.mspx)

Spies!

EDIT: from Iran!

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

~~~
gcb
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

------
lawnchair_larry
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.

------
wladimir
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...

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

~~~
wladimir
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.

~~~
pmjordan
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.

