CCC Create a Rogue CA Certificate 300
t3rmin4t0r writes "Just when you were breathing easy about Kaminsky, DNS and the word hijacking, by repeating the word SSL in your head, the hackers at CCC were busy at work making a hash of SSL certificate security. Here's the scoop on how they set up their own rogue CA, by (from what I can figure) reversing the hash and engineering a collision up in MD5 space. Until now, MD5 collisions have been ignored because nobody would put in that much effort to create a useful dummy file, but a CA certificate for phishing seems juicy enough to be fodder for the botnets now."
Why trust the PKI? (Score:5, Interesting)
Why does your bank not give you a compact disc with their public key on it when you sign up for an account?
Still using MD5 for this ? (Score:4, Interesting)
its only the CA's that use MD5 so the question is. (Score:3, Interesting)
some CA's use MD5 the question really should be which ones
they point to a rather doomsday scenario of having a problem with all SSL Certificate Authorities
this is not the case
only the ones that use MD5
so the question really is what is the list of SSL Certificate Authorities that do this ?
regards
John Jones
http://www.johnjones.me.uk [johnjones.me.uk]
Re:Why trust the PKI? (Score:3, Interesting)
Sounds like a great plan to me. Plus have a "Use only my bank's CA" mode built into your browser so you know damn well it's them and nobody else.
Re:No weakness (Score:3, Interesting)
Brute force? Not according to TFA:
In the interest of protecting the Internet against malicious attacks using our technique, we have omitted the critical details of our sophisticated and highly optimized method for computing MD5 collisions.
It says they compute collisions, which is indeed a weakness in MD5. Even if they use brute force, the fact that it's forceable is still a weakness.
Now, MD5 still probably makes for a pretty good checksum for utilities like Tripwire and such, but for security it's broken, broken, broken.
Re:Alright this Internet is ruined (Score:4, Interesting)
Re:Why trust the PKI? (Score:3, Interesting)
"This is Mr. Soandso from &BANK NAME&. We have had a recent error in the code cards and would like to verify that you have one of the ones that is not a problem. Could you read line &LINE NUMBER& to me so I can check to see if you have a valid code list?"
Sure it is a little extra effort, but not so much that nobody would attempt it.
Reality check for Mozilla (Score:5, Interesting)
First, this issue is about banks (for instance) verifying themselves to the client, not the other way around, so not sure how OTPs and such figure into this.
Overall, between the drama over one of Comodo's trustee CAs handing out certs without verification (for mozilla.com no less) and this MD5 attack, there is a lesson on this for Mozilla:
Trusted CAs aren't the epitome of web safety. In fact, they are LESS safe than one of those "Invalid" (to use Mozilla's ill-chosen words) self-signed certificates under some circumstances.
I put the ranking of https safety as follows:
1. Any self-generated cert (even self-signed) which has been directly copied from the service provider (bank, etc.) and imported into the browser.
Though this is the most secure, it is a shame that the user may receive warnings from other Firefox users who visited the site about the cert being "Invalid", undermining confidence in this most secure method of using certs.
2. Any self-generated cert (even self-signed) verified by SHA1 fingerprint "out of bank" (e.g. letter or phone call or even email) then imported into the browser. Unfortunately the easiest method to initiate this procedure (visit the site, verify then click on a button to import) is now somewhat broken in Firefox and will quite inappropriately undermine the user's confidence in what is otherwise a very secure cert.
3. Relying on the browser-trusted CAs. Unfortunately there now many of them which are obscure even in the tech community, and some are sloppy and incompetent.
Maybe a Firefox config setting (Score:2, Interesting)
Wouldn't setting security.ssl3.rsa_rc4_128_md5 to false prohibit these kind of attacks?
collision attacks are easy to identify (Score:5, Interesting)
note that the collision attack requires a bit of junk in the cert to make the hash be the same as for the original... this means the junk will not look like the rest of the cert. the rest of the cert is formatted and the collision noise will look mostly random. a simple test for unexpected randomness in the cert data (including Netscape comments) would reveal this sort of mischief. it just takes a bit of code on the browser to look for it. shouldn't even degrade browsing performance too much.
Mod parent up (Score:1, Interesting)
Constraining the content allowed in certificate files should improve the robustness of certificate files.
This approach is notable in that it requires updating SSL implementations to be more stringent -- but it generally shouldn't require changes in the x509 data. Some considerations:
IANAPC,BIRACBBS!