Support for HTTP Strict Transport Security / HSTS
I'm wondering if Plesk also will implent HTTP Strict Transport (or HSTS) Security in the GUI. It's an extra layer of security for sites who need to be extra secure.
It's being done with a special header (mod_headers for Apache) and a TLS connection. The client (browser) can then verify if the server is the real server and not a man-in-the-middle server/attack.
It's as simple as adding the following code to the vhost config (HTTPS only!):
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
The functionality is now available in the SSL It! Plesk Extension: https://ext.plesk.com/packages/3c4117f6-c05c-4d3b-9173-60f10096a9c4-sslit
How to find it:
1. install SSL It! Extension (it’s available for Plesk 17.8+)
2. go to > SSL/TLS Certificates
3. if there is no SSL Certificate installed on the domain – issue one (using, for example, free Let’s Encrypt SSL Certificate)
4. if an SSL Certificate is installed on the domain, there is a switcher HSTS, turn it on
We would appreciate hearing your feedback on the implementation of this functionality. Thanks in advance!
Please add "preload" header feature.
Thank you very much for the extension! HSTS preloading would a great feature too. In case you added it, please provide an option for 1 year HSTS header too. Two years is not necessary for most use cases.
Michael Lux commented
Great stuff. Everything important in an easy-to-use UI. Two improvement suggestions:
1. Please add optional HSTS preloading. It's an expert feature, but it makes the whole thing even better!
2. Maybe a link to a sever config checker like Qualys SSL Labs to check if everything is working as configured? Useful, for instance, because the plugin won't notice if you already have another HSTS header in place in Server Config...
You didn't get what HSTS is about, I'm afraid? Ever heard of TLS/SSL stripping?
Sure, if the TLS certificate renewal fails (99 % of the time because the server admin is an idiot and blocked something or screwed up configuration), then it's a p.i.t.a. So is every other configuration error that prevents your domain from working.
I take care of dozens of websites, all protected with Let's encrypt and HSTS. Guess how often I experienced the renewal problem? Exactly once, because of a screwed up nginx config file.
Christian Heutger commented
I'm not sure, if that's the best place, but there seems to be a "bug" in your current SEO safe redirects setup regarding HSTS and primary using the HSTS preload list.
This list requires, that the headers are sent from https://example.com (maybe redirected by http://example.com and not first redirecting to http://www.example.com and then https://www.example.com) as the preload submission tool rejects such redirects.
So your SEO safe redirects are working somehow the "wrong order", if HSTS submission is planned.
Adrian Mörchen commented
HSTS also has some disadvantage.
I.e. ever tried to open a site where for whatever reason the generation of a new certificate failed? p**n in the *ss. (alternative HSTS with very low max-age, but then it isn't useful at all)
Instead there should be a global option for "always redirect to https".
Michael Koontz commented
The addition of HSTS support in Plesk would be a great addition. Please consider adding this soon.
I plan to switch on hsts this year on all https websites, with or without plesk, but would be quite disappointed if not by plesk (no track of what is done,..)
[Deleted User] commented
TRUE, you can set up all this by using "Additional Headers" or .htaccess.
In order not to use .htaccess (slows down a bit) u better use Plesk settings wich should end in .conf!
It would be great if you ad such stuff like the HSTS - Header as a templates.
wth do i have an helpful system like plesk to make my life more easy?!? :-)
Denver Prophit Jr. commented
Your KB needs to update the NGINX HSTS with the always parameter.
Alexander Yamshanov commented
I was tempted to copy/paste the solutions given on the forum and here....
Later I noticed I needed to change them as they were giving problems.
One is minor and only involves the testing of the domain by SSLlabs.
It turned out that SSLlabs chokes on websites that need credentials to test HSTS
These sites need the "always" attribute.
The other one is the flag "includeSubDomains".
As most will use this nginx directive server wide and they don't really know for a 100% what their clients are up to, you shouldn't use that flag.
I had a client that was running a plain http-only domain on a subdomain on some other server.
That site stopped working for all clients that previously went to their main site.
IMHO the flag includeSubDomains doesn't add anything extra for the site you're securing.
It limits all the sites of that domain to https.
This may be sensible for 1 specific domain, but most likely not a decision for you to make for ALL your clients.
add_header Strict-Transport-Security 'max-age=15768000' always;
Nelsir Carlos Luterek commented
This feature will be very useful since many internet sites like google chrome browser already uses this technology, my vote is to be implemented in plesk.
Jordan Schelew commented
I'm in favour of this as well. But a quick warning: make sure to remove the 'includeSubDomains' if the domain is being used for the Quick Preview URL.
Peter Downes commented
A very simple feature to implement, yet it's been 3+ years. Having to patch it through HTTP directives.