First of all, congrats to the people who pulled this off. A couple of the authors are friends of mine, and I heard a few weeks ago that they were going to announce something major today, but this is still bigger than I expected.
In a way, I'm very gratified to see this. Let me explain. I used to do hash function research a couple of years ago before I shifted to other things. I've also worked in a team building a security product. When I suggested that they should stop using MD5 to publish hashes of worm binaries, they weren't sure why I wanted them to do that. This was well after MD5 collisions had been widely publicized. I brought it up in a meeting, and they said that other teams also used MD5s, so it would be confusing for users to have two different formats, and so they weren't going to switch "until everyone else did." I was very surprised, but dropped it because I figured I was getting a taste of how things worked in the real world.
In my life as an academic, the one thing I've repeatedly observed is that the disconnect between people doing research and people directly applying that research is huge. Seriously, what does one have to do? It's not like we're trying to educate end-users here -- root CA's are in the business of staying on top of this stuff. Sheesh.
It's quite impressive due to the timing involved. It takes approx 2 days to compute the collision. They need to pick an exact time (to the second) that they will request the cert after the collision is computed, and the exact serial number that the CA will issue. They can monitor and increment the serial number as the target time approaches by buying more certs.
They created an MD5 collision to get RapidSSL to sign a certificate whose signature also verifies a CA=YES certificate. In other words, they used an MD5 collision to synthesize a new CA. Your browser will trust an Amazon.com certificate signed by their rogue CA.
They were able to do this because:
(1) RapidSSL, FreeSSL, TC TrustCenter, RSA, Thawte, and Verisign Japan will sign certs with MD5.
(2) They worked with Arjen Lenstra and Marc Stevens and obtained a method to generate pairs of plaintexts with arbitrary chosen prefixes within 72 hours on a cluster of 200 PS3 game consoles.
(3) Even though the prefix of a signed certificate contains fields the attacker doesn't control --- the serial number and validity period (which is effectively a timestamp of when the cert was signed at the CA), RapidSSL fucked up and used a monotonically increasing serial number (!), so they could predict the CA's fields and build them into their collision.
(4) Even though generating the MD5 collision requires the certificates to include a large amount of random-looking data, there's a place in the "real" certificate and a different place in the "rogue" certificate to stash that data: the collision material in the "real" cert is hidden the the RSA modulus, which is random anyways, and the corresponding location in the "rogue" certificate is masked as a "Netscape Comment Field" (a "tumor") which browsers ignore.
All 4 of these things had to happen at the same time to make this doable:
(1) There's no practical break for SHA-1, which is what most CAs use.
(2) You have to be able to generate the collision within a short window of time to get the resulting product signed properly by the CA, so you need the new academic result (and the PS3s).
(3) If RapidSSL and FreeSSL had simply randomized the serial number, like everyone else, there'd be no way to predict the signed product of the request, and your collision wouldn't mean anything.
(4) You obviously have to play ASN.1 games to make the random collision fit into a semantically valid certificate.
They spent $700 generating certificate requests to pull this off; because RapidSSL allows requestors to reissue certs 20 times, each attempt costs $2.50.
In particular, section 5.3.4 has the clearest description of MD5 collisions I've ever read, with a really excellent series of graphics.
IS THIS THE WORST THING THAT HAS EVER HAPPENED TO THE INTERNET EVER EVER?
No. Two years ago, Daniel Bleichenbacher demonstrated a pencil and paper attack on the RSA validation procedure used by OpenSSL. That attack required a mass software update. This one will hopefully just put RapidSSL out of business.
This one will hopefully just put RapidSSL out of business.
I did not realize this until just now, but RapidSSL is owned by GeoTrust, which is owned by Verisign... so RapidSSL may not disappear in a puff of logic as one might hope.
Here's Verisign's report that they've discontinued MD5 and are offering free replacement certificates:
Of course, all the KPMG audit really says is "GeoTrust has a policy about checking the documentation of people who request certificates", and there's part of the problem: there's no way for a CA to make an attestation that they've implemented the technology competantly, because no third party will certify that attestation.
The person who manages to get their "Live Chat" people to respond to questions about this (perhaps by asking as a "prospective customer concerned about stories in the news") is going win a Hacker News karma bonanza.
Am I reading your output correctly, or are you saying that Verisign US is vulnerable? Or is this just humor?
The reality seems to be that only RapidSSL and FreeSSL are practically vulnerable; of the small subset of CAs that will sign with MD5, they're the two that will sign predictably; the others randomize the serial number field.
Moreover, this is an exceedingly hard vulnerability to exploit. Sotirov's team not only had a cluster of PS3s running custom code optimized to quickly find MD5 collisions, but were also working with a new academic result on collision-finding that has not yet been published.
OK, if you're right about the serial number part that is great. All I did was export the CA certs in my Firefox install and then ran a quick program on all the files to extract the signature algorithm.
Anyhow, the program you want to check this out is Firefox itself: Preferences -> Advanced -> Encryption -> View Certificates -> Authorities -> "View" -> Details.
Yes, but prior discovery is a real problem. If Jake and Alex hadn't told us that they had successfully pulled this off we would never have otherwise known. In that case they would be in silent and permanent possession of something like the master keys to the whole SSL certificate system.
Agreed. However, wouldn't an operational review of certificate issuance activity of the impacted CAs provide another level of assurance that the researchers were the only ones who successfully exploited this vulnerability? I would imagine their activity (when inspected as a series of requests) would look rather anomalous.
Yes. Moreover, this is cited in the author's paper as a countermeasure against the attack. The attack required them to make a series of requests to probe and then prime the serial number to the value they picked for their "colliding machine", which takes days to run.
What about prior discovery that occurred before all the other certificate authorities began to harden against theoretical attacks like this? MD5 based signatures and monotonically increasing certificate serial numbers used to be the rule, not the exception.
I have root certificates in my browser that are valid from 1998 to 2018. It's not so easy to verify that this attack didn't already happen 5 or even 10 years ago.
Personally I think it's extremely unlikely, especially since the chosen prefix collision attack they used has only been public for less than two years, but how could you know for sure?
They're also using an unpublished variant of the chosen-prefix attack, which presumably is what allows them to win the weekend race to generate a collision with a predicted timestamp/serial pair.
We're also focusing on the algorithm, but not really accounting for the fact that simply owning a cluster of PS3s doesn't give you the optimized math code that generates the birthday bits during the weekend window. That code is itself presumably harder to write than any zero-day exploit.
And all the customers that bought certificates from these CA's? Let 'em hang?
Who cares that these customers business reputations depends on the SSL certificates validity.
I agree with you that certificates made with the MD5 hash should be phased out gradually by the CAs, but you can't just do a sweeping revocation without ruining businesses.
Which would you prefer to have: Customers complaining that your SSL certificate is invalid until you spend the a few minutes to get an updated certificate; or customers complaining that you're a fraud because they gave you (well, really just someone pretending to be you) money and you haven't delivered the product/service they ordered?
I don't understand your logic. Revoking certificates will cause unpleasant SSL errors. Not revoking certificates will negate all the security of SSL. How could those two problems be comparable?
> Revoking certificates will cause unpleasant SSL errors.
Unpleasant errors scares away buyers. That is, Error + Credit Card = No Purchase
> Not revoking certificates will negate all the security of SSL.
Not true. The encryption part of the certificate is still there. However, the added assurance that you're really on the site you think is compromised.
But has the assurance part of SSL certificates actually reduced phishing? Stupid people will still put all their money in BankOfShmamerica.com as long as it looks sort of like the BankOfAmerica.com site and doesn't throw any errors.
If you think "the encryption part of the certificate" is still there, you don't really understand how SSL works. Without a secure certificate, you can't trust your SSL session keys. See:
You're right - I've never implemented SSL, and as such don't know the minutia of the algorithm.
I didn't gather a lot of information from the link you posted, but this doc on the SSL handshake ( http://docs.sun.com/source/816-6156-10/contents.htm ) to my eyes doesn't show why you wouldn't be able to trust your session keys.
Could you explain how session keys can be compromised?
In this case I could be falling for a fake site and sending them my CC data, instead of Amazon, however I'm still protected from my CC being stolen by guy who setup the coffee house Wifi router.
Out of all the hypothetical scenarios you could have chosen, you picked one where it is not only possible to intercept your encrypted data but really quite obvious how to do it.
Unfortunately, you too are misunderstanding how SSL works. If you own the coffee house WiFi router, you can decrypt any SSL session that traverses your network that doesn't use valid certificates. You simply need to inject your own certificate into the SSL session and fix a session key.
You cannot secure a conversation between two unrelated parties over the Internet without some form of authentication, to "break the tie" if the attacker presents their own keys/certificates.
I have great respect for your security knowledge, but your consistent black & white views and your assumption that anyone who doesn't share them doesn't understand the technology is frustrating.
If I own a coffee house router, or if I am simply sniffing un-encrypted wifi packets out of the air in the coffee house, logging traffic is extremely simple. I can log all traffic, or just traffic to http pages with names like login, or checkout, and I can do that very very very easily. It will log tons data automatically, and let me comb through it later. As a newbie to linux I could do that. The barrier preventing me from stealing the info you send over http is VERY low, and virtually anyone can do it.
The attack you describe is much more difficult to execute. The number of people who could make that attack is several orders of magnitude smaller than the previous attack. Hence my risk is several orders of magnitude smaller.
You're arguing that because skilled safe-crackers can open a safe, people should just leave their valuables on their lawn chairs out front. Security isn't black and white. Nothing will be 100% secure from every type of attack. It's a matter of raising the barrier of entry for an attack high enough that it's generally not worth the trouble.
What you're not acknowledging, anywhere in the above 5 paragraphs of text, is that all the security you're talking about getting from SSL in this scenario is security that the attacker is choosing to give you. When we reason about information security, we don't usually give the attacker that kind of advantage.
There is no such thing as a purely-passive attacker. In reality, no serious attacker is even going to bother sniffing your traffic; they're going to redirect it.
Sorry, the scenario we're talking about here, as laid out by you: "Not revoking certificates will negate all the security of SSL."
We're not talking about the scenario where a very smart attacker is targeting me with this security hole. We're talking about the impact of not revoking the certificates in question. At which point there is a very very small possibility that I will be targeted by an active attacker with the know-how to exploit this issue. The rest of the time SSL will continue to work as designed and will protect me from wifi snoopers and suspect routers.
There absolutely are passive attackers. There are people running open wifi points that log http form submissions with a "password" field, and then try the same username/password on a few major sites (ebay, amazon, etrade, gmail, BoA, etc...) automatically (working on the assumption that people use the same login/password on the many non-ssl authed non-important sites as they do for their important accounts). Successful login data is marked. I have met people running these. It costs nothing, is fully automated, and has very little risk.
They may not be "serious attackers", but the likelihood of one of them getting your mom's eTrade info is much higher than an active attacker targeting your mom.
I'm sorry, I'm just not interested in talking about security in terms of attackers who are too dumb or lazy to carry out well-known, utterly practical attacks. You can keep saying that "the encryption part of SSL works fine with authentication"; if you add the phrase "as long as you're dealing with functionally retarded adversaries", I won't even call you on it.
Well known and utterly practical? You have been commenting about how difficult this attack is and how the MD5 collision breakthrough is still secret.
You're not interested in the risk of or protection against provided by SSL encryption for a simple and probably relatively common passive attack? Because those people are lazy or dumb, we can write them off entirely and say SSL provides no security if there's a potential CA related exploit? I get that it's not as interesting a situation to think about, but I think that logically you can prove that SSL provides an increased security over http to the end user, even if some certs could be compromised.
"
(2) You have to be able to generate the collision within a short window of time to get the resulting product signed properly by the CA, so you need the new academic result (and the PS3s).
(1) The attack is extremely difficult to pull off.
(2) Critical details required to carry it out --- an academic breakthrough in MD5 collision-finding --- were actually withheld, meaning that no "zero-day" occurred.
(3) The "fix" for this attack is for RapidSSL to randomize serials and stop using MD5, both of which will happen; if you believe certificates from before today are vulnerable, that's an even stronger argument for publishing.
"
The attack you are talking about it completely trivial. It relies on you being too dumb to even care if you have a real certificate. The attack Sotirov, et al have discovered is extremely hard. It works even if you check certificates.
I think that was modoc's original point, in response to the 'stella' comment. SSL, even if vulnerable to Sotirov-level impersonation attacks, still protects from other idiot-level attacks.
So you might be tricked into setting up encrypted communication to one of the (small) N groups that have the knowledge/budget to do a Sotirov attack, but at least you still won't have identity details hijacked by (large) M others, because even broken cert-checking protects against them.
"the encryption part of the certificate" is still there as far as the wifi packets leaving your laptop are concerned, and as far as the poorly/maliciously configured linux router in the backroom of the coffee shop are concerned.
So, is it 100% secure? No. Is there still a reasonably high barrier of entry to getting your CC number/bank login? Yes.
That's like saying if you were using one of the weak Debian ssh keys, you might as well be using telnet. It's simply not true. The effort to steal your info is at least an order of magnitude (if not more) higher, even with weak ssh keys. The same situation applies here.
tptakec is 100% correct, but I like to explain stuff to people:
The packets leaving your laptop are protected from being eavesdropped by third parties, but the party you're sending your banking password to is some asshole who now apparently runs a CA, and just issued a certificate telling your web browser he's your bank.
The scenario under discussion (at least I as understood it from this particular thread of comments) is if we don't revoke all the compromisable certs. The scenario is NOT that I am connected to an attacker who has successfully used this attack against me.
Under that scenario, then you've already lost your data (although I'd still hold it's better to have your CC stolen by one person, rather than two), so yes, that's bad. However, that's not the scenario that I've been discussing here. This thread came under the debate about the risks and issues with revoking all those certs immediately, versus not.
If you're saying, "we shouldn't do anything rash to mitigate an attack that requires Arjen Lenstra and a specially tuned cluster of PS3s to accomplish", then that makes sense.
If you're saying, "we shouldn't do anything rash because certificates don't break encryption, only authentication", then you are perpetuating a really dangerous myth about SSL security.
The customers that bought certificates should be getting an SHA1 certificate from the CAs. Why shouldn't there be a sweeping revocation? Any web apps that are dependent on rapid response to problems like this will be able to respond quickly. If things are handled properly, we should see abandonment of MD5 certs in a matter of days. Taking more time just gives time to the exploiters.
A sweeping revocation wouldn't work, as you can only revoke certifcates that have not been tampered with. You must issue a SHA-1 certificate to everyone and then change every piece of software that uses certificates not to trust certificates with an MD5 hash in the trust chain. If someone else has successfully performed this attack, he might posses a CA certificate that is valid until 2038 and you have no way to know about it until he uses it against you.
(1) The attack is extremely difficult to pull off.
(2) Critical details required to carry it out --- an academic breakthrough in MD5 collision-finding --- were actually withheld, meaning that no "zero-day" occurred.
(3) The "fix" for this attack is for RapidSSL to randomize serials and stop using MD5, both of which will happen; if you believe certificates from before today are vulnerable, that's an even stronger argument for publishing.
(4) The product of the attack was deliberately backdated to 2004 to prevent real-world exploitation.
(5) I may be wrong about this, but --- Ben Laurie himself helped zero-day the RSA signature validation flaw two years ago.
In a way, I'm very gratified to see this. Let me explain. I used to do hash function research a couple of years ago before I shifted to other things. I've also worked in a team building a security product. When I suggested that they should stop using MD5 to publish hashes of worm binaries, they weren't sure why I wanted them to do that. This was well after MD5 collisions had been widely publicized. I brought it up in a meeting, and they said that other teams also used MD5s, so it would be confusing for users to have two different formats, and so they weren't going to switch "until everyone else did." I was very surprised, but dropped it because I figured I was getting a taste of how things worked in the real world.
In my life as an academic, the one thing I've repeatedly observed is that the disconnect between people doing research and people directly applying that research is huge. Seriously, what does one have to do? It's not like we're trying to educate end-users here -- root CA's are in the business of staying on top of this stuff. Sheesh.
Edit. The talk video is available at http://tinyurl.com/a9754t but it's kinda slow right now.