https://bugs.exim.org/show_bug.cgi?id=1895
Phil Pennock <pdp@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|FIXED |---
Status|RESOLVED |REOPENED
--- Comment #6 from Phil Pennock <pdp@???> ---
I have merged to master (following discussion with jgh and cryptographic input
from Viktor Dukhovni of Postfix (many thanks!)) a change which is not ideal,
but better.
http://git.exim.org/exim.git/commit/317e40ac8b1b816f4a22620a5647c6258de61598
https://github.com/Exim/exim/commit/317e40ac8b1b816f4a22620a5647c6258de61598
It's a signed commit because of the cryptographic material added, to provide
some provenance.
I have added the TLS groups from RFC 7919. I also added three primes which I
generated in May of this year, to move away from the RFC-offered primes.
Because we load from PEM and still need to support OpenSSL pre-1.0.2, I can't
use the "X9.42 DH" CMS support to load DH parameters with q in them. We're
loading PEM, so AFAICT our choices are "switch to DER embedding" (and not
support q in external files, elevating the Exim-internal parameters to
"especially privileged") or require OpenSSL 1.0.2.
I have sent mail to exim-announce:
https://lists.exim.org/lurker/message/20161008.231103.c70b2da8.en.html
which warns of the issue, points to work-arounds, and reminds folks that as of
next year, OpenSSL 1.0.2 is the minimum supported by the OpenSSL project.
My understanding, from talking with people who actually understand the math in
crypto (where I'm at a rather more dangerous level, which is why I try hard to
_avoid_ forcing crypto policy on people) is that the missing "q" does not
matter for Exim's use-model, where we fork a new process for each new inbound
connection and establish the TLS context after that, never re-using it for
another connection.
So: I think that Exim 4.88 provides better options, with a better default,
here, but there's still more we can do next year. But the commit does actually
resolve your issue, I believe, including providing the newly standardized DH
primes for those who want verifiable provenance.
Can you think of something we should be doing better, in advance of dropping
support for OpenSSL prior to 1.0.2 and supporting q in the DH parameters?
I think that after the next release, we might switch the structs of in-built
parameters to include a "deprecated" flag and log on start-up, but I'm really
not convinced it's worth it. I strongly suspect that fewer than 10 people/orgs
in the world are explicitly setting `tls_dhparam` to any of the `ike` values:
they're taking the default, or specifying a filename, or specifying "historic"
or perhaps "none" for some weird reason (corporate snooping compatibility?).
If I'm wrong in any of the above, I truly do welcome education and pointers. I
need to know more here.
Thanks.
--
You are receiving this mail because:
You are on the CC list for the bug.
