GDPR and SSL hardening

v7

(Giacomo Sanchietti) #1

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:

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:

/cc @dev_team


Best practice with vhosts at your server
(Michael Kicks) #2

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.


(Davide Principi) #3

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.


(Michael Kicks) #4

The checkbox/option?


(Davide Principi) #5

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.


(Dan) #6

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.


(Davide Principi) #7

A pull request on https://github.com/nethserver/docs is always welcome!


(Davide Principi) #8

Postfix issues opened:


(Michael Kicks) #9

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.


(Davide Principi) #10

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

We must add them to the list!

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


(Dan) #11

The existing pki property would seem relevant.


(Davide Principi) #12

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

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


(Davide Principi) #13

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:


(Stéphane de Labrusse) #14

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 :wink:


(Michael Kicks) #15

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.


(Dan) #16

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.


(Davide Principi) #17

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


(Jeroen Visser) #18

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 :slight_smile:


(Stéphane de Labrusse) #19

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 :smiley:

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


(Michael Kicks) #20

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.