How HSTS works

Let us say there is a website with a domain name “example.com”. If one types “example.com” in a browser to view and interact with the content of a given site, he/she might specify either “http://” or “https://” in front of the domain name in the address bar. However, typically, a user enters only a domain name to the address bar, thus, the initial connection with the server is performed via insecure HTTP. Moreover, if a user is accessing “example.com” for the first time and he/she does not know whether this site is accessible via HTTPS or not, he/she would typically enter just ”example.com” into the browser, which would be inadvertently interpreted as “http://example.com”.

Even if an automatic redirection from HTTP to HTTPS is enabled for “example.com”, there is a strong probability that the initial request sent from a client (web browser or another application) to the server over the plain HTTP, will be intercepted and replaced/modified by an attacker who acts in his interests.

In order to avoid such situations during the next visits to “example.com”, HSTS Policy can be enabled on the web server. Once it is enabled, each and every connection to the server will be performed in a following scenario.

Next time when one types “example.com” in the browser (regardless of whether it is “http://” or “https://”) and sends the request to establish a connection with the website, the server, where the website is hosted, sends to the client a so-called HTTP response containing a new header, which was not present in the previous HTTP responses, – “Strict-Transport-Security” with its own directives.

The “Strict-Transport-Security” header stipulates that HSTS Policy for “example.com” is enabled for a given period of time which is specified in seconds as a directive value in the header field. Once an HSTS-conformant web browser receives a syntactically correct STS header, it performs matching of “example.com” with so-called Known HSTS Hosts – domain names, which have been noted as HSTS Hosts and added to the browser’s HSTS Storage already. If the browser does not find the matching host or the match is found, however, the header is different by any its directive from the one from HSTS Storage, the recently received header is added to the HSTS Storage. Depending on a matching result, “example.com” either becomes a new Known HSTS Host or the existing Known HSTS Host gets updated with recently received directives.

Hence, every new attempt of access to “example.com” via an insecure HTTP connection within the given browser will be automatically switched to HTTPS and the initial request will be conveyed via HTTPS (i.e. HTTP over TLS/SSL) to the server, significantly decreasing the effectiveness of attacks.

The HSTS addressed threats

Let us describe common threats and scenarios in which enabling HSTS could be beneficial:

• A user has added “http://example.com” to Bookmarks in a browser and constantly uses the saved bookmark for accessing the site. If HSTS is enabled, “http://example.com” will be transformed into “https://example.com” immediately after clicking on the bookmark.
• “Click-through security”, which in most cases can be treated as “click-through insecurity”. If there is an issue with establishing a secure connection due to an invalid certificate, a broken trust chain or a mismatch between the domain name in question and the one specified in the certificate, a web browser will typically show a warning, which would give the user a choice whether to proceed or to terminate the connection. HSTS Policy implies that an erroneous connection will be terminated immediately and irreversibly in order to mitigate the possibility for an attacker to manipulate the certificate.
• Passive eavesdropping. A very widespread example is if one, using a public Wi-Fi spot, accesses his/her favorite social network or an online banking account. The device which provides free access to the Internet is configured by an attacker to enforce all HTTPS requests to be conveyed via HTTP and thus to collect unencrypted cookies from the user’s device. In this situation HSTS Policy will shut down the connection due to an attempt of establishing an insecure HTTP session.
• Website deployment bugs. There is a well-known issue of so-called “mixed content”. It occurs if any element within the source code of the given website (e.g. CSS, JavaScript or a simple image) is served via an insecure HTTP connection. Hence, it makes possible for an attacker to use such exploits to upload malicious scripts to the website and control the behavior of either specific pages or the whole site on a temporary or constant basis. Besides the fact that HSTS Policy addresses the threats of this kind, it is highly recommended for web developers to take care in advance of the content of their web resources so that it is served in a secure fashion everywhere it is possible.

The above mentioned list of use cases is not full and can be pretty extensive as the attackers’ imagination and toolkit can produce a wide range of threat models which would require a separate article for their description. To summarize this part of the article, we should emphasize that the most part of known threats is based on a sophisticated combination of social engineering, man-in-the-middle (MITM) instruments and website / web server deployment bugs.