Busy day at Black Hat
Greetings from Las Vegas. Today we saw two presentations regarding attacks that affect the world of SSL. I'll give you a capsule summary of each and tell you how VeriSign certificates fit in. Lest this post become a tome, the summaries will have to be oversimplified. I'll strive to represent the subjects as accurately as I can.
First up was Moxie Marlinspike, detailing the latest additions to his sslstrip tool. The focus of this presentation was various ways to use null characters to fool browsers and other pieces of relying software into believing a certificate has been issued to a different domain than the one to which is was actually issued. The idea is that the attack would give the online criminal the ability to put up a certificate on what appears to be the exact same domain name as the targeted site. sslstrip accomplishes this feat through a Man-in-the-Middle attack and uses the null-character certificate to create its false certificates on the fly.
I'm pleased to say that none of VeriSign's SSL Certificates on any brand allow null characters, meaning that you can't use any of our certificates in the attack detailed today. While the fundamental problem needs to be solved by the client software that trusts these certificates, we still prefer not to be contributing to the problem. And until these problems are solved at the source, EV SSL is a great interim solution. The detailed attack will not work against EV SSL (as agreed by Mr. Marlinspike during the Q and A session after his talk), which means that sites have the power to defend themselves against null character attacks and in fact all attacks using sslstrip.
EV SSL is even a viable defense against null character certificate attacks launched against non-customer-facing systems. Marlinspike discussed the possibility of using this attack against the auto-update functionality that's prevelent in desktop software today. If these updates depend exclusively on SSL to confirm their veracity, a null character certificate can work there. Marlinspike suggests code signing as the solution to this problem (and I agree that code signing is a good solution). It happens that employing EV SSL on this update functionality would solve the problem as well.
After this session I rushed off to watch Dan Kaminsky present his own set of SSL tricks. Kaminsky covered several topics which had SSL as a common theme. Interestingly, he also revealed his own work with null characters, which was very similar to Marlinspike's. In addition, Kaminsky talked about pre-image attacks against MD2, which he expects to be viable this calendar year. He reports that MD2 is not trusted or soon to not be trusted on these applications and platforms: Firefox, OpenSSL, Red Hat, Opera, Apple, Microsoft, Google, and VeriSign. Here I can be more specific. As of May 2009, VeriSign is issuing its SSL Certificates on all brands using SHA-1.
Kaminsky also described a "leading zero attack," by which a certificate can fool client software by essentially attaching an invisible zero to the first hex character in the certificate. Again, I'm happy to tell you that VeriSign won't issue SSL Certificates with leading zeros on any of our brands.
Kaminsky had some other topics such as smart cards and the challenges in running a secure CA that probably don't need discussion in what already is a long post. I'll get into those if there's demand. He closed with his thoughts on the EV SSL iFrame attack scheduled for discussion tomorrow. He echoed my earlier comments that we need to keep straight which part of the infrastructure is under attack if we want to fix it and that we still need green address bars to help with the serious business of protecting against the classic phishing attack. To quote him directly, "All [EV SSL] handles is semantic collisions, but the semantic collisions are really important."