Explain HTTP Strict Transport Security
HTTP stands for Hypertext Transfer Protocol. This protocol is used for communication in web requests. HTTPS on the other hand stands for Hypertext Transfer Protocol Secure. While HTTP doesn’t concerned about encrypting data that is getting transmitted in HTTP Requests and is generally prone to Man-In-The-Middle (MiTM) attacks. An adversary in the network would be able to eavesdrop on an HTTP communication thus making it less secure. Most modern web communication happens through the HTTPS scheme which encrypts the payload.
Redirecting HTTP to HTTPS traffic: Considering the obvious benefit, most modern websites force users to communicate to it only via HTTPS protocol. However, the client (the user browser) may still issue HTTP Requests without using HTTPS. The web server in the ideal case would want to notify/redirect clients to use HTTPS instead of HTTP when accessing their domain. One way to achieve this is:
- The client tries to access the HTTP version of the site. For example, the user enters http://geeksforgeeks.org.
- The server then redirects these requests to a safer HTTPS version. In our case, http://geeksforgeeks.org to https://geeksforgeeks.org.
Problem with this approach: This may sound safer, but in this approach, the server first accepts an HTTP Connection and redirects it to an HTTPS Alternative. As you may see, the first HTTP Request may itself be eavesdropped on no matter where other requests land. Since this is prone to be intercepted, the adversary in the network may even tamper with this redirect to a malicious site instead of a secure version of the original site that the client is trying to access.
HSTS : HTTP Strict-Transport-Security: To solve this problem, one can use HSTS. HSTS Stands for HTTP Strict-Transport-Security. HSTS informs browsers that the site should be strictly accessed via the HTTPS scheme alone and any subsequent calls made to the server should automatically be converted into its secure alternative on HTTPS. Web servers often indicate this metadata information via a response header.
Syntax: The syntax of this response header is:
Web servers indicate the time here till which the browser should remember this decision of forcing all web requests to the server to be made only via HTTPS. It is quite common that information is set to a few years in this response header.
Optional Parameters: This header supports some optional parameters/attributes. They are preload and includeSubDomains.
- includeSubDomains: This attribute, if enabled on a Strict-Transport-Security response header, indicates that this HSTS policy should be applied to the server’s subdomains also. For example, if HSTS is enabled on http://geeksforgeeks.org and includeSubDomains is also set as in the following,
Then the browser remembers that this is applicable to all subdomains of geeksforgeeks.org. So for example, if the user-agent tries to access http://auth.geeksforgeeks.org though being a subdomain would obey this policy and get transferred to safer HTTPS.
- preload: There is; a list of preload domains by the HSTS preload service. Once you submit your domain to this preload services list, your domain will never be accessed by the HTTP scheme by the browser. This is still not part of the official specification, though some browsers follow this.
Browser Compatibility: Fortunately, all modern browsers on the web and mobile currently support HSTS headers and follow this approach. It is also expected that preload would become a standard in the future.