What is HSTS?
HSTS, which stands for HTTP Strict Transport Security, is a mechanism that helps protect our websites against hackers' interventions. It actually informs webs browsers to use a response header and to use it fro and back during the communication.
Once the supported browser receives this response header, then that browser will make sure that communication between the networks happens only in HTTPS rather than HTTP.
Why HSTS is needed?
Over free Wi-fi, if any hacker tries to access information, it can be easily done by “packet-sniffing” if the communication between two devices is done through HTTP.
The devices are not connected to each other so if any two devices need to communicate then they must pass their requests through a series of routers. These routers if had HTTP, then it can be compromised and will be victims of “man-in-middle” attacks.
Even the data transmitted via these connections can be read easily because these are just plain text, which leaves the user in great danger and there is completely no protection for the data shared.
Thus, HSTS forces all connections to pass through HTTPS connections instead of the plain text in HTTP. This will provide the necessary protection and make it impossible for hackers to read or manipulate the data shared between two devices.
Only 301 redirecting from HTTP to HTTPS is not enough for the complete protection of the website. Still, there are chances of capturing the website cookies or even may redirect to their phishing site which looks similar to yours.
How HSTS works?
When a browser finds that a domain has HSTS enabled then it will do two things: 1. It includes https:// even if the user didn't specify a protocol or type http://. 2. It removes the ability of the users to click through warnings about invalid certificates.
The main work of HSTS is to make the visitors use only HTTPS even though their browsers make them to go to HTTP.
- Because when a user types a domain name without specifying the https:// then the browser's default protocol is plain HTTP.
- Or the user may click on old links which have http:// in them without noticing or without prior knowledge of HTTPS.
Actually, without HSTS, even HTTPS using websites still listen to HTTP in order to redirect the user to an HTTPS URL, say in 301 redirects.
$ curl --head http://xyzzz.com HTTP/1.1 301 Moved Permanently Location: https://xyzzz.com/
This is very unsafe and can lead to hackers redirecting you to their own phishing sites or even read your valuable information which will have serious consequences. Here comes HSTS to rescue the sites from attackers by returning the Strict Transport Security header whenever the sites connect securely.
$ curl --head https://xyzzz.com HTTP/1.1 200 OK Strict-Transport-Security:max-age=31536000; includeSubdomains; preload
In this example, HSTS is enabled for xyzzz.com. Even if any user tries to use http://xyzzz.com the HSTS will make the browser issue the request for https://xyzzz.com.
This is the basic syntax of HSTS:
To include subdomains, the syntax is:
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
To include preloading in HSTS, the syntax is:
Strict-Transport-Security: max-age=<expire-time>; preload
max-age=<expire-time> - This directive is mandatory to be mentioned. This is the time in seconds when the browser should remember that a site is only accessed using HTTPS.
includeSubDomains - This directive is optional. This is used to denote that all the subdomains will have the same rule as mentioned.
preload - This is also optional. The preloading is explained in detail below.
HSTS preloading is a list of hosts built onto a browser enforces the use of HTTPS only on their site. This list is called as “HSTS preload list” and was created by the chrome security team. These listed domains get enabled their HSTS automatically even for their first visit.
- In many cases, it will never be the first visit. Say we explore https://xyzzz.com.
- There are, however, many websites that redirect to https://xyzzz.com directly from http://xyzzz.com.
- Several sites redirect users from http://xyzzz.com to http://destination.com. Again, we have a difficult time making the first visit. Hence, preloading is necessary.
The chrome security team allows us to submit our domain to the preloading list, provided meeting their submission requirements.
Their requirements are as follows:
- Must have a valid certificate.
- If you are listening on port 80, redirect from HTTP to HTTPS on the same host.
- You must support HTTPS for the www subdomain if a DNS record exists for that subdomain.
- Must serve an HSTS header for the HTTPS requests on the base domain.
An example of a valid HSTS header is :
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Once the domain is added to the preloading list, then it cannot be easily undone. Even if the domain is removed, it will take months for the change to reach users with a Chrome update. So, it is better to be sure that we can support HTTPS for our domain, including all our subdomains too, in a long term.
- HSTS protects sites from man-in-middle attacks by pointing the traffic to HTTPS.
- HSTS compliant browser aborts the connection if the security of the certificate can not be confirmed.
- HSTS improves the page load time since it eliminates redirects from Http to Https, which is an essential feature for SEO.
Finally, HSTS is necessary for improved security because it provides end-to-end encryption through HTTPS. Since HSTS headers are only valid through HTTPS headers, we can be sure that HTTP won't come in the middle of the transmission.
Once HSTS is enabled for a site, then HTTP won't work. So, we have to use HTTPS for every page of the domain and also for subdomains if we used includesubdomains.
The only small advantage is, those complex websites require little extra time to make these changes. Also if our website certificate is invalid, then access to our website will be disabled if we have HSTS enabled.
If the requirements are properly met, then HSTS is the best security mechanism to protect against attackers.