It has always been "believed" that nation states are using MITM attacks based on "legit" certificates and a single pipeline. This however provides stronger evidence that that belief is well founded. (versus just being paranoid).

Combined with the Ars article [1] on those certificates that come bundled with the browser and the circumstantial evidence begins to pile up.

Presumably one can delete various CA's they don't trust from their cache, but that just makes the browser complain that mail.google.com is using a certificate that isn't trusted, it doesn't let you connect to a server from Google that is using a certificate you trust.

[1] http://arstechnica.com/security/news/2010/03/govts-certifica...

Also, ioerror has posted an update in response to Comodo's disclosure:

https://blog.torproject.org/blog/detecting-certificate-autho...

Bottom line is certificate revocation lists and OCSP don't mean anything to an attacker like Iran who is MITM'ing the relevant traffic.

Yea, did the OCSP designers even thinking about the possiblity of MITMing the OCSP itself?

This is a bit of a mess. I wouldn't trust the revocation to work, since that involves a request over a network that has already been compromised.

Interesting to find what the Chrome team did to fix this:

http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x50...

Good reason to upgrade!

(Edit: this happen a few weeks ago, it has apparently taken the browser makers 8 days to issue an update while in the interim there were rogue signed certs out in the wild)

Does anybody find it ironic that this guy from the TOR project (great work by this guy) uncovers this and we take it at face value that the IP address that this attack appeared to be coming from is the actual attacker? The attacker couldn't possibly have been using a proxy, could he have? </sarcasm>.

I just got sent this screenshot from an Indian tech co who say they were hacked only a few hours ago, from an Iranian IP address:

http://imgur.com/qj1Ak

Turns out the IP address is being misreported as from Iran, so i'm wondering if the same thing happen in this case to point the finger at them

Did anyone ask the ISP (Pishgaman TOSE Ertebatat Tehran Network) to investigate which subscriber was using the IP address at the time of the attack?

I think when there is presumably a state actor involved, the issue comes up of how you could possibly trust any answer you got. If the iranians told you oh we traced it back to joe in columbus or victor in st. petersburg would you say "oh, thanks" and go knock on their doors? Pretty sure no one has been bothering to ask the CIA who they think made Stuxnet either.

This is proof that nations are hacking and spoofing SSL keys in order to spy on its citizens.

No it's not. Even if "most of the IPs involved in the attack came from Iran" constituted proof that the attacker was Iranian, it would not be proof that (1) the attacker was the Iranian government, or that (2) they intended to use the stolen SSL keys to spy on the citizenry of Iran.

It is, at best, evidence, not proof. Reasonably strong evidence, mind you.

Not that strong if you consider this:

"The attacker was well prepared and knew in advance what he was to try to achieve. He seemed to have a list of targets that he knew he wanted to obtain certificates for, was able quickly to generate the CSRs for these certificates and submit the orders to our system so that the certificates would be produced and made available to him."

This makes me think that this could've been prepared anywhere in the world and was made from an Iranian IP address to make it look like it originated in Iran.

If they were that prepared why not use a host in a different country?

It is the classic "China IP" issue, in that China has become such a famous source for penetrations that other actors appear to prefer Chinese IPs as effective cutouts. But the other side of the coin is that a substantial number of attacks from china IPs do actually get tracked back to individuals or organizations inside China. That would lead one to conclude that if it quacks like a duck, it is, often, a duck.

Goes to show that you need to know/trust your certificate chain, and not some "padlock" piece of browser chrome. Continuing my irritation with the way browser presentations de-emphasize the actual chain and certificates involved.

Even if the certificate labeling is copied, the actual cryptographic values will change. (If they were readily reproducible, the cryptography itself would be useless.)

So... notify the user when those values change from previous sessions, or at least when the fingerprint changes. This still assumes the ability to establish the legitimate values during those previous sessions or via other means. And it appears that trusting the original browser installation is not adequate. (E.g. dozens of "built-in" certs, some from who knows where. Or now, apparently, attempted forgery of Mozilla certificates.)

Of course, I guess most users will refuse to deal with such details, anyway. Until it hurts enough...