[Last updated: January 2021] When I first read about HSTS, my first reaction was, "What's this? A replacement for HTTPS? Considering the ubiquity of HTTPS, shouldn't we be working to improve it first instead of replacing it?" Turned out, my initial understanding of HTTP Strict Transport Security was off the mark.
The HTTP Strict Transport Security or HSTS (specified in RFC 6797)isn't really a separate communications protocol meant to replace HTTPS. Instead, it's actually a mechanism that forces the proper use of HTTPS and mitigates some serious vulnerabilities. To better appreciate the benefits of HSTS, it would be a good idea to discuss those vulnerabilities first.
Vulnerabilities in using HTTPS
As the secure counterpart of HTTP, HTTPS leverages the security features of SSL/TLS to provide data-in-motion encryption, server and client authentication, and data integrity. But in order to take advantage of these security features, the web client (usually a web browser) must first indicate its desire to communicate via HTTPS. To do so, it would have to include "https://" in each request to the web server likeso:
However, most users rarely ever specify the protocol (i.e. http or https) when they try to access a web site or web page through a browser. For example, to access http://www.sampledomain.com, a user would mostly likely just enter either of the following on the URL bar:
This works because all popular browsers are able to anticipate what the user wants to do and simply add the protocol. So if, say, you type in www.jscape.com on a Firefox, Chrome or Internet Explorer URL bar, the browser will automatically send the request for http://www.jscape.com to the web server.
Note that what's normally sent by the browser is http:// and not https://. Thus, if you won't explicitly order the browser to connect via https, it will simply connect via http by default. So how will your connection be secured by SSL/TLS if that's the case? Well, if your web server has been set to redirect HTTP requests to HTTPS as shown below, then after initially connecting via HTTP, all succeeding transactions within the same session will be done over HTTPS.
Pretty neat, huh?
Yeah. Except for one thing.
Remember that the browser (if no protocol is specified by the user) will initially have to connect via HTTP all the time. There is no way the browser will be able to remember that a particular domain should be connected to via HTTPS. Even if a browser has already connected to a domain over HTTPS, that doesn't mean it will already automatically send succeeding requests via HTTPS when it connects again the following day, week, or month.
That opening (wherein browsers have to inititally request via HTTP) is all a malicious hacker would need to launch a man-in-the-middle (MITM) protocol downgrade attack such as SSL-stripping.
In attacks like this, the MITM attacker intercepts traffic between the client and the server, alters the messages, and deceives both parties into thinking they're still communicating with one another. The attacker communicates with the server via HTTPS while communicating with the client via HTTP.
Because messages sent via HTTP are just in plaintext, the MITM attacker could easily grab whatever information is sent out by the client, including passwords.
Related post: Countering Packet Sniffers Using Encrypted FTP
How HSTS helps
When a web server implements and enables HSTS, all browsers that connect to it will be forced to do so strictly via HTTPS. That means, there won't be that exploitable vulnerability wherein a browser would initially connect via HTTP before it gets redirected to HTTPS - except for that very first instance that the browser makes contact with the web server.
Let me explain how it works.
When a browser makes its first ever HTTPS connection (perhaps after the user explicitly enters https on the URL bar or via HTTP-HTTPS redirect) with a web server that has HSTS enabled, the server will respond with the response header field: "Strict-Transport-Security".
When any HSTS-capable browser sees this field, it will make all succeeding requests to this server strictly via HTTPS. It will continue to do so for as long as the max-age is not yet exceeded.
The max-age, which you can see in the screenshot above, is the duration over which HSTS will be enforced by this server and a web client. This value is specified on the Web server. The max-age is specified in seconds. So, for example, if you would like HSTS to be enforced for a period of one year, then you would set the max-age to 31536000 seconds.
That means, if a browser has just received the Strict-Transport Security field from this server, and it (the browser) attempts another connection the following day, week, or month (or 11 months later), then it will automatically send each URL request in HTTPS.
What's more, even if a user (using the same browser in question) clicks a http hyperlink that points to a resource under the same domain, the corresponding request will still be sent via https.
If you have a keen eye, you might have noticed the parameter "includeSubDomains". That simply means, the Strict-Transport-Security will be applied to all subdomains as well.
Enabling HSTS on JSCAPE MFT Server
To enable HSTS on JSCAPE MFT Server, just go to Settings > Web > Web tab > Connections and then tick the Enable HTTP Strict Security Transport (HSTS).
This would enable HSTS for all web file transfer services. If you wish to enable HSTS for all connections to your administrative web interface as well, just enable the same option in Settings > Web > REST tab > Connections.
If you click the HSTS settings button, you may specify the max-age as well as whether to include subdomains. That's it. Now you know what HSTS is and how to enable it on JSCAPE MFT Server.