Thanks for the details DK! --Manny
On Wed, Dec 31, 2008 at 10:35 AM, David Kaiser <[email protected]> wrote: > 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 > > _______________________________________________ > LinuxUsers mailing list > [email protected] > http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers >
