What is HSTS
Further reading
How to prevent your website from a hack
A General guide to Safe Website Updating
Step by Step Approach to Password Protect a Directory in cPanel
How to check your PHP version and configure your PHP settings
7 Security Tips for a WordPress Website
Basic Guide to WordPress Security
How to Fix a Hacked WordPress Website
How Secure is Your Joomla Website
How to Fix The Joomla White Screen of Death
Origins and adoption
HTTP Strict Transport Security (HSTS) is a is a web server security mechanism that tells browsers how to handle connections made to it via an instructional header. As an important addition to HTTPS and global security of data, HSTS has been in the woodworks since the second half of 2009 but the majority of progress has come in the last 2 years. Already implemented by big players like Google, Facebook, Twitter and PayPal HSTS is also enabled on all of our shared servers to compliment the rest of the security features we offer.
Why MITM shouldn’t be taken lightly
Man-in-the-middle (MITM) attacks are still an unknown matter to most regular users, even when the same have been targeted by such attacks during their everyday digital presence. Flying under the radar is part of the problem and we believe that knowing what you might expect from public Wi-Fi networks can significantly reduce unwanted data exposure online. The most common practice is to have hacker spoofing a Wi-Fi hotspot with him standing between a user and the router. Now imagine that this user wants to access your website. Even if the connection from the router to your website is secured via the HTTPS protocol, the hacker can strip the SSL, obtain and change unencrypted data from the user before encrypting and sending it to the router. This way the user has no idea his data is being accessed on the fly which can lead to all sorts of malicious scenarios. These sorts of attacks can be mitigated using HSTS to force the browser to only use HTTPS when connecting to your website from the get go.
HSTS and A+ Grade on SSL checks
The idea of SSL checkers is not only to see that you have SSL issued for your domain, but also how to optimize the security for that domain. SSL Checkers like SSLLabs take into consideration a plethora of options and vulnerabilities covered by different versions of TLS, Cipher strength, key strength etc. to provide an adequate representation of the strength of your SSL in a grade system from F to A+. Activating a Let’s Encrypt from your cPanel will get you to an A Grade. The only thing missing in order to get a perfect score of A+ is to have HSTS enabled as like we mentioned in the last paragraph, without it MITM are still a possibility. Once you have enabled it, the SSL covering your domain will be considered fully optimized and you will get the perfect score for it. And we all love perfect scores especially when we talk about security.
As there will always be a tug of war between Security and Malicious intents, it is to be expected in the future to build on upon HSTS and HTTPS and make them even better. However, for now this is the current peak of hardening you can achieve in this layer of security and it is worth the extra time to enable it for your websites.
How to Enable HSTS
Enabling HTTP Strict Transport Security (HSTS) is a simple process that involves only adding a few lines with directives in the .htaccess file of your website. As a user types your website, and the browser sends a request to the server on which your website resides, the header which we will add to your .htaccess file will tell the browser that it should connect via HTTPS by default and remember this setting for the future depending on the number of seconds we put in the max-age directive of the header. In our case, we will add 31536000 seconds which amounts to one year, so if a user doesn't clean his browser's cache, that browser will connect him to your website via HTTPS by default for a period of 1 year. Alternatively, there are options to do all of this via plugins much like the premium version of Really Simple SSL for WordPress.
To add the header to your website, login to your cPanel account and navigate to the File Manager icon.
Now navigate to the directory of your hosting account in which your website resides. For most of you this will be /home/user/public_html, or if you are using a subfolder, you will also have to enter it to find your website files. Locate the .htaccess file, right click on it and select the Edit option.Now add the following lines at the top of your .htaccess file:
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000"
</IfModule>
To make it also compliant with the preload list requirements you need to add includeSubDomains and preload directives:
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>
So now it should look a bit like this:
Note that for our example we are using a WordPress based website with the WP Rocket plugin enabled thus the extra lines of code in our .htaccess file. Also, don't forget to hit the Save Changes button at the top of the page and you are done.
You now know how to successfully enable HSTS for your domain.
How to Disable HSTS
If you encounter an issue with HSTS before you add it to the preload list and cannot access your website fully due to reasons like expired SSL certificate or mixed content, you can disable HSTS in order to load the website and find a resolution for your issue.
The actual disabling of the tag is easy and can be done by changing the max-age directive from 31536000 to 0 which will make it expire at the moment it activates. For more information on how to find and edit the .htaccess file and the header, please check our initial tutorial called How to Enable HSTS.
This only change the max-age is better than just removing the entire header from your .htaccess file since when the tag was first read and cached by the browser it, the max age was applied, and the browser was instructed to cache this header for that period. By changing the max-age to 0, you are re-instructing the browser to essentially neglect the entire header without further caching.
However, as browsers were updated with HSTS in mind, some of them will still have the header's instructions saved in them, which will require you to remove it manually.
Chrome
- In order to access the local HSTS settings saved in Chrome you will have to copy this in your address bar: chrome://net-internals/#hsts
- To confirm that the domain which you have disabled are saved in Chrome, type the domain in the Query Domain section (without http:// or https://) and click the Query button. If you get a "Found" result with data after it, then the domain was saved by Chrome.
- Now type the same domain into the Delete domain section and click the button. Now your browser will no longer force the HTTPS connection to that website.
Your browser will no longer force an HTTPS connection to that site.
Firefox
- Firefox makes things a bit easier as you won'\t have to access any specific option pages which are usually hidden as with Chrome.
- You should start with closing all your tabs and using the full History Shortcut Ctrl + Shift + H. Then find the website which you want to remove from the HSTS browser list, right-click on it and select Forget About This Site.
Then restart Firefox to get the desired result.
Safari
- Close Safari.
- Delete the
~/Library/Cookies/HSTS.plistfile. - Reopen Safari
Disabling HSTS is not recommended but may be required in some situations. However, you are now aware of how to do this procedure via the header and in 3 of the most used browsers.
How to opt-in for Preload List
Even if you have the HSTS header added to your website's .htaccess file, there is still a small window of vulnerability for newly installed browsers or completely wiped local states. To counter this, the Chromium Projects came up with the idea to create a preload list for chrome which contains all domains (and subdomains/nested subdomains) that were opt-in by their owners to be HSTS enabled by default. Mozilla Firefox and Safari maintain similar lists based on the original Chrome list to be able to do the same. You can opt-in for inclusion in this list if you can cover the requirements predefined by the Chromium Projects team:
- Serve a valid certificate.
- Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.
- Serve all subdomains over HTTPS.
- In particular, you must support HTTPS for the www subdomain if a DNS record for that subdomain exists.
Additionaly, to serve the HSTS header on the base domain for HTTPS requests requires:
- The max-age must be at least 31536000 seconds (1 year).
- The includeSubDomains directive must be specified.
- The preload directive must be specified.
- If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).
To address these requirements in order:
- Serving a valid certificate can be easily achieved by issuing a Let's Encrypt certificate for your domain and subdomains or by using a GlobalSign or other SSL certificate of your own.
- Redirecting from HTTP to HTTPS on the same host can be done by adding this to your .htaccess file and making sure you change "yourdomainhere.com" with your actual domain:
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://yourdomainhere.com/$1 [R=301,L] - Let's Encrypt will allow you to choose the subdomains which you want to cover when issuing a certificate for a certain domain. Just make sure your subdomains don't have any mixed content issues.
- You will need the HSTS header for making the correct HTTPS replies. For more information on the header, please visit our How to Enable HSTS tutorial on the matter.
Once you cover all of the above, go to this page for a check on HSTS compliance. Enter your domain, and you should see the following screen.
Warning
Once added to the preload list, the reversal of this action is very time consuming and may take up to 12 weeks for Chrome users and more for the rest of the browsers.
Below it, you will have the submit form in which you have to agree with the two terms by checking their boxes and then click on the submit button.
With this, your domain is now in the preload list, and will directly load via HTTPS mitigating MITM attack attempts.
How to opt-out of the Preload List
The only downside on the Chrome Preload list is the fact that if you decide to remove your domain from it, you will have to again cover a set of requirements and wait 6-12 weeks to be delisted with additional time for delisting from other browser's lists.
The requirements which you will have to meet are the following:
- Be preloaded or pending preload through hstspreload.org.
- Serve HTTPS with a valid certificate.
- Send a valid HSTS header that does not contain the preload directive.
To address them in order:
- This is self-explanatory, as in order to ask for a delisting you should first be listed or at least pending for a listing in the preload list.
- Even when delisting, you must still serve your content via HTTPS which means that your certificate must be active. Renewing your SSL might be needed in case it expired.
- You must still have the HSTS header in your .htaccess file.However, you should edit out the preload directive.
You can get delisted from the preload list while still keeping your HSTS enabled. To completely disable HSTS leave only this in your header:
<IfModule mod_headers.c> Header set Strict-Transport-Security "max-age=0" </IfModule>
If for some reason, you cannot comply with the above-mentioned requirements but still wish to remove your domain from the preload list, you can contact the listing authority directly by using this contact email.
Resolving HSTS issues
The same functionality which provide the extra protection when you have HSTS enabled can be a hurdle when trying to access your website if you encounter an error in your browser such as:
Error code: SSL_ERROR_BAD_CERT_DOMAIN
You will not be able to skip it and continue to the website due to errors on HSTS websites being forced as unskippable. As mentioned in the published in 2012 RFC6797 Section 12.1:
Failing secure connection establishment on any warnings or errors (per Section 8.4 ("Errors in Secure Transport Establishment")) should be done with "no user recourse". This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry. Essentially, "any warnings or errors" means anything that would cause the UA implementation to announce to the user that something is not entirely correct with the connection establishment. Not doing this, i.e., allowing user recourse such as "clicking through warning/error dialogs", is a recipe for a man-in-the-middle attack. If a web application issues an HSTS Policy, then it is implicitly opting into the "no user recourse" approach, whereby all certificate errors or warnings cause a connection termination, with no chance to "fool" users into making the wrong decision and compromising themselves.As an example, you can try to skip this error from the following website. Having said that, we will take a look at the most common issues regarding HSTS and how to resolve them
Expired SSL
If you actually got the above-mentioned error message in your browser, the SSL certificate for your domain has expired and needs to be renewed.
- In case you are using the Let's Encrypt service, renewal should be done automatically, unless there was editing in the DNS zone. For example, a Cloudflare configuration for that domain may be the cause for the Let's Encrypt certificate not to renew. This may require you to pause Cloudflare, purge the Cloudflare cache, issue the certificate and then reactivate Cloudflare. If you come across another issue related to the SSL certificate which you are unable to tackle yourself, you can always submit a ticket via your client area and our technical team will be right there to help you.
- If you are using a GlobalSign certificate, you will have to renew the service via your client area.
Mixed Content
When a browser access a web page via HTTPS connection and detects insecure (HTTP) resources, it will either not load them resulting in a broken layout of completely fail to load anything depending on the exact resource which is served over HTTP. This can be fixed by migrating all HTTP content to HTTPS.
Mixed content can be categorized as Active or Passive:
- Active mixed content which includes resources like JavaScript, CSS, fonts, etc. Browsers will not load any of these in such cases, due to the chance of them being compromised and used for malicious attacks.
- Passive mixed content which includes resources like images, video/audio, pdf, etc. Most browsers can load this content for now, however with stricter policies regarding mixed content coming into play; we may see more red error pages regarding unsecured content which is promoting webmasters to fix such mixed content on their websites. This is due to the connection being only partially encrypted meaning that the unencrypted content is accessible to sniffers and susceptible to man-in-the-middle (MITM) attacks.
You can use plugins to help you with fixing your mixed content such as the SSL Insecure Content Fixer or Really Simple SSL (pro feature) in case you are running a WordPress based site.
Redirect Loops
Depending on your website configuration, you might experience a redirect loop when you have HSTS enabled. This usually happens but is not limited to having a redirect all traffic rule in your .htaccess file:RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R,L]
This can also be done by a redirect plugin as those plugins will automatically add lines of code in your .htcaccess file. The same outcome can be detected, If you have enabled similar redirect in the virtual host file, in case you are managing your own server.
Also, please note that HSTS may act out of the ordinary in certain configurations making redirects before or after the one specified in the configuration file which could lead to extra redirects and slower load time for the end user. However, the diagnosis of this type of redirect errors cannot be generalized and has to be looked in a case-by-case fashion.
Cached Header after disabling HSTS
The HSTS header explicitly instructs browsers how long to wait before checking for the same via the max-age directive inside the header. If you have set that to 31536000 seconds as is the requirement for adding a domain to the preload list, this means that the browser will remember the settings for 1 year.
