Some preliminary analysis of:
https://www.openssl.org/news/secadv/20160128.txt
as it pertains to Exim.
## DH small subgroups (CVE-2016-0701)
You can be vulnerable with OpenSSL 1.0.2 if the file passed to
tls_dhparam has parameters generated in a new way, and they're dodgy
parameters.
Mitigation 1: don't do that
Mitigation 2: Exim forks a new process for each inbound connection, so
reuse of one private param seems unlikely (unless it's
generated and cached during the initial sanity check)
Mitigation 3: Exim main config: openssl_options +single_dh_use
Seriously, don't generate bad parameters, configure Exim to use them,
then complain that the OpenSSL library leaks the reused DH private key.
So, if you're generating the file passed to tls_dhparam and using
`openssl dhparam -dsaparam` then you've got issues.
The "migitation 3" implements the change in config which OpenSSL has now
made mandatory and backported.
## SSLv2 doesn't block disabled ciphers (CVE-2015-3197)
Seriously, SSLv2? I know that opportunistic encryption for MX delivery
means "use even crap encryption, since you'd fall back to plaintext
anyway", but SSLv2?
Exim disables SSLv2 by default since 4.80, and you could use
`openssl_options` to enable it before then. Since 4.80, you'd have to
explicitly set `openssl_options -no_sslv2` to enable SSLv2.
Enabling SSLv2 exposes you to many issues. If you're doing that, then
you presumably don't care how good your encryption is, so really have no
basis for complaint if ciphers you'd disabled get used.
For encryption for Submission: don't enable SSLv2, there's no
conceivable model where you want to support mail-clients that
unmaintained, they'll have other security problems.
For encryption for MX delivery: if you care about delivery not being
downgraded, don't enable SSLv2; Exim doesn't by default. As long as
you're running in a mode where you'll fallback to cleartext delivery,
there's not a great hardship in a remote server configuring a null
encryption.
## Logjam update
Previous releases of OpenSSL set a minimum DH size of 768 bits to limit
Logjam impact, this release moves to 1024 bits.
Exim built with GnuTLS has pretty much always set a minimum size of 1024
(excepting the period where an OS packager raised it to 2048).
I don't think Exim has ever enforced a minimum size when built using
OpenSSL. If this change affects you, then fix the servers using tiny DH
params sizes. If you can't get somebody else to fix, then they don't
care about security, fall back to plaintext. If you can't get someone
else to fix, but this is somehow your problem anyway, then believe me
when I say that there are better jobs out there.
## Conclusion
So: you probably don't need to do anything for Exim based on this
OpenSSL release, unless you've been lowering security anyway, in which
case you might have lowered it even more than to the "pathetically bad"
levels to which you thought you'd lowered it.
