By Najaf Ali
TLS (a.k.a. SSL) is the gold standard in security. In theory it's supposed to give you:
- Authentication - So you know that if you see the padlock icon and your address bar says "https://google.com", you're definitely speaking to the real google.com and not someone pretending to be them.
- Confidentiality - A guarantee that any data you exchange over the secure channel will not be vulnerable to eavesdropping.
- Integrity - So that you can be sure that any data you exchange over a TLS connection hasn't been tampered with by a third party.
I'm of the opinion that having TLS on is a good idea and can probably meet the expectations of it that I've outlined above. That is in fact if you're actually using TLS to secure your connection with your clients...
The type of attack that TLS thwarts
It's worth noting quickly what sort of attack TLS is designed to defend against. The attack steps might look something like this:
- Bob vists alice.com
- Mallory is eavesdropping on the network
- alice.com presents Bob with a username/password challenge
- Bob enters his username and password and logs in via a HTTP request
- Mallory intercepts this traffic and captures Bobs username/password combo
This is a simple case of eavesdropping, but of course the attacks can get a lot sneakier than this. Mallory can also modify the traffic as she sees fit, perhaps injecting some HTML into a trusted website that Bob frequents to this effect:
Due to an increase in fraudulent accounts, we're going to need to re-authenticate your account. Please fill out the form below re-entering your payment details so that we can confirm your details.
Credit Card # [ ] Security Code [ ]
Thanks in advance, the alice.com security team.
This is the sort of attack that TLS is extremely important for defending against. You're not really serious about protecting your users if you're collecting sensitive information over a non-secure channel.
The glorious horror of SSL Stripping
In 2009 an extremely smart cookie that goes by the name Moxie Marlinspike explained the idea of SSL Stripping: an attack that takes advantage of the fact that for most websites, the initial connection is made over a regular old TCP connection without any of the above guarantees. The user is then typically redirected to the TLS version of the site.
How SSL stripping works is this:
- As before, Mallory is intercepting all traffic on the network.
- Bob visits http://alice.com
- http://alice.com sends back a redirect to https://alice.com
- Mallory intercepts the redirect and acts as the other end of the TLS session with https://alice.com, sending an unencrypted version of the content back to Bob. Mallory also makes all requests on Bobs behalf over it's TLS connection with https://alice.com.
- As far as https://alice.com is concerned, Bob is using the site over a TLS connection.
- As far as Bob is concerned, he's using the site over a regular HTTP connection. An internet-savvy Bob would perhaps notice the lack of a padlock icon
- Mallory is free to view and tamper with the content that Bob sees as she deems fit.
I would hasten to point out that this completely and utterly nullifies the guarantees that TLS makes about authentication, confidentiality and integrity. It's a relatively easy attack to implement, the open source tools exist and are freely available. It's a matter of getting onto a public wifi network (like one at a hotel or coffee shop) and running two commands at the terminal.
Protections against SSL Stripping
If you think hard about this problem, you'll realize that aside from making all browsers do https connections by default all the time (and then forcing all users on Earth to upgrade to your new TLS-only browser), there is no 100% foolproof protection against SSL stripping.
You can protect yourself from someone trying to run sslstrip on your network by installing the HTTPS Everywhere plugin for your web browser of choice. This will attempt to make all HTTP requests via TLS first and only revert to regular HTTP once that fails.
HSTS (HTTP Strict Transport Security) is a countermeasure to this threat implemented in most modern browsers. When a server sets the following header over a TLS connection:
The browser responds by only ever using https when communicating with that
website for the duration of
max-age. It goes as far as rewriting all http
before following them. Once a browser has the HSTS header set for a particular
website, then that client should in theory be protected against SSL Stripping
attacks when using that host.
Two of my favourite websites in the universe implement HSTS, you should too:
[email protected] $ curl -sI https://stripe.com/gb | grep "Strict-Transport-Security" Strict-Transport-Security: max-age=31556926; includeSubDomains [email protected] $ curl -sI https://github.com | grep "Strict-Transport-Security" Strict-Transport-Security: max-age=2592000
However, the HSTS header can only be sent over a HTTPS connection to begin with. If a user has never visited your website and types out the regular old http URL, they are susceptible to SSL stripping and there's not much you can do about it.