Earlier today, I posted a little too quickly. Before caffeine had taken effect. I wrote " I.e., phishers will be able to create their own signing certificate and make it's signature match the signature of a legitimate signing certificate from Verisign." That was wrong. That's not what the vulnerabilities in MD5 and SHA-1 will allow. It would be really, really bad if it were the case, because such forgeries would be completely untraceable, but it's not the case. There is still, however, a significant problem, and now that I'm back from dropping the kids off at camp I need to set the record straight.
What I should have written, and what I would have written if I hadn't posted before all neurons were awake and firing properly, is that phishers will be able to take a valid server certificate, issued by a legitimate CA,and modify it without invalidating the CA's signature. I.e., they'll be able to take a certificate that was issued for a server www.evildoers.com and change the identifying information within the certificate so that it says it is www.goodguys.com, and web server software configured with that certificate will send SSL packets that look like they come from www.goodguys.com. Substitute "paypal.com" or "bankofamerica.com" for "goodguys.com", and you'll see how dangerous this will be.
The reason I can say with some assurance that this will happen is that since last year when I had reported that SHA-0 and MD5 were broken, and since February, when I reported that the SHA-1 hash algorithm was broken, two significant things have happened. One is that (via Bruce Schneier) the paper that describes the cryptanalysis of SHA-1 that leads to the method of creating hash collisions has been published. And the second is that (via Ned as well as Schneier) a technique for generating practical MD5 collisions has been demonstrated. By practical, I mean that two files with different content but the same signature have been generated, and both files contain plausible content. If someone looks at the actual byte stream of the forged file, it can be detected, but if someone just launches it there is no appearance of any tampering. In this particular case, it was done with PostScript files and features of the PostScript language are used to hide the tampering in the PostScript output. The thing is, I now see no reason why it couldn't be done with X.509 certificates because first of all there are a number of ways to put optional information into a certificate file, and browsers may not display some of that information allowing tampering within that information to be effectively hidden, and secondly because nobody actually clicks on the padlock to view certificate information anyhow.
What this all means is that there will be imposter servers out there with certificates that were signed by Verisign but then indetectably altered. These cerfificates will not have the same private key as the server that they are pretending to be, but it won't matter because there is no directory of server public keys for SSL to check against. Verisign will have a record of who received the initial certificate, but nobody will know who altered it. I single stolen server certificate will be able to morph into any number of unrelated imposter servers. It's just a matter of time now. Scary!
Now that I've got that straightened out, I can move on to the implications for Notes and Domino, but once again I'm going to delay it to another post. Many things to do right now.
1. vesoftware11/05/2013 11:03:45 PM
Agen Bola Promo 100% SBOBET IBCBET Casino Poker Tangkas Online
ITUPOKER.COM AGEN POKER ONLINE INDONESIA TERPERCAYA
alfaonline.com : Toko belanja online murah, Promo heboh jual barang hanya Rp 1,-