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:
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.