Those who follow cryptographic news may have already seen concerns
spreading about the integrity of Diffie-Hellman primes in RFC 5114.
This mail will attempt to explain the issue and how it affects Exim.
Short version: used to be utterly horrible for OpenSSL users; got
better, but we now believe not as much better as we'd hoped; we now
believe that for GnuTLS users, things got a little worse instead of
being a no-op. In the next version of Exim (4.88) it's better still by
default, but manually generating a file for your `tls_dhparam` setting
avoids the issue, always has, and is the best way forward.
Documentation updated to make this clearer.
PS: OpenSSL EOL at end of this year, from next year they only support
1.0.2 and higher.
For the long version, grab a coffee. Happy Monday morning.
Exchanging email with link security uses TLS. By default, this is done
in a very vulnerable way because of the nature of email. As such, much
of the concern is, for most, worrying over a thorn in a finger when
there's arterial blood gushing from the stump of the other arm. Those
interested in preventing the bigger problems should look at DANE in
Exim's experimental-spec.txt, ensure that they have DNSSEC-validating
resolvers and consider providing feedback to help this feature move out
of Experimental status. Without this, or equivalent site-specific
overrides ("manual pinning"), all MTA-MTA traffic is vulnerable to
active attack.
Assuming that you have meaningful identity verification (via DANE or
manual configuration) then we can move onto the problems here.
If an attacker has captured your encrypted communications, what can they
do to figure out the plaintext? There's two main approaches to how TLS
runs, with different failure modes. In one approach, anyone with the
server's private key can decrypt all communications with that server,
past or future, as long as the same private key is used. In the other
approach, session keys are negotiated such that having the server's
private key is not enough to determine the session keys from what's on
the wire. This second approach is most often now called "Perfect
Forward Secrecy" or PFS. In older non-elliptic-curve cryptosystems,
it's a feature of any ciphersuite whose name starts "TLS_DHE_".
Research has shown that if someone mathematically capable can choose the
prime numbers used for these DHE suites, they *can* (now confirmed) set
things up so that they can "more easily" decrypt communications made
with them. It takes immense (but achievable) computing power to
pre-compute what's needed, and is not trivial even after that, but it's
within the reach of a few organizations which exist today.
In versions of Exim before 4.80 (in 2012), Exim using GnuTLS would
generate some DH parameters if they did not exist. Exim using
OpenSSL could be given a filename containing DH parameters.
During the RC process for 4.80, in recovering from some unfortunate
interoperability issues around DH parameter sizes, custom OS packaging
changes and more, we encountered numerous issues with automatic
generation of DH parameters; to step around the whole issue, I took the
various RFCs which specified common DH parameters and encoded them as
named options as alternatives for an external file, and chose one as the
default. The default I picked was IKE 23 from RFC5114. It remained
possible to specify an external file.
For the next release of Exim (4.88), the set of available pre-canned DH
parameters has been expanded to include five new sets from RFC7919 and
three sets generated by me. The RFC7919 parameters are chosen to have
verifiable provenance. The new default is specific to Exim.
For cryptographers: Exim does not pass the 'q' value for DH
initialization for the built-in constants, but Exim as a server never
re-uses an SSL context for more than one handshake. Exim forks a new
process for each inbound connection and sets up TLS post-fork. Our
understanding, based upon consultation with those who do know more, is
that there this exposes a trivial leak of one bit of information about
the ephemeral context, which is immediately discarded anyway.
In practice:
0. If you're not using authenticated TLS you have no way of knowing if
someone was grabbing anything; most non-DANE users fall into this
category. We do want things to be better for those who do put in the
effort to maintain a well-run mail-system though;
1. Good OS packagers generated new DH parameters on your system, and
still do so;
2. If you're accepting the defaults and not using such a package, then
Exim 4.80's changes to the _default_ moved OpenSSL users from "anyone
who could break into your server to steal keys could easily decrypt
all past and future communications" to "a very few organizations
could decrypt specific communications, with effort, but without
having to break in first"; for GnuTLS users, it moved from "as secure
as we know how" to that "very few organizations" category;
3. If you follow the documentation and set up the `tls_dhparam` main
configuration option to point to a file of your generation, you're
probably as good as it's possible to get, while using RSA/DHE
communications;
4. If you run without tuning `tls_dhparam` then 4.88 will be better for
you, if you trust me. If you don't trust me but (do trust code I
help maintain and) don't want to generate your own DH parameters,
then set: tls_dhparam = ffdhe2048
5. Debian (and thus Ubuntu) stopped configuring packages to use custom
DH parameters, instead accepting the standards in Exim; that was
reasonable on their part, since we shipped this new, simpler,
facility but does mean that they're the one group who have
unfortunately gone backwards in security, when it comes to defending
against such well-equipped adversaries. (They've still always
ensured they were far better than most others.) Sites who need to
defend against those adversaries should probably generate their own
`tls_params` file, same as anyone else.
Debian maintainers: sorry, you accidentally got burned by me.
In 2012, we were hitting problems with mail-clients using Mozilla's NSS
library not accepting DH parameters larger than 2236 bits (and
hard-failing TLS when offered such), some OS packages which had patched
Exim to not only offer 2048-bit primes in DH parameters but to require
that as the minimum of remote sites too (not their intention) and a need
to update things. We moved to 2048-bit defaults, available for
everyone, but my documentation updates did not call out that maintaining
your own DH parameters was still the best approach.
By late 2016, enough attention has been paid to cryptographic libraries
that postmasters might reasonably try again to raise the DH parameter
bit-size to be consistent with recommendations in
<
https://www.keylength.com/en/3/>. Setting:
tls_dhparam = ffdhe3072
or:
tls_dhparam = ffdhe4096
may be appropriate for those who wish to use standard-but-auditable
primes. (You can also put the standard primes into the file which you
point Exim at). We suggest the best approach, given what is currently
known, is generating your own parameters of that size.
In separate DH news: for the DH parameters (p, g, q) Exim has only
provided the (p, g) values. This opens Exim connections to a certain
class of attack; however an Exim serve does not re-use SSL contexts for
multiple handshakes when accepting inbound connections: each is accepted
in a new process. So this attack can leak one bit of information about
an object which is discarded and never re-used. Newer OpenSSL has
routines to load variants which include 'q' from the CMS (PEM) files but
not everyone using Exim with OpenSSL is on 1.0.2 already. As such,
rather than rush out changes and break Exim for many users for an
improvement which doesn't actually help with our user-model, we're
proceeding more cautiously.
We'd like to remind administrators that OpenSSL has a published support
policy for their releases at:
<
https://www.openssl.org/policies/releasestrat.html>
and that as of January 1st, 2017, only OpenSSL 1.0.2 and higher will
still be supported. Versions 0.9.8 and 1.0.0 are no longer supported
and 1.0.1 reaches EOL on 2016-12-31.
Exim is a volunteer project, already maintaining TLS support across both
OpenSSL and GnuTLS. OpenSSL is making a number of API cleanups and
continuing to support older releases is becoming untenable for Exim. We
are strongly tempted to declare that we will not support building Exim
against releases of OpenSSL not supported by the OpenSSL Project.
Please take this into account when considering how to manage your
maintenance plans.
Personally, I anticipate Exim installation instructions documenting how
to install a current OpenSSL alongside Exim on common platforms.
With the opportunity to clean things up, we'll be better placed to
support newer cryptography and variant libraries. Patches welcome.
Regards,
- -Phil Pennock
