Should we consider Allow enabling of HSTS

Split off from discussion Template /etc/httpd/conf.d/ssl.conf

Current best practices have changed for common Websites:

# generated 2019-07-19,
# requires mod_ssl, mod_socache_shmcb, mod_rewrite, and mod_headers
<VirtualHost *:80>
    RewriteEngine On
    RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]

<VirtualHost *:443>
    SSLEngine on
    SSLCertificateFile      /path/to/signed_certificate
    SSLCertificateChainFile /path/to/intermediate_certificate
    SSLCertificateKeyFile   /path/to/private_key

    # HTTP Strict Transport Security (mod_headers is required) (63072000 seconds)
    Header always set Strict-Transport-Security "max-age=63072000"

# intermediate configuration, tweak to your needs
SSLProtocol             all -SSLv3 -TLSv1 -TLSv1.1
SSLHonorCipherOrder     off

I think we should update our templates accordingly.
I recently got a F score…

Does this really need to be set to two years? Seems excessive.

This is the PR:

I report here the comment from the PR:

I’m not sure this is the right approach: the httpd server could host also HTTP applications.
If we enforce the HSTS such applications should always be accessed via HTTPS and this could cause many problems if the certificate is not valid.
Also, a sysadmin could have installed an application which doesn’t work with SSL: we can’t break existing installations!

If we want to support HSTS, it should be an option disabled by default.

There’s no way you should have gotten that with a default configuration with the current options. What were the noted concerns, and which test platform noted them?

And I agree that HSTS is something that needs to be explicitly enabled by the admin once he’s sure the TLS configuration (including renewal, especially if using Let’s Encrypt) is working properly. It should not be enabled by default.

1 Like

The tests were performed by Mozilla Observatory.

OK, and the Observatory is all about the headers, the vast majority of which would be controlled by any public-facing applications you’d be using–it isn’t (and isn’t intended to be) a test of the security of your TLS configuration. A better tool for that would be the Qualsys tool at, which returns an A for a Neth 7.6 server with the 2018-10-01 TLS policy.

The only header that Mozilla flags that arguably should be done server-wide is HSTS, but again, that should not be turned on by default–too risky.

Why isn’t there a way to tell the default virtual host to redirect to HTTPS? You can for any other virtual host.

I think that both the Headers and the SSL config are important.
Regarding HSTS we should allow the user to progressively enlarge the max-age value. It is good practice to start with a low value and test if everything works, and then progressively enhance it.

This brings me to my next point:
Is there a way to edit my virtualhost config without losing all of it as soon as the config file is regenerated? Otherwise we would limit any user to just the config possibilities we provide in the GUI, which probably will never be enough…

No, Observatory tests HTTP Headers, TLS, SSH and also runs third party tests with one of those being ths ssllabs test. You get a much better overview with this!

OK, more precisely, the Observatory that gives a poor grade on a stock Neth installation (the “HTTP Observatory”) is all about the headers. The “TLS Observatory” only determines whether the configuration strictly conforms to one of Mozilla’s prepackaged recommendations, and thus doesn’t assign a grade to TLS security, good or bad. The only thing that grades TLS configuration are the third-party scanners, and a base Neth installation scores well (not perfectly, but well) on those.

Your “recently got a F” was all about the headers, and enabling HSTS (regardless of the time) would have only raised that to a D–it still doesn’t do anything for content-security-policy, frame-options, etc. And those, IMO, shouldn’t be controlled at a server-wide level, but left to whatever web applications you’re using (Nextcloud, for example, sets all these except HSTS).

Edit: if you put, say, Nextcloud at the root of a virtual host, you’ll get A+ at the HTTP Observatory:
Again, that’s one’s all about the headers, and it’s the web application that sets the headers. The nethserver-nextcloud package sets the HSTS header automatically, though, and that setting isn’t configurable. That doesn’t seem optimal.

1 Like

What is the downside of having HSTS enabled as default setting?
Could generate any kind of problem on Apache-dependant applications?

HSTS prevents anyone from viewing your site insecurely (which includes not only via HTTP, but also via HTTPS with a cert error) for the specified time (which should be at least six months, and Mozilla is now recommending two years) after they last viewed it securely. If you have a problem with your HTTPS configuration (such as your cert expiring), it will lock visitors out of your site until you fix it.

It seems that you can expire HSTS by setting it to 0 when you encounter a problem.

I back this feature but it should be disabled by default and the admin can choose to enabled it.

Required steps:

  • define a new property
  • improve current template
  • add the new property to cockpit UI

I would strongly suggest to make this property variable by providing a input field for max age in the GUI.

1 Like

HSTS setting could/should be “separated” for every virtual host/reverse proxy? Or it’s a “one shot” setting for the webserver? (i don’t know and i am trying to understand, that’s not a request for feature)
Also… do cockpit (as nethgui) rely on specific apache instance?

1 Like

It can, but it will cover everything for a given hostname (it won’t limit itself to subdirectories).

Yes, but that header has to be served over HTTPS, so you’ve got a chicken/egg problem. If you anticipate a problem, you can set it to 0 before the problem happens, and you might be OK (any client that had received the header with 0 would be able to connect over HTTP or invalid HTTPS). But if your HTTPS is already broken (including an expired cert or a cert name mismatch), the 0 won’t override the previous time setting, as the client won’t ever see it.