Opened 5 years ago

Last modified 4 years ago

#7931 assigned Feature/Enhancement Request

Forward secrecy cipher suite support needed for mail

Reported by: Owned by:
Priority: High Component: Tech
Keywords: tls perdition courier roundcube Cc:
Sensitive: no


I'm looking at the TLS handshake to retrieve mail (pop) from and see this cipher suite is used TLS_RSA_WITH_AES_128_CBC_SHA

It looks like support for forward secrecy cipher suites needs to be added.

I'm using mpop to get mail and it lists this as its first choice: TLS_DHE_RSA_WITH_AES_128_CBC_SHA

Change History (13)

comment:1 Changed 5 years ago by

  • Keywords tls added
  • Owner set to
  • Status changed from new to assigned

I agree that this should be done. I'll look into what we need to do to make it happen, starting with the services providing the TLS aggregator.

comment:2 Changed 5 years ago by

Ross and i looked into this today, and we've made some first steps in planning it out.

There are several steps to ensuring that all POP and IMAP service within MF/PL can support forward secrecy:

  • get DHE working on the perdition IMAP and POP3 proxies running on -- this may require a patch to perdition to offer it on the server side, since i don't think the perdition codebase currently passes any DH parameters to libssl.
  • get DHE working on the courier-tls IMAP and POP3 servers running on the MOSHes and anywhere else that offers backend mail storage. This seems like it can be done with a change to puppet that would enable PFS (we tested something similar on boggs, but have not tested the change through puppet yet).
  • ensure that perdition is configured to require DHE ciphersuites from its backend connections.

The SMTP connections on moshes and on the mail aggregators all offer DHE, but use 1024-bit DH parameters, which are considered weak these days. they should probably use a stronger set of DH parameters, particularly because it looks like they all currently default to using the same parameters as each other (which makes it a particularly valuable parameter set for an adversary to target).

So this work is underway, but is not yet resolved.

comment:3 Changed 4 years ago by

testing this change to puppet on boggs.

comment:4 Changed 4 years ago by

I've just pushed puppet configs that make the appropriate changes. These changes are supposed to restart the courier daemons when the configurations get updated, but that does not seem to happen (for reasons i do not understand).

I also note that it seems like running freepuppet-run now always produces:

notice: /Stage[main]/M_courier::Pop/Service[courier-pop-ssl]/ensure: ensure changed 'stopped' to 'running'
notice: /Stage[main]/M_courier::Pop/Service[courier-pop]/ensure: ensure changed 'stopped' to 'running'
notice: /Stage[main]/M_courier::Imap/Service[courier-imap]/ensure: ensure changed 'stopped' to 'running'
notice: /Stage[main]/M_courier::Imap/Service[courier-imap-ssl]/ensure: ensure changed 'stopped' to 'running'

But of course these services are not actually stopped in the first place, so maybe it's just confused about whether it is running or not? someone with more puppet-fu than me probably needs to take a look at that.

Anyway, I am moving on try to sort out the perdition issues so that we can offer PFS on the frontend.

Once the perdition frontend is fixed, we need to ensure that all the backends offer PFS, then we can try to configure perdition to require PFS ciphersuites to the backends.

We should also somehow try to ensure that the imapd-ssl.erb installation actually depends on the exec["x509-append-dhparams"] invocation, so that we don't tell it to load DH params from files that don't have DH params in them.

comment:5 Changed 4 years ago by

I've figured out how to get puppet to check properly whether the service is running, but i haven't finished it yet. It looks like:

  service { "courier-imap":
    ensure => running,
    hasstatus => true,
    status => 'ps "$(cat /var/run/courier/ 2>/dev/null)" >/dev/null 2>/dev/null'

this is deployed (in an ugly hacked fashion) on boggs, and i need to clean it up.

comment:6 Changed 4 years ago by

OK, i've fixed the service checks so that they can tell whether the courier daemons are working, and that seems to have made it so that the updated courier configs will take effect once puppet loads.

so the mail backends will all have PFS enabled as soon as the next puppet tag gets pushed out.

comment:7 Changed 4 years ago by

  • Keywords perdition courier added

I'm going to try to install the patched version of perdition on for testing. I'll take gil out of the DNS RR first.

comment:8 Changed 4 years ago by

gil is back in the DNS RR. The updated version of perdition is now in the MF/PL apt repository's squeeze-mfpl distro, and is installed on both gil and paulo.

To add the EDH server-side capacity to gil and paulo, ross added the MF/PL apt repository to both of them via puppet, and then we did:

# there was no trailing newline on this file, so clean it up first :/
echo >>/etc/ssl/
certtool --generate-dh-params >>/etc/ssl/
apt-get update
apt-get dist-upgrade

So we're doing well here: end users can communicate using forward secrecy to for imap and pop and smtp.

We have a few more steps before we can close this fully, though:

  • the DH parameters offered by gil and paulo for SMTP are the stock 1024-bit debian postfix DH group. We should reconfigure postfix there to use a stronger DH group.
  • all the MF/PL backend servers need to have their courier instances and configurations updated to be able to offer PFS directly.
  • once the backend servers are all updated, we need to configure perdition on gil and paulo to require forward secrecy ciphersuites when contacting the backend servers.

comment:9 Changed 4 years ago by

i've pushed patched versions of perdition to the wheezy-mfpl distro on

comment:10 follow-up: Changed 4 years ago by

Since yesterday's tag mfpl-puppet-2.00, all backend servers should now be offering DHE ciphersuites for POP and IMAP.

So we need to tell the perdition gateways to rely on ephemeral Diffie-Hellman for the backhaul connections.

I think that's done by adding the following line to /etc/perdition/perdition.conf:

ssl_outgoing_ciphers HIGH:-kRSA:-kDSA:-aDH:-AECDH:-ADH:-aDSS:-PSK:-SRP

We also probably want to configure postfix to use stronger parameters when ephemeral DH is selected. Postfix's config names are confused here. smtpd_tls_dh1024_param_file really should be named smtpd_tls_normal_dh_param_file (it's used when a non-export ciphersuite is selected), and smtpd_tls_dh512_param_file really should be named smtpd_tls_export_param_file (it's used when a super-weak "export" ciphersuite is selected).

By default, both of these values are empty, so they use postfix's built-in DH groups, which are 1024-bits and 512-bits by default. If some inbound SMTP connection offers only "export" ciphersuites, they have lost the game already, so i don't think we need to bother with smtpd_tls_dh512_param_file (and indeed, if you provide a > 512-bit DH group as a serer while selecting an export ciphersuite, OpenSSL itself will abort the connection, presumably out of some archaic fealty to 1990's era cryptowars munitions control).

So i think we just need to add this line to /etc/postfix/

smtpd_tls_dh1024_param_file = /etc/ssl/

I've tested these changes on and they seem to not break anything.

However, when testing them, i don't think ssl_outgoing_ciphers is having the desired effect for sessions that use STARTTLS. I'll document that in a minute.

Last edited 4 years ago by (previous) (diff)

comment:11 Changed 4 years ago by

I've fixed the bug in perdition that makes it not use the outgoing cipher suite properly and deployed that fix to the wheezy-mfpl repository, so it is running on gil, along with the (not-yet-puppet-ified) configuration changes mentioned in comment:10.

If gil doesn't give us trouble with these setups over the next few days, we should push these changes into puppet, backport the fix to squeeze-mfpl, and deploy it to paulo as well (or, if paulo is upgraded to wheezy by then, skip the backporting).

comment:12 in reply to: ↑ 10 Changed 4 years ago by

Last edited 4 years ago by (previous) (diff)

comment:13 Changed 4 years ago by

  • Keywords roundcube added

Ah, forward secrecy for mail matters in several more places, which i'd forgotten to mention here and still haven't been dealt with:

  • the link between roundcube and should enforce a PFS ciphersuite.
  • the TLS layer protecting should offer PFS (and maybe automatically select it if the client offers it?)

Do we want to think about trying to do the same protections on horde as well?

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.