GDPR and SSL hardening

giacomo · February 12, 2018, 9:27am

With new GDPR rules, users are requesting safer configuration for mail and HTTP servers.

Do we need to change our defaults or simply add a new checkbox to enforce following options?

Apache

Disable SSLv2, SSLv3 and improve ciphers.

We currently don’t have a page inside the Server Manager to expose such configuration.

Some other open questions:

Does this configuration should be applied to all virtual hosts? And what about the default one?
Should httpd-admin always have a more stricter SSL configuration?

References:

4.13. Hardening TLS Configuration Red Hat Enterprise Linux 7 | Red Hat Customer Portal

Postfix: remove Gmail red paddlock

Whenever possible, use TLS encryption for SMTP.

Tested and safe Postfix configuration:

smtpd_tls_security_level = may
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtpd_tls_loglevel = 1

Reference log from Postfix:


Feb  9 16:46:50 support postfix/smtp[1473]: setting up TLS connection to aspmx.l.google.com[2a00:1450:4013:c00::1a]:25
Feb  9 16:46:50 support postfix/smtp[1473]: certificate verification failed for aspmx.l.google.com[2a00:1450:4013:c00::1a]:25: untrusted issuer /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
Feb  9 16:46:50 support postfix/smtp[1476]: setting up TLS connection to gmail-smtp-in.l.google.com[2a00:1450:400c:c00::1b]:25
Feb  9 16:46:50 support postfix/smtp[1473]: Untrusted TLS connection established to aspmx.l.google.com[2a00:1450:4013:c00::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

References:

Postfix: disable old ciphers

Postfix configuration:

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2, !SSLv3
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3

Reference:

Resolution for POODLE SSL 3.0 vulnerability (CVE-2014-3566) in Postfix and Dovecot - Red Hat Customer Portal

/cc @dev_team

pike · February 12, 2018, 9:41am

This one.
Maybe i’m wrong, but as for law you have to choose the highest encrypt, therefore choose a weaker one should not be an option.

Otherwise, revert the checkbox: strong as default, weaker as option with a warning with GDPR.

davidep · February 12, 2018, 9:48am

We can turn to the new security requirements starting from NethServer 7.5. However there must be a way to get back to the old settings. I’d say a documented procedure.

pike · February 12, 2018, 9:52am

The checkbox/option?

davidep · February 12, 2018, 9:57am

There isn’t a central point where this policy is enforced. Every service has its implementation.

From the UI point of view it is the same. Whilst the Email page could be good for Postfix, there’s no suitable page for Apache. If the opt-out is an edge-case, I’d prefer a documented procedure instead of putting a checkbox in a remote edge of the screen.

danb35 · February 12, 2018, 1:30pm

The problem is that older browsers/operating systems may not support the newer protocols and cipher suites, and some folks may need to work with those users. If we update the defaults (which I think we should), we should also provide a reasonably-accessible means of reverting them for compatibility with older software.

I’d also be hesitant about addressing compliance with any regulatory scheme in any but the most generic terms. I’d think a better path would be to say what the configuration is ("by default, Nethserver enables TLS 1.1 and later with the following cipher suites: "), and leave it to the user to ascertain whether this meets their needs.

davidep · February 12, 2018, 1:34pm

A pull request on GitHub - NethServer/docs: NethServer documentation is always welcome!

davidep · February 12, 2018, 3:07pm

Postfix issues opened:

pike · February 12, 2018, 3:51pm

You’re “tech-a-like” right.
But this kind of law (GDPR) attributes you liability if you don’t choose the safest/less vulnerable/newer and more secure option.
So… if the tech issue is outside your pertinency, liability is outside. If you choose to allow not safest (latest) software to connect, it’s your liability.

Therefore, the default should be most restrictive, and consequently, an unsafe option as a possibility, but not the first one.

davidep · February 13, 2018, 5:10pm

What about slapd (LDAP), ejabberd (XMPP), dovecot (IMAP, POP3)? …and what else?

We must add them to the list!

I’m considering a centralized prop to configure them all…

danb35 · February 13, 2018, 5:12pm

The existing pki property would seem relevant.

davidep · February 13, 2018, 5:14pm

Yes, furthermore with a system-wide configuration point a dedicated UI page is feasible.

(I’m not saying I want to code it!)

davidep · March 14, 2018, 9:31am

Update:

@stephdl started to work on this issue and we’re discussing the implementation details on GitHub. For any one interested, please see issues:

Open PRs:

stephdl · March 14, 2018, 10:35am

For hardening ssl we need to talk about service to protect

I could see

Dovecot
Apache
Postfix (#5420)
Ldap (don’t know ?)
…

My list is based on services which need a certificate, we can remove or add services…shout if i’m wrong

pike · March 14, 2018, 11:42am

IMVHO, GDPR talks of “secure by design”.
Therefore, if protocol/application has an “SSL version”, this should be enabled by default with the strongest/less vulnerable cipher setup as default setting.

danb35 · March 14, 2018, 2:04pm

As to which services to harden, I’d say that if a service supports TLS, we should give the ability to use that. I’m fine with setting (reasonable) secure defaults, but we should give the (easy) ability to roll back to more-compatible settings.

davidep · March 15, 2018, 8:10am

This is my proposal for the DB format. Defaults for ns 7.4

tls=configuration
     policy=legacy

Define an event tls-policy-save: every package that uses TLS must subscribe it
An UI is required (but should be really simple, just a page with a dropdown menu to select the policy)
Starting from 7.5 we can use dates as policy values (for instance policy=20180330)
Policy upgrade must be manual
If a package does not implement the selected policy, it must apply the strongest one it knows
A package may choose to raise the policy level to a minimum standard (e.g. httpd-admin)

Why not use an existing DB key? pki is for server certificate management, that is a separate issue.

Package list, so far

- [ ] nethserver-directory (slapd)
- [ ] nethserver-mail-server (dovecot)
- [ ] nethserver-smarthost (postfix)
- [ ] nethserver-openssh (sshd)
- [ ] nethserver-httpd (httpd) -- requires a migrate fragment for `SSLCipherSuite` prop and honor customized values
- [ ] nethserver-httpd-admin? -- this is already hardened separately: apply a "minimum policy?"
- [ ] nethserver-ejabberd (ejabberd)
- [ ] nethserver-mysql (!)
- [ ] nethserver-postgresql (?)
- [ ] nethserver-sssd (is a network client)
- [ ] openvpn and ipsec networks
- ...

/cc @dev_team

planet_jeroen · March 15, 2018, 8:49am

Yes, please change the defaults to be encrypted by default, and that means goating people to a letsencrypt certificate as well.

This would make me find a way to stop by and say hello to you guys, and ask whom to kiss. So it may be a double edged sword there … older browsers and os-es should not be considdered in the default and should be discouraged against.

Not doing so essentially helps malicious people to take advantage of users that have to rely on lazy sysadmins who didnt think about security or warning their users. It should be easy to enable the legacy stuff anyway, with a huge red banner filled with implications, but that should be a very deliberate action.

IMNSHO

stephdl · March 15, 2018, 3:55pm

I did some tests about to test ssl certificates with ssllabs and apache, the breaking change is rather on the protocol limited we can use. Sure if we force only tls1.2 we have a A but we miss some clients (android2 and XP/IE{6,7,8})

of course who still use IE

More seriously, just remove SSL2 & SSL3 and keep the actual cypher, you got a B with a warning for RC4 which is know as insecure. We can also refer to https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29 and provide support for a lot of client and be more secure than now.

I don’t think we can go to the most secure way and refuse older client like the modern way proposes but I feel that we should offer the most security method without possibility to reduce it.
actually I have found this, let talk of it

list of services to concentrate effort (now), once the prop name will be found, and possible settings
httpd see https://wiki.mozilla.org/Security/Server_Side_TLS#Intermediate_compatibility_.28default.29

SSLProtocol all -SSLv2 -SSLv3
#SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS:!SEED:!IDEA
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
SSLCompression Off

postfix
see https://github.com/NethServer/dev/issues/5420 and http://www.postfix.org/TLS_README.html#server_cipher & http://www.postfix.org/TLS_README.html#client_cipher

smtpd_tls_mandatory_protocols=!SSLv2,!SSLv3
smtpd_tls_protocols=!SSLv2,!SSLv3
smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5

smtp_tls_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_protocols=!SSLv2,!SSLv3
smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = RC4, MD5

dovecot see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-hardening_tls_configuration#sec-Configuring_Specific_Applications

ssl_cipher_list = HIGH:!LOW:!SSLv2:!SSLv3:!EXP!aNULL:!MD5   
ssl_prefer_server_ciphers = yes

ssh see https://infosec.mozilla.org/guidelines/openssh.html
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,diffie-hellman-group-exchange-sha256

Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr

MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com

pike · March 15, 2018, 7:02pm

IE 8 not supported anymore => out of GDPR
Win XP not supported anymore => out of GDPR
Android 2 not supported anymore => out of GDPR.

I’m not telling that i like to be on this razor edge, and behave just like the main QMail developer, but at least by my perspective, if NethServer needs to be GDPR compliant, the project should cut the rope and let obsolete and unsupported software to be kept outside.

Therefore, if the unsupported software (uncompliant to strong cyphers) will be able to connect to the server, liability falls on sysadmin’s head.