I don't know if anyone saw the news yesterday, but there is now the possibility to do a real Man-in-the-middle (MITM) SSL attack - without the targets browser suspecting anything or showing a warning.
See these articles: http://blog.wired.com/27bstroke6/2008/12/berlin.html http://www.tgdaily.com/html_tmp/content-view-40765-108.html And here is the output from the security researchers: http://www.win.tue.nl/hashclash/rogue-ca/ (An awesome and well-documented report - I'd recommend anyone interested in SSL read this.) So - for the folks at home - here's a nice simple explanation of what was just accomplished. Most script kiddies, like Dan Tentler, run tools like Ettercap to do ARP spoofing, and put themselves between you and your router - they become the so-called 'MITM' and look for information they could use against you (like your passwords) without you knowing it. That's typically only good for plain unencrypted communications. That's why SSL was invented (and SSH for interactive sessions.) The 'S' in Ssl, Ssh and httpS has stood for 'Security' because these protocols provide a layer of "transport security" meaning the information might be raw or plain-text but it is transported over the network in encrypted form. These secure transport layers accomplish this by providing end-to-end security, where only the client and server have a negotiated set of keys. The SSL encryption/key system builds upon something called PKI, basically the server has a private key which includes a large random number that takes quite a while to generate - and the client has it's own private key - and they negotiate by accessing each other's public key and using it to exchange information that is encrypted only for each receiver. The PKI scheme in SSL allows for different forms of crypto keys to be used, such as MD5, SHA-1, or SHA-256, for example. When Dan set out to steal people's passwords, he ran Ettercap which did ARP spoofing, but since his machine was acting as the man in the middle - it couldn't handle SSL protocol - because of this PKI system guaranteeing that Chris's client and the google server would do a key exchange and prevent the MITM from seeing anything. Dan got Chris's password on Saturday night because his machine was issuing _Invalid_ SSL certificates. This is why most browsers will stop and put you through several screens of nagging dialog boxes when they encounter an invalid certificate. And, honestly, you should never ever accept an invalid cert unless it is one you generated and placed on your own machine. (Chris's SSL Client in this case was not a browser, but was the Pidgin IM client - and it probably needs some UI/design work where it comes up with a very strongly-worded dialog box that makes you type a captcha or something to continue.) So - back to the great hack I read about yesterday. How were these researchers able to "break" SSL? They were successful in generating a completely valid (to all browsers) SSL certificate for whatever domain name they wanted to. If they wanted to give you a certificate for Amazon.com, they could. Then, they could be seated right next to you and acting as a MITM on the network, waiting for you to sign in to amazon.com and your browser would Trust that it was talking in a secure fashion to the Amazon.com server. The flaw that they took advantage of was that the MD5 encryption is not fail-proof. Since MD5 is a hashing function, there exists the chance that more than one input can provide the same hash. The presence of multiple keys that equate to the same hash is called a collision. The SSL hackers built a cluster of 20 PlayStation 3 gaming consoles and programmed them to start spinning through generated MD5 keys and evaluating the hash until it was equal to one of the pre-existing ones that is already trusted by your browser. They were able to generate an SSL certificate that appeared to be trusted as if it were signed by Verisign, since Verisign signs their certs with an MD5 key. Why does this matter you say? Well, if these guys were able to do this - someone else has already started - and I expect within another 5 or 6 months someone with less scruples will succeed. Someone could generate a bunch of certs which expires in 2525 or something - and they will be generating them for wellsfargo.com, bankofamerica.com, chase.com, etc... I expect that once someone can generate a key that can sign any cert with - that it would only be a matter of time before that key was traded around the internet in hacker chat rooms, or bought and sold on a black market. It wouldn't take everyone having to build the cluster of PS3's to do it - someone will do it once and then start selling it - eventually every script kiddie like Dan Tentler will just download an ISO and boot an image and have a pre-loaded and pre-configured set of keys and a suite of cert generation tools to try and grab your encrypted information by just launching an automated process. So - what to do? Well, I suspect most major CA's will regenerate their certificates authority keys with SHA keys instead of MD5. But it could be quite some time before sites re-issue their certs based on SHA. (I have some to do.) I am also going to investigate configuring my Firefox browser to not accept MD5 keys for SSL, and require SHA keys only - this is a huge impracticality since many SSL sites are still on MD5. But, at least I would know not to disable that check while using a public internet connection - only go to sites with an MD5-based cert while I'm on my home connection or something. BTW, I am impressed that the researchers did this with their computer clocks set to 2004, and they generated their certificate to expire in 2004 - so while they haven't released their cert, if it somehow got out, it is extremely unlikely that your browser would ever trust this key unless your clock was off - way off. (The key that generated that cert however - it has no expiration...) Okay - enough of my random thoughts. Read the articles above for more info on MD5's failure and what could happen with browsers trusting bad SSL certs. DK On 12/28/2008, "Manny" <[email protected]> wrote: >Aye! What he said! > >Question: So with a "mitm" attack even ssl (https) isn't safe? The >person doing the attack can see encrypted passwords? > >--Manny
