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.
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 https://www.ssllabs.com/ssltest/, 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: https://observatory.mozilla.org/analyze/db-cloud.org
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.
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.
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?
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.