NethServer Version: 7.8.2003
Module: Base
Is there any way to alter the webserver(s) on Neth to enforce HSTS?
NethServer Version: 7.8.2003
Module: Base
Is there any way to alter the webserver(s) on Neth to enforce HSTS?
Does it work if you set a stricter TLS Policy?
On my gentoo webserver I had to add those lines near the ssl configuration in the apache vhost config of the websites itâs serving, but I have to leave it to the nethserver pros to explain how this can be implemented with some e-smith template because I donât know. Maybe they also decide to activate this option in the apache config?
Header always set Strict-Transport-Security âmax-age=31536000; includeSubDomainsâ
Header set Content-Secure-Policy âdefault-src âselfâ;â
It works with a custom template:
Create custom template dir:
mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf
Create file /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/20hsts
with following content:
Header always set Strict-Transport-Security "max-age=31536000"
Apply configuration:
signal-event nethserver-httpd-update
Thereâs a feature thread:
âŠand as I noted there, HSTS should not be enabled by defaultâthereâs too much risk of locking visitors out of your site. But yes, Neth should include the option in the server manager.
Iâve got that set and the security fault remains.
Awesome. Iâll set this and keep my ear open in case anyone has problems. Thanks!
Just to confirm: will this fix handle servers on all ports or is it targeted? I receive the security notification on 9090 and 443.
No, the custom template only covers the httpd port 443. For the other services more custom templates are needed.
As regards cockpit port 9090 I did not find a way to enable HSTS.
Cockpit is not intended as âpublic available toolâ⊠As advised into management interface, the IP should be restricted to a defined list for allowing connection.
IMVHO also for every other module which expose a âpublic applicatonâ, like MatterMost o NextCloud.
Thank you for trying.
Warning:Once enabled, HSTS disallows the user from overriding an invalid or self-signed certificate message. Your website will be inaccessible without a valid SSL.
This will enable for the whole apache, maybe we could have a solution adapted to each vhost
Now i get why itâs not exposed that kind of option on CockpitâŠ
However it brings a lot of good new security layer like the man in the middle
create a file /etc/e-smith/templates/httpd/vhost-extra/20HSTS
{
if ($Port == 443) {
$OUT .= q(
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</IfModule>
);
}
We can create a checkbox (default disabled) with a warning about selfsigned certificates (who use it nowadays). Obviously this will be only enabled per virtualhost
I think this is a good plan. Iâd also add to the warning that if the certificate becomes invalid for any other reason, users will also be unable to connect. The most likely issue here would be that a cert fails to renew, and that problem isnât recognized in time, HSTS will lock people out.
If thatâs the case, documentation to reverse the process, and set to default, from the cli would be helpful.
Thatâs the problem with HSTSâremoving it wonât help you. Every time you connect, it sends the header that tells your browser to not connect insecurely to your FQDN (optionally including subdomains) for the next n seconds (generally for a period of one-two years), no matter what. By design, you canât just override this in the browser by clicking âvisit anywayâ. And the fact that the server isnât sending that header now doesnât help, when it did send it last time. So disabling it from the command line is only part of the solution; the rest is that you must then visit from a different browser (one thatâs never received the HSTS header from your server).
Itâs not that bad, you can clear it in the browsers:
Firefox:
Chrome/Safari:
https://really-simple-ssl.com/knowledge-base/clear-hsts-browser/
We talked internally about HSTS feature and we are not sure it is good enough about the user experience. We think that it could bring some good things from a security perspective but also bad behaviors if you are not fully warned about the consequences.
In short for now we would like that people tries it without being exposed in the UI and this can be done simply by a .htaccess
in the vhost itself, force obviously the https of your vhost
vim /var/lib/nethserver/vhost/64f1c94a95e24a9/.htaccess
drop in your .htaccess
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" env=HTTPS
</IfModule>
reload httpd
systemctl reload httpd
test it by https://securityheaders.com/