Yes, I forgot to say MD5-RSA. MD5 is the hash - RSA is the crypto algorithm. It's still a hash collision that is at fault. And, I meant to type 200 - not sure where the extra '0' went - but it was in my brain when I was typing.
I think you're right on with distributed computing - or FPGA or a GPU or a cell processor - things like this will be interesting to watch. Makes it much more difficult to just feel safe by looking at a gold padlock on your browser. DK Chris Thomas wrote: > I think I read about this. I think you have a couple of simple miss prints. > MD5, SHA-1 and such are hashing functions and not forms of crypto keys. The > hashes just ensure that nothing has been tampered with. I have to read the > articles again but, what I got from it is they found a collision in the MD5 > hash. So they could genereate a new SSL cert with the same hash. This means > it looks like the cert was never tampered with. Second, I think they used 200 > not 20 PS3's to generate the fake but valid SSL cert. > > In the age of distributed / cloud computing, that's not a lot of computing > resources. I think the people said that it would of cost only $1,500 to do > their research on Amazon's EC2. I'm most worried if someone builds a few > FPGAs specifically teweeked for the researcher's algorithm. Then they could > generate a new SSL cert in near real time; fast enough to make a MITM attack > plausable and to make the end user think the slowness they experianced was > due to Internet traffic or something. > > Chris > > On 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 > > > > > _______________________________________________ > LinuxUsers mailing list > [email protected] > http://socallinux.org/cgi-bin/mailman/listinfo/linuxusers
