Template /etc/httpd/conf.d/ssl.conf

[danb35 (Dan)]

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).

Thoughts?

[dnutan (Marc)]

IIRC some settings are templated in other drop-in files under /etc/httpd/conf.d/

Like you I’d also prefer a more secure default configuration, as of now it follows upstream defaults. It was discussed in the past:

More secure SSL CipherSuites

Continuing the discussion from Letsencrypt certificate produces SSL error: NethServer Version: v7 Module: ssl I would propose to change the CipherSuites in /etc/httpd/conf.d/ssl.conf and /etc/httpd/admin-conf/httpd.conf and disabling SSL3 in the former: SSLProtocol all -SSLv2 -SSLv3 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128…

Webserver not as safe as expected?

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: config setprop httpd SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH signal-event nethserver-httpd-update Said this, we choose to stay complian…

Webserver not as safe as expected?

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 t…

Nethserver and TLS/SSLv3

I was following a discussion on another server platform I use, and an issue about TLS and accepted ciphers and protocols… When I decided to investigate what protocols and ciphers my Nethserver advertises: [root@neth ~]# nmap --script ssl-enum-ciphers -p 465 127.0.0.1 Starting Nmap 5.51 ( http://nmap.org ) at 2015-06-17 07:44 CDT Nmap scan report for localhost (127.0.0.1) Host is up (0.00013s latency). PORT STATE SERVICE 465/tcp open smtps | ssl-enum-ciphers: | SSLv3 | Ciphers (30) |…

The NethServer server is a winner even if not perfect

Many ICT administrators and executives looking for compensation for the Microsoft TMG (ISA) server. In the framework of a professional discussion with my colleagues, we selected three candidates IPFire, IPCop and pfSense. We have recently begun pfSense but it is rather problematic. Unfortunately, we was did not know NethServer : Now we using for testing NethServer in full operation in a small company (about 50 employees). NethServer works well. If we succeed with developers NethServ…

Disabling SSLv2, SSLv3, and other tweaks wanted

NethServer Version: v7 Module: v7-rc2 I currently have a webserver and Nextcloud accessible across the internet. I noticed that default settings in Apache and NextCloud have some concerns, such as using SSLv2 and SSLv3 (Poodle Vulnerability in SSLv3), and the RC4 cipher by default, which I would like to disable. I previously had a webserver running on Arch Linux, and used SSL Server Test to find and help close vunerabilities. A simple edit of relevant config files was all it took to close th…

NethServer distro is installed with the support of weak ciphers

Continuing the discussion from The NethServer server is a winner even if not perfect:

Hardening ssl - Qualys analysis

The httpd/SSLCipherSuite prop has been changed to that value on 6.7 release. The new default value comes from upstream. This entire story is on http://dev.nethserver.org/issues/3246 To customize it config setprop httpd SSLCipherSuite signal-event nethserver-httpd-update

The developers manual describes how to change the SSLCipherSuite db property.

[davidep (Davide Principi)]

Going by memory, you should start by defining a virtual host with the web server module.

Default Apache host retain upstream SSL settings whilst virtualhosts provide some hardening.

So the SSL.conf template wasn’t needed.

[danb35 (Dan)]

as of now it follows upstream defaults.

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?

The developers manual describes how to change the SSLCipherSuite db property.

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.

[danb35 (Dan)]

Default Apache host retain upstream SSL settings whilst virtualhosts provide some hardening.

Clearly I need to dig into the virtual hosts configuration a bit. But what’s the rationale for treating them differently?

[davidep (Davide Principi)]

Clearly I need to dig into the virtual hosts configuration a bit. But what’s the rationale for treating them differently?

Default Apache host retain upstream SSL settings whilst virtualhosts provide some hardening.

This is not true: it seems they share the same SSLCipherSuite value. To copy it from httpd-admin (which has an hardened default)

config setprop httpd SSLCipherSuite $(config getprop httpd-admin SSLCipherSuite)
signal-event nethserver-httpd-update

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).

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).

[mrmarkuz (Markus Neuberger)]

Thanks @davidep and @danb35 , SSLCipherSuite wasn’t set by default in httpd-admin on two of my servers but I could set it now with your instructions:

config setprop httpd SSLCipherSuite 'ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL'
config setprop httpd-admin SSLCipherSuite 'ALL:+HIGH:!ADH:!EXP:!SSLv2:!SSLv3:!MEDIUM:!LOW:!NULL:!aNULL'
signal-event nethserver-httpd-update
signal-event nethserver-httpd-admin-update

Do we also have to change SSLProtocol parameter or is SSLCipherSuite enough?

My sources for SSL/TLS recommendations:

https://grok.lsu.edu/article.aspx?articleid=17596
https://wiki.mozilla.org/Security/Server_Side_TLS#Modern_compatibility

[dnutan (Marc)]

Do we also have to change SSLProtocol parameter

Yes, also SSLProtocol.

[mrmarkuz (Markus Neuberger)]

Ah, now I see /etc/httpd/admin-conf/httpd.conf is templated:

[root@server httpd]# cat /etc/e-smith/templates/etc/httpd/admin-conf/httpd.conf/30ssl
#
# 30ssl
#

# settings by https://cipherli.st/
SSLCipherSuite EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH
SSLProtocol All -SSLv2 -SSLv3
SSLHonorCipherOrder On

For httpd one may just edit /etc/httpd/conf.d/ssl.conf

[davidep (Davide Principi)]

-SSLv2

SSLv2 seems no longer available, it could be redundant.

We should add a SSLProtocol prop, because it seems adjusting the cipher suite is not enough to get a good SSL rating

Edit: add the following template-custom

[root ~]# cat /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/10ssl_custom
#
# 10ssl_custom -- davidep 20180117
# Disable sslv3 protocol
#
SSLProtocol All -SSLv3

[mrmarkuz (Markus Neuberger)]

With a letsencrypt cert and following settings I got an A rating at ssllabs and no warnings at symantec:

Create custom template

mkdir -p /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/
nano /etc/e-smith/templates-custom/etc/httpd/conf.d/nethserver.conf/10ssl_custom

#
# 10ssl_custom -- davidep 20180117 
# Disable all protocols except TLSv1.2 
#
SSLProtocol all -TLSv1.1 -TLSv1 -SSLv2 -SSLv3
SSLCipherSuite HIGH:!aNULL:!eNULL:!kECDH:!aDH:!RC4:!3DES:!CAMELLIA:!MD5:!PSK:!SRP:!KRB5:@STRENGTH
SSLHonorCipherOrder on

Change SSLCipherSuite in ssl.conf:

nano /etc/httpd/conf.d/ssl.conf

SSLCipherSuite HIGH:!aNULL:!eNULL:!kECDH:!aDH:!RC4:!3DES:!CAMELLIA:!MD5:!PSK:!SRP:!KRB5:@STRENGTH

Apply changes:

signal-event nethserver-httpd-update

Source:
https://community.qualys.com/thread/14141

[davidep (Davide Principi)]

The cons of an high rate is loosing compatibility with older clients. I have to trade of between the two.

[mrmarkuz (Markus Neuberger)]

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.

[jassonmc (JM)]

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”
…

Cheers
Juri