Black Hat 2009 SSL Review: Breaking the Myths of Extended Validation SSL Certificates (Alexander Sotirov and Mike Zusman)

Sotirov's and Zusman's talk (the paper and the slides available for download) is a practical exercise in breaking the assurance provided by EV certificates, building on the discovery Collin Jackson and Adam Barth made in their paper Beware of Finer-Grained Origins:

Extended Validation. The browser’s scripting policy does not distinguish between HTTPS connections that use an Extended Validation (EV) certificates from those that use non-EV certificates. For example, Pay- Pal serves https://www.paypal.com/ using an EV certificate, but a principal who has a non-EV certificate for www.paypal.com can inject script into the PayPal login page without disrupting the browser’s Extended Validation security indicators...

The above has the following implications:

1. EV sites generally use components that are delivered from other non-EV SSL places. Thus, if you have a valid non-EV certificate in the name of the server used for the component delivery, you can subvert the EV site.
2. Sotirov and Zusman also point out that browsers don't perform SSL certificate pinning, happily accepting a request from a site with an EV certificate, followed by a request from the same site using another certificate. That allows for what they call SSL Rebinding. Through the same-origin policy, a subverted document delivered with a non-EV certificate can assume control of an EV site.
3. They further point that it is possible to perform SSL cache poisoning, which is a side-effect of the caching subsystem in browsers being separate from the security system. For browsers, a file from a non-EV site is the same as a file from a EV site:
   1. A user is somehow lead into requesting a file supposedly from an EV site (e.g., a script file), but the file is delivered by an attacker performing a MITM attack and using a valid non-EV certificate.
   2. The user goes to the real EV site, at which point his browser will attempt to refresh the previously cached script file.
   3. If the EV site responds with an 304 (Not Modified) response, the browser will continue to use the subverted version of the script.

Sotirov and Zusman offer a number of suggestions to fix the above problems, but admit that most of them are not likely to happen. The problem here is that it is the browser vendors who should be pushing the security envelope (no one else is in a position to do it), but doing so would break sites and the vendors, who are primarily focused on winning market share, won't risk breakage. The only realistic solution seems to be to make it possible for sites to elect to be more secure so that, in time, we can upgrade to a more secure Internet.

I still maintain that a comprehensive solution (in a way similar to that I proposed in the Secure Browsing Mode document) is the best way forward. Band aids can only do so much and, for once, we need to do a job properly.