[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

2016-10-08 Thread admin 
https://bugs.exim.org/show_bug.cgi?id=1895

Phil Pennock  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from Phil Pennock  ---
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/ ##

[exim-dev] [Bug 1895] Default groups for DH possibly backdoored

2016-10-08 Thread admin 
https://bugs.exim.org/show_bug.cgi?id=1895

Git Commit  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||g...@exim.org

--- Comment #5 from Git Commit  ---
Git commit:
http://git.exim.org/exim.git/commitdiff/317e40ac8b1b816f4a22620a5647c6258de61598

commit 317e40ac8b1b816f4a22620a5647c6258de61598
Author: Phil Pennock 
AuthorDate: Sun May 29 02:31:18 2016 -0400
Commit: Phil Pennock 
CommitDate: Sat Oct 8 19:23:37 2016 -0400

dh parameters update, new values & default

* add three new exim-specific dh parameter constants; state provenance,
  but no way for others to verify; this is a signed commit, which is
  about as much as we can do for the truly paranoid: provide an audit
  trail.
* add the rfc 7919 dh primes
  + no tls feature negotiation, per 7919, but the dh primes can be used
if folks so choose
* fixed broken format string in util/gen_pkcs3.c
* tried to make gen_pkcs3.c support q values.
  + turns out, q doesn't affect the pem and that's not a mistake in my
initialisation; i've checked with a cryptographer, we're losing some
server-side optimizations but not any security properties for our
scenario.

fixes: 1895

 doc/doc-docbook/spec.xfpt |  38 +++-
 doc/doc-txt/ChangeLog |   3 +
 doc/doc-txt/NewStuff  |   2 +
 src/scripts/source_checks |   1 +
 src/src/std-crypto.c  | 503 +-
 src/util/.gitignore   |   2 +
 src/util/gen_pkcs3.c  |  41 +++-
 7 files changed, 574 insertions(+), 16 deletions(-)

-- 
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/ ##

[exim-dev] [Bug 1837] small subgroup attack

2016-10-08 Thread admin 
https://bugs.exim.org/show_bug.cgi?id=1837

Phil Pennock  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #10 from Phil Pennock  ---
Current stance:

Missing q leaks one bit of information from an ephemeral context which is never
reused and is not a problem in Exim's environment.  It's not ideal.

We're about to merge code changing the default to one we generate (small
sub-group, no q), and providing the new RFC 7919 values too.

The `openssl genpkey` command is not generic and does not let us get the
RFC7919 values.  I have not found a way yet to get this information for
arbitrary other DH parameters instead of just those hard-coded ones.

AFAICT from OpenSSL "NEWS" file, CMS support for X9.42 DH came in with OpenSSL
1.0.2 and that is the feature needed for us to switch to the variant suggested
in this bug, using our current code.   Exim needs to continue supporting older
versions of OpenSSL so that's not a viable path for us.

Rather than add lots of keys and change how the crypto is used at the same
time, I'm breaking this into two steps:

(1) Push the current changes, which still have the q problem for small
subgroups, accepting that it doesn't matter for Exim but is not ideal.

(2) Look at using DER encoded binary directly in source files, per Viktor's
suggestion, as done in Postfix.  With that, we don't need to worry about CMS
support and we should be able to specify 'q' with any supported version of
OpenSSL.  That's a lower-priority task.

-- 
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/ ##

[exim-dev] [Bug 1819] Conditional configuration depending on exim version

2016-10-08 Thread admin 
https://bugs.exim.org/show_bug.cgi?id=1819

Jeremy Harris  changed:

   What|Removed |Added

   Assignee|h...@schlittermann.de |jgh146...@wizmail.org
 Status|NEW |ASSIGNED
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jeremy Harris  ---
The above implements the original request 2nd option.  For the specific issue:

.ifdef _OPT_MAIN_ADD_ENVIRONMENT
add_environment=foo
.endif

Use 'exim -bP macros' to see the list of predefined macros.

--- Comment #9 from Jeremy Harris  ---
Nobody commented

-- 
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/ ##

[exim-dev] [Bug 1897] Exim not falling back to non-TLS on callouts

2016-10-08 Thread admin 
https://bugs.exim.org/show_bug.cgi?id=1897

Jeremy Harris  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
Version|4.86+ HEAD  |4.86

-- 
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/ ##