GDPR and SSL hardening


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?


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?


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[2a00:1450:4013:c00::1a]:25
Feb  9 16:46:50 support postfix/smtp[1473]: certificate verification failed for[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[2a00:1450:400c:c00::1b]:25
Feb  9 16:46:50 support postfix/smtp[1473]: Untrusted TLS connection established to[2a00:1450:4013:c00::1a]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)


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


/cc @dev_team


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.


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.

The checkbox/option?

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.

1 Like

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.

1 Like

A pull request on is always welcome!

1 Like

Postfix issues opened:

1 Like

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.

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…


The existing pki property would seem relevant.

1 Like

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

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


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


For hardening ssl we need to talk about service to protect

I could see

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:

1 Like

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.

1 Like

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.

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

  • 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

1 Like

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:

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

SSLProtocol all -SSLv2 -SSLv3
SSLHonorCipherOrder on
SSLCompression Off

see and &

smtpd_tls_mandatory_ciphers = high
smtpd_tls_mandatory_exclude_ciphers = aNULL, MD5

smtp_tls_mandatory_ciphers = medium
smtp_tls_mandatory_exclude_ciphers = RC4, MD5

dovecot see

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

ssh see




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.