How to render SSL useless
Later today I will be presenting at the OWASP London meeting. The title of my presentation is How to Render SSL Useless, and I will be talking about the recent issues with SSL/TLS, my work at SSL Labs, as well as listing Top 11 SSL deployment mistakes that render SSL useless.
Here's the presentation:





Nice presentation! I guess its even better with the spoken words to go with the slides, but I think I got the message.
Let's say I'm running a standard Wordpress blog. http://example.com is the blog homepage (www. is redirected there with a 301). There is no secret content but an admin or registered user can log in at http://example.com/wp-admin (that's the default url, at least).
Do you have any general advice here? My first assumption is that we would want to protect the admin area (and login) with SSL, but is that doable without having the whole site protected? And what would be the downside (if any) of doing that? Just CPU, or more?
Posted by: Per Wiklander | January 17, 2010 at 02:54 AM
Let's say we don't want to SSL-protect the content part of the site, then I guess I could have an https://admin.example.com (and http is redirected with a 301 there to force https). That should make the session cookies used for admin secure, right? But on the other hand you could still get your comment posting session hijacked on the content-site.
So it's either 100% SSL or a static content free for all and no secrets kind of deal.
I just noticed that my bank uses http://bank.com for the public site and https://secure2.bank.com for the private part (along with various certificates and a physical auth device).
Posted by: Per Wiklander | January 17, 2010 at 03:07 AM
Per, in response to your first question -- it you can't have the entire site under SSL (yes, you'd get slightly worse performance) then make sure the admin area cannot be accessed without SSL and always use a https bookmark to get there.
To the http://admin.example.com idea -- that would work out much better, assuming the admin cookies have the "secure" flag on them and that you, again, access your admin area directly.
Posted by: Ivan Ristic | January 18, 2010 at 08:56 AM
nice one
Posted by: Christian Folini | January 18, 2010 at 11:54 AM
Here's a practical example of misconfiguration I encountered. It is part of your categories 3 and/or 10.
I had many difficulties convincing the developers and architects they were doing it wrong: when posting a form (for example with the site credentials), not only the form destination has to be in SSL, but also the form! If not, the credentials are sent to a not-yet-trusted site, as they're switching for HTTP to HTTPS.
Then of course, they need two different session mechanism, and a secure cookie.
Posted by: David Mathy | January 18, 2010 at 02:24 PM
Nice presentation Ivan!
Another thing that we see often (Frank Heidt of Leviathan pointed this out) is even on the https site, often there are things which return a redirect to an http! For example, a "search" box on a bank's site was seen to return a redirect to results from a search appliance. This is all it takes for the user to end up in an SSLStrip scenario, or redirected to a typo phishing site with an actual valid cert.
Posted by: Marsh Ray | February 20, 2010 at 03:23 PM