Slashdot Mirror
CCC Create a Rogue CA Certificate
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."
It could be a rogue communist CA. That way, they're both!
Knowledge is power. Knowledge shared is power lost.
I'm not familiar with the details of certificate use, but as far as the cryptologic component there seems to be a reasonable fix, that will not require any change from end-users or invalidate existing certificates (apart from changing the hash).
The attack is based on finding a hash collision between certificates A and B, having the CA signing A, and using the signature for B. If the CA were to make a small change to A before signing it the attack would be foiled, since it requires active participation from the CA.
Suppose the CA started to add a few random bits to each certificate before signing it. The applicant is told what these bits are, so that they can use the signed (modified) certificate to verify themselves to users. With just a few extra bits this would make the attack unfeasible. Does this make sense?
That's a nice piece of work. I'm very impressed.
Practical conclusions:
This is just to head off the inevitable screaming of "MD5 is broken for everything anyway!!!".
Why head that off when it's a perfectly valid criticism? MD5's been out of date for a few years now and it's been broken for nearly that long. Using MD5 eliminates the CA's credibility.
People need to be trained. If somebody claiming to be your bank calls you, ask at which extension he can be reached from the number you have for your bank, and call back. Simple.
Go green: turn off your refrigerator.
Of all the industries that are slow to implement change in cryptographic practices, banking is by far the slowest. Part of this is bureaucratic inertia, part of this is lack of trust of newer algorithms until "proven" safe, and still part of this is reliance on legacy HSMs in their server facilities. Even the NSA has mandated a faster transition to better crypto (e.g. Suite B) than banking. Banking is still using 3DES instead of AES128, although for practical purposes brute-forcing 3DES at 112 bits of effective security isn't that much worse than AES' 128 bits. Banking won't move quickly unless someone starts stealing many thousands of high-profile accounts, but it'll be a bit like a buffalo stampede.
Still, it's mind-boggling that MD5 is still in use by anyone at this point given that it is susceptible to collisions. NSA Suite B is very clear that SHA2 256 is the minimum acceptable hash, and so it should be elsewhere regardless of your symmetric or asymmetric crypto. Back in the day when RSA512 was still used for PKI because of limited computing power, there might have been an excuse to stick to MD5. And yet, we all moved on to RSA1024 and RSA2048 because RSA512 was broken too. SHA2 is free, and it works. It really is time to move on from MD5 for all uses.
Funny enough that the entire security of the Internet as most users see it is based on the MD5 hash of the browser binary...
Very true. Studies have shown that people want to be helpful and will give up information they shouldn't. And all good crackers know to attack the weakest link in the security chain - the user. The most complex lock in the world will not help you if someone hands the keys over to the "bad guys".
"But this one goes to 11!"
I know, what if they just installed secured computers which allow exclusive access to their system, in various locations throughout the country so there was always one near by!
They could even install cash dispensing devices to allow you to withdraw funds from your account, maybe call them Automated Teller Machines or something along those lines. Wow, I should totally patent this idea
I don't think banks will be using MD5 at this point in time.
That is not important. CAs that use MD5 for their cert signing are already in the browsers list of trusted CAs. It is not important what CA the banks use for their own certs for this attack to work.
I just don't trust anything that bleeds for five days and doesn't die.
If the certificate is imported into the browser as a trusted certificate you don't get the warning, that's the point.
The invalid warnings are for when the certificate has been sent over an untrusted connection and you have no assurance that the certificate is the correct one for the site. In this case, flashing a huge warning in the user's face is absolutely the right thing to do since at the moment, all legitimate online shops have a certificate verified by a third party.
The trusted third party solution we have currently is the most convenient since it's all automatic and transparent to the user. What we're recently finding is that some of these trusted third parties are not turstworthy.
I wish to remain anomalous
I would myself go to another shop and get a SHA-1 signed certificate (or even a SHA-2 signed certificate for those not concerned with low level browsers). At least your customers will know that there is no man in the middle due to the MD5 issue.
Unfortunately, no, they won't. An MD-5 signed intermediate cert can quite happily issue certs signed with SHA-1. (They did just this as part of their testing.) There's no requirement for the signing chain to be signed with the same algorithm.
The fact that your end certificate is SHA-1 signed really doesn't mean anything to the end user. If your cert is MD-5 signed, all that could possibly mean is that your CA at one time did something stupid. Whether it is still doing that stupid thing (or already did that stupid thing for an attacker) is something that the end user has no way of knowing...the end user really is basically screwed here.
If the certificate is imported into the browser as a trusted certificate you don't get the warning, that's the point.
The invalid warnings are for when the certificate has been sent over an untrusted connection and you have no assurance that the certificate is the correct one for the site. In this case, flashing a huge warning in the user's face is absolutely the right thing to do since at the moment, all legitimate online shops have a certificate verified by a third party.
Huge warning Yes; Incorrectly-worded warning that passes judgment on the cert before the user even wonders if it can be verified... NO.
The old behavior used a big warning without condemning the cert. Unfortunately it gave the used an option to just accept the cert and make a connect without even viewing it.
The correct change to make IMO would be to remove the "Continue" button and instead force the user to import the cert before continuing with a connection. Then the certs would be handled more like SSH keys; an attacker would have to maintain constant MITM from the user's first login in order to fool them - very unlikely.
More than that, the browser could show th SHA1 finger print in any/all cert warnings. This would encourage banks, merchants, etc. to start printing their fingerprints along with their URL on bank statements, invoices or other correspondence, facilitating a strong out-of-band verification.
The trusted third party solution we have currently is the most convenient since it's all automatic and transparent to the user. What we're recently finding is that some of these trusted third parties are not turstworthy.
I agree. But the transparency is bad in this case because the responsibility can only ever be in the user's hands; the web would have to become rigidly authoritarian otherwise. People need to be able to handle keys responsibly in the digital world as they do in the physical one. PC systems should make certs and keys more tangible to end-users, letting them grab, move, examine, collect and most importantly recognize them in a heartbeat. It should be possible to designate a flash card expressly for storing certs/keys and passwords to be carried around in one's wallet, purse or keychain.
Probably wears 'em.
This is exactly what I do. When a bank or CC issuer calls (usually to verify a purchase) I call the number listed on the back of the card, not the number left in the message.
There is very little future in being right when your boss is wrong.
If you RTFA you'll note that there is only one known CA that is really vulnerable to this attack, RapidSSL (and also FreeSSL which is part of RapidSSL). This is due to the necessary timing of the validity period and the sequential serial numbers used by the CA.
Also of note is that it doesn't matter what encryption was used to sign the root cert, what matters is the type of encryption that the vulnerable CA uses to sign *your* cert. The CA's certificate could be signed with MD5, SHA1 or anything, really.
Windows is a bonfire, Linux is the sun. Linux only looks smaller if you lack perspective.