https://bugs.exim.org/show_bug.cgi?id=1895
Phil Pennock <p...@exim.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED --- Comment #6 from Phil Pennock <p...@exim.org> --- 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. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##