As I was looking to make some edits to ssl.conf, I realized that it isn’t templated–NS 7.4 just uses the default ssl.conf file from the upstream mod_ssl package. This seems kind of odd, given that pretty much every other configuration file is templated, and it means there’s simply no way to configure any HTTPS-related settings through the config system.
There are a couple of things that really need to be changed, as they compromise the security of a Neth installation:
SSLv3 is enabled, which is quite insecure (even TLS 1.0 is questionable, as I understand it).
The RC4 cipher is also enabled with some protocols.
Templating would also allow for properties for SSL key/cert/chain, removing the need to, for example, copy the Let’s Encrypt cert from /etc/letsencrypt every time it’s issued.
The particular thing I was looking to do was enable OCSP stapling, which is a straightforward enough setting (and I could, of course, just make the changes to ssl.conf).
When the upstream defaults are known to be insecure (as they are), that doesn’t really seem like a good idea. And why follow the upstream defaults on this one particular point, when just about everything else (on the system in general, and in the Apache configuration specifically) is customized?
Since ssl.conf isn’t templated at all, I’m curious how that setting would take effect–maybe I’ll have to try it. Looking through some of the links you gave (shame on me for not searching for prior discussion, though my point in this thread is a little different), it sounds like that property affects configured virtual hosts, but not the default. I’m having trouble imagining the rationale here. But really, there are two orthogonal issues:
IMO, ssl.conf should be templated just as most of the other system config files are, and for the same reasons. Configuration properties like the SSLCipherSuite should be implemented there for system-wide use. Or, alternatively, manage those settings directly through the httpd.conf templates and get rid of ssl.conf.
Whether ssl.conf is templated or not, the current NS7 defaults are insecure and should be changed. SSLv2 and SSLv3 should not be supported, nor should RC4. I don’t see this as an issue of breaking upstream compatibility–we’d be using unmodified upstream packages, but customizing the configuration–as we do for pretty much every other upstream package.
You can edit ssl.conf directly (as it’s not a template). Remember to add it to the config backup.
The approach of NS templates is rather overriding the settings by issuing the same configuration directive at a later step (conf.d files are evaluated in alphabetical order), or in a more specific context (global/vhost/directory).
I think we should go for compatibility. Just disabling SSLv3 would be a good compromise IMO between rating (B) and compatibility. With active SSLv3 we get “C” and some security warnings (poodle…).
People who like it more secure are always able to change SSLCipherSuite and SSLProtocol.
I definitely support a more secure default and would not only disable SSLv3
I have been using the following ssl.conf settings since about 2 years for about anything.
Gets me an A+ rating on Qualys and only kicks veeeery old clients, like Android v2, Win XP with IE8 and the like. No matter what application, that conf never failed on me.
As a default, enforcing HSTS might be a little bit too much…
…
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
SSLHonorCipherOrder on
SSLInsecureRenegotiation off
SSLCompression Off
Header always set Strict-Transport-Security “max-age=15768000”
…