I haven’t changed anything to the apache, so I recon this is vulnerable ‘out-of-the-box’.
Can someone confirm these issues? Are they to be marked as bug?
I can’t check right now, but I’m sure the resulting config-file had “SSLProtocol All -SSLv2”, without -SSLv3 in it. (yesterday added SSLv3 manually).
Maybe the installation of a let’s encrypt certificate messes the template up?
(Can you reproduce the SSL-check on the website I mentioned?)
Tomorrow I can build a VM to reproduce myself.
SSLv3 is disabled in httpd-admin instance, but not in httpd.
We use SSL configuration from upstream, you can freely change the /etc/httpd/conf.d/ssl.conf configuration file.
Probably you hit this bug (check for the workaround inside the issue itself):
Maybe it’s related to not very secure cipher suits.
You can change it using:
repaired the chain as described in the bug (although: ‘hostname’ isn’t necessarily equal to the cetificate-name)
perform the change about SSLCipherSuite as mentioned above (vulnerability was indeed about ciphersuites)
restarted the webserver via the admin-consol
Rechecked, and my grade was upped from C to B
What’s left:
This server accepts RC4 cipher, but only with older protocol versions. Grade capped to B more info
The server does not support Forward Secrecy with the reference browsers. more info
I’m not able to interpret that score, maybe others are?
As for your question: let me ask another question: Why shouldn’t NS be shipped with a more secure apache-configuration…? SSLv3 is more then a year considered obsolete AFAIK. Why disable it on an internal website, and not on an internetfacing one?
httpd-admin on port 980/https is publicly available from the internet.
The main httpd instance on port 443/https has the upstream default. It is not secured with the state-of-the-art settings, I think because the default config file does not change during the release life cycle. The CentOS sysadmin knows it and fixes httpd configuration properly.
In NethServer our sysadmin is the template system. I think in this specific case the follow upstream default rule does not fit properly. Let’s fix the default value from our templates!
Before doing this, I’d wait to see the ssl.conf shipped with RHEL 7.3. For the ns7 rc2 release I’d go with the following adjustments:
nethserver-httpd TCP port 443
Set the prop httpd/SSLCipherSuite to the upstream default, like ssl.conf. The current value comes from ns6, issue #3246. The effect is we have distinct configurations on nethserver-virtualhosts sites and on the default virtual host defined by ssl.conf. This is misleading.
nethserver-httpd-admin TCP port 980
Here we can assume the admin has a modern browser, and performance is not the main goal. Set a strong configuration (@giacomo already tested this from https://cipherli.st/) in the template 30ssl.