We are pleased to announce that HTTP Strict Transport Security (HSTS) (RFC 6797) has been added to our ever-growing list of security features. It can now be enabled for all Enterprise, Business and Pro customers by going to Site > Settings > General > Site settings > SSL Support, and checking the “Enable” check box.
Read on to learn how HSTS improves your website security and about the HSTS configurations available with Incapsula.
HSTS explained
HSTS is a security mechanism enabling websites to announce themselves as accessible only via HTTPS. It’s among a number of solutions developed to handle the demand for secure data exchanges between browsers and websites. HSTS directly complements the HTTPS Everywhere extension, which converts sites from HTTP to HTTPS.
In using HSTS, all HTTP traffic en route to a website is redirected and served through HTTPS. This policy can be applied to existing and future subdomains so that they are also only accessible through HTTPS.
Additionally, HSTS has the ability to send the initial request to a website as HTTPS, without communicating directly with the server. Located within most browsers, a supported domains list—maintained by the Chromium project—makes this possible.
Today most browsers support HSTS and many sites (see the STS preloaded list) already use the implementation.
How HSTS works
Servers communicate HSTS to a browser as a HTTP response header field, named Strict-Transport-Security. The header comprises three directives; one required and two optional.
The use of additional directives gradually increases the effectiveness of HSTS. It also provides tighter communication security between users and target websites. Each directive requires those that came before it for effectiveness to increase.
The HSTS header appears in the response as follows:
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
The directives play the following roles:
- max-age (required) – Specifies the duration after receiving the Strict-Transport-Security header during which insecure HTTP requests cannot be made to the server. In most cases the max-age value is set to 31536000 seconds—roughly equal to one year.
- includeSubdomains (optional) – Adding this directive extends the HSTS scope to all current and future subdomains. It is important to ensure that all subdomains are able to exchange data using HTTPS, as once this directive is added, they will be forced to.
- preload (optional) – Essentially hardcodes a website address inside a browser. Once an initial HTTP request to a website occurs, the browser finds the requested domain in a preloaded list, and internally redirects it to HTTPS—instead of to the site.
For example, a visit to Facebook using Google Chrome would look like this:
Note both the Status Code and the Non-Authoritative-Reason for the internal redirection.
Adding a domain to the preload list is neither immediate nor automatic. You can add
a domain to the HSTS preload list, provided it meets these requirements:
- The server must have a valid certificate.
- The server must redirect all HTTP traffic to HTTPS.
- All subdomains must serve data over HTTPS only, specifically including the‘www’ subdomain if a DNS record exists.
- The HSTS header must be served on the base domain for HTTPS requests,
and must include the following:- Expiry must be at least 18 weeks (10886400 seconds).
- TheincludeSubdomains token must be specified.
- Thepreload token must be specified.
- If serving an additional redirect from the HTTPS site, the redirect must still have the HSTS header (not that of the page to which it redirects).
Use this form to submit a request. Each submission undergoes a manual review that may take between one and several weeks.
The security benefits of HSTS
There are a number of security benefits to be gained from using HSTS. These include the significant reduction in the ability of an attacker to execute a man-in-the-middle (MITM) attack.
MITM attacks occur when a perpetrator positions himself between a browser and a website, intercepts a communication and alters it so that both parties think they are actually communicating directly with each other.
For example, in a Downgrade Attack, the attacker “downgrades” the secured communication protocol to an older and lower quality form of operation (due to what is called a Backward compatibility). This operation is susceptible to a known vulnerability and can be exploited by the attacker to intercept the encrypted communication in order to do as he wishes.
A widely used form of Downgrade Attack is known as SSL Stripping (also HTTPS Stripping), where an attacker forces the victim’s browser to communicate via HTTP, by “stripping” HTTPS from the URL. As a result, all of the victim’s requests are sent as plain-text, allowing the attacker to collect sensitive data.
HSTS also protects against Cookie Hijacking. This takes place when an attacker “hijacks” the session’s token, typically placed in a HTTP cookie, which is used to distinguish users.
HSTS configuration examples
max-age (only) – As mentioned, once an initial request is sent to a website, it responds with the Strict-Transport-Security header. No insecure requests can be made to the site until the max-age expires.
This is highly effective against MITM attacks, since the ability to tamper with any encrypted communication between two parties is dramatically reduced (as long as the max-age value hasn’t expired).
max-age + includeSubdomains – With this implementation, the HSTS scope extends to all existing and future subdomains.
This directive is very effective against attacks that hijack cookies, which can be executed by setting up a mock sub-domain and tricking users to visit it. Their unique cookie identifier is then stolen and later placed in a browser to access sensitive information belonging to the victim, including their email account.
For this reason alone, it’s recommended that includeSubdomains be implemented as part of your HSTS protection.
max-age + includeSubdomains + preload – This implementation is the most effective, as it provides very tight protection against MITM attacks and SSL stripping.
When the first request is sent to a website, there is still a short window of opportunity to intercept the communication and carry out a MITM attack. This is because a direct connection is established with the server.
This situation can be completely avoided by implementing the preload directive and adding extra protection from any malicious attempts to intercept the very first communication with a website.
This implementation is extremely useful against SSL stripping, as the attacker doesn’t have the ability to tamper with the encrypted communication exchange between the user and server. As a result, there is no possibility of stealing any sensitive data.
Getting started with HSTS
HSTS is now available for all Incapsula Enterprise, Business and Pro customers.
There are a number of configurations, all of which can be changed on the fly. Please contact us with any questions you may have regarding HSTS and how it applies to your website.
Try Imperva for Free
Protect your business for 30 days on Imperva.
