HSTS and Rails

HSTS

HSTS stands for HTTP Strict Transport Security. HSTS helps in preventing SSL stripping attacks and session hijacking attacks. SSL Stripping attacks are a special type of man in the middle attack (MITM).

Connections start with http

Let's see how a typical request session happens on the Internet.

When a user opens a browser and types a url then browsers, by default, put http in front of it. Then browsers send HTTP request to the server. The server answers via HTTP saying that please send request over HTTPS. The browsers now send HTTPS request.

HSTS ensures HTTPS at the browser level

Every single time when a browser sends a HTTP request and the server sends a 301 redirect response demanding request to be sent over HTTPS there is an opportunity for the SSL strip attack. We will see how this attack works soon.

It would be nice if server could tell browser that not only for this session but for any future sessions also please send all requests over HTTPS.

That's what HSTS does. HSTS tells browsers that for all future requests please use HTTPS for say next 6 months. So now even if user types http://www.ecommerce.com then the browser itself will switch HTTP into HTTPS without contacting server for a period of 6 months.

In Rails when we use force_ssl then Rails not only redirects to https but Rails also sets HSTS headers. The default time period is 2 years in Rails.

What is SSL strip attacks and how it works

Let's say that Harry, the hacker, visits Starbucks coffee shop. Here he created a hotspot named "Starrbucks coffee". Notice that he has put two "r"s in the name of "Starrbucks coffee".

Joe walks into the coffee shop, and he sees that there are two hotspots named "Starbucks coffee". He did not pay attention to the misspelling. Joe connects to the hotspot setup by Harry.

Now Joe opens his notes site www.mynotes.com. Mynotes already has HSTS enabled and Joe visits mynotes.com regularly, so the browser knows to send the request over HTTPS.

In his notes he has a link to www.toystore.com. He clicks on the link to buy a gift for the upcoming birthday party. Since there is no protocol mentioned in the link by default browser sends the request using HTTP.

Request is sent to http://www.toystore.com. Since Joe is connected to the hotspot run by Harry, request first goes to Harry. Harry has setup a proxy. Harry stops the request in the middle and he initiates a brand new request to http://www.toystore.com.

Toystore site sends a 301 response to the client asking the client to send the request over HTTPS. If Harry sends this response as it is Joe then Joe's browser will make a direct tunnel between Joe's browser and toystore.com. That's how https works. It sets a secure tunnel between the client and the server. If there is a direct HTTPS connection between Jeo's browser and toystore.com then Harry would not be able to steal Joe's credit card information.

So this is what Harry does. Harry does not forward that response to send request over HTTPS to Joe. Instead Harry sends the request over HTTPS to toystore.com. toystore.com responds with the login page. Harry takes the response of this page and sends it to Joe over HTTP. So here Harry is taking HTTPS response and stripping the SSL and sending the same response over HTTP. This is why it is called SSL strip attack.

Now Joe fills out the form and submits it over HTTP. Harry does not let this submission go through. He is in the middle between Jeo and the toystore. Harry looks at the data. Puts this data in the form and submits the form using HTTPS to the toystore.com.

The main takeaway is that Joe never sends any data over HTTPS and in this way Harry is able to see all the data because all the data is being sent over HTTP and not HTTPS. In this way Harry is able to steal Joe's credit card information.

How this could have been mitigated.

This was not the first time Joe was visiting toystore.com. If toystore.com would have been using HSTS then all requests to toystore.com would have been sent over HTTPS even if Joe is clicking on a link that says http://www.toystore.com.

However, this mechanism does not solve the problem of first visit. What if Joe has never been to www.tshirts.com and his friends on the chat tell him about it. Even if the engineering folks at tshirts.com have implemented HSTS, the very first request to tshirts.com by Joe at that coffee shop can be intercepted by Harry. To solve this first visit problem https://hstspreload.org was born.

HSTS Preloading using hstspreload.org

Major browsers like Chrome, Firefox, Opera, Safari, IE came together and support https://hstspreload.org/. Any request made to any site listed in hstspreload is always sent over HTTPS including the very first request.

For example "mail.google.com" is in the hstspreload list. It means even if we get a brand new laptop and in the url if we type http://mail.google.com then even for the first visit the request will be sent over HTTPS and not HTTP.

Avoid hotspots at public wifi

With proper tooling mounting man in the middle attack is not very difficult Firesheep is a Firefox extension which makes session hijacking extremely easy.

In response to firesheep we had initiatives like HTTPS everywhere. This is why starting chrome 68 all sites using HTTP are flagged as Not secure by default.

This is also a good reminder that unless absolutely needed please do not connect to the random wifi hotspots. Only connect to known wifi hotspots.