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."
Re:Rouge CA? (Score:3, Insightful)
It could be a rogue communist CA. That way, they're both!
Possible solution? (Score:2, Insightful)
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?
A nice piece of work (Score:5, Insightful)
That's a nice piece of work. I'm very impressed.
Practical conclusions:
Re:No weakness (Score:4, Insightful)
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.
Re:Why trust the PKI? (Score:3, Insightful)
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.
Banking is typically slowest to change its crypto (Score:3, Insightful)
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...
Re:Why trust the PKI? (Score:3, Insightful)
Re:Why trust the PKI? (Score:3, Insightful)
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
Re:Rouge students and some more insight (Score:3, Insightful)
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.
Re:Reality check for Mozilla (Score:3, Insightful)
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.
Re:Rouge students and some more insight (Score:3, Insightful)
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.
Re:Reality check for Mozilla (Score:3, Insightful)
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.
Re:You know what I hate? (Score:1, Insightful)
Probably wears 'em.
Re:Why trust the PKI? (Score:3, Insightful)
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.
Re:Alright this Internet is ruined (Score:3, Insightful)
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.