Short Bytes: HSTS (HTTP Strict Transport Security) is a recent development to enhance security on the internet by forcing web browsers to access websites only over an HTTPS connection. An HTTP header is sent by a website to the browser to enable HSTS security policy. This prevents attacks like cookie sniffing, MITM using SSL stripping, etc.
HTTPS has been brought into existence to overcome this issue. The HTTPS protocol ensures that the data transmission between an end user and a website occurs over a connection encrypted using the Transport Layer Security (TLS). However, this is not a foolproof solution because the HTTPS hasn’t been deployed by a considerable number of websites on the internet.
What is HSTS?
Google recently announced that it will implement HSTS on Google.com and its other services. HSTS is HTTP Strict Transport Security. It is a security feature which forces your web browser to access a website only using an HTTPS connection.
Published on November 19, 2012, the HSTS specification (RFC 6797) was originally drafted by a PayPal employee Jeff Hodges along with Collin Jackson and Adam Barth on September 18, 2009.
The specification finds its roots in the research paper “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks” authored by Jackson and Barth. HSTS also finds motivation from the Hodges’ and Andy Steingrueble’s research paper “The Need for Coherent Web Security Policy Framework(s)” published in 2010 which was a sight of improving web security.
What is the need of HSTS?
When you access a website which has implemented the HSTS policy, the website can ask your web browser to use HTTPS connection. This can circumvent various attacks which can be performed over an HTTP connection. For example, the attacks involving cookie sniffing and eavesdropping. The man-in-the-middle attacks involving SSL-striping can be stopped by the implementation of HSTS.
Recommended: What Is The Difference Between HTTP And HTTPS?
How is HSTS Enabled?
The activation of the HSTS policy is simple. When a supported web browser connects to a website, it sends the following header to the web browser:
The header mandates that the web browser will access that particular website using an HTTPS connection. However, there is a catch in the picture. The web browser will follow the header instructions if the first visit made to a website is over an HTTPS connection. This means the web browser will ignore the header if the first visit to a website is made over an HTTP connection.
The max-age parameter specifies the time (expireTime) until the web browser should follow the header’s instructions. The expireTime is written in seconds.
For example, if the expireTime is 3600, for the next 1 hour the web browser will connect to that website over an HTTPS connection ditching any attempt of an HTTP request. After this, it can be accessed via HTTP. However, the websites have the ease of changing the expiration time in the header.
The header has an optional flag “includeSubDomains” which is to make sure that the web browser accesses the sub domains over an HTTPS connection, otherwise, they can be accessed over an HTTP connection.
The optional flag ‘preload‘ is added in the header to tell the web browser that the particular domain has to be preloaded. Different web browsers like Chrome, Firefox, etc maintain an HSTS Preload List which contains the name of the domains which want to have HSTS enabled for all users from the first time.
The HSTS Preload list gets frequently updated with new domains and synced with the browsers. It comes handy in the case a user has reinstalled the web browser. Because all the previous HSTS information stored on the computer is wiped out. At least, the domains present in the list are HSTS enabled.
Shortcomings of HSTS
HTTP Strict Transport Security seems to be an effective solution to achieve security over a connection. And it is, but it has some disadvantages also. The thing that the HSTS header is only accepted over HTTPS can open the doors for the attackers. The very first request to the website, if made over HTTP, could leave the user prone to security threats and unauthorized redirects. That’s where the HSTS Preload List comes in as a savior. But the fact is the domain names should be submitted to be included in the list. It won’t help if the new domain isn’t in the list. And, of course, the preload can’t include every domain name on the internet.
Also, there are some privacy issues associated with the implementation of HSTS. It can be used to know the identity of the users without using cookies. Your web browser knows whether to use HTTPS or not for a particular website in its cookie. This simple information can be used to store and retrieve information on your computer.
An attacker can make you visit a list of websites (or subdomains) on a web page under his control and send HTTP headers for them. Some of those headers will ask you to use HTTPS and some will not. The information, whether yes or no, is stored in your web browser’s HSTS database and behave as a supercookie.
When the next time you access the same website, the attacker can redirect you to the same websites and cross check the yes and no pattern. Moreover, this works even if you using incognito mode in Chrome.
This method can also be used to store a pattern, for instance, a message can be hidden in the sub-domain names list. The list of the links on the web page can be extended till as much as the attacker wants. So, it can be used to track an uncountable number of people. You can read more about this in a simple explanation by Mark Stockley.
Such issues put a question mark on users’ privacy over HSTS. A possible solution is to clear the HSTS database regularly but this would delete the HTTPS connection information of the websites and also concern the security. In a nutshell, it’s a question about security vs privacy. Which one matters to you more?
Did you find this helpful? Tell us in the comments below.