Exim, DH, GnuTLS & interop

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Exim, DH, GnuTLS & interop

Phil Pennock
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Folks, sorry this isn't threading: I subscribed to this list to post
after being pointed by Viktor at:

  http://archives.neohapsis.com/archives/postfix/2013-09/0003.html
  http://archives.neohapsis.com/archives/postfix/2013-09/0015.html

For interop and to counter accidental misinformation, I'll clarify some
Exim points here.  If anyone wants any further guidance for Exim, I
suggest that exim-users is the place to start, and that postfix-users
only be used for interop debugging on this particular issue if the list
veterans are happy with that.  I'll try to hang around for a few days
for any follow-up (but am "rather busy" right now, so replies won't be
prompt).

  https://lists.exim.org/mailman/listinfo/exim-users

Exim does not itself set a minimum length of 2048 bits for EDH; *if*
Exim is built against GnuTLS (instead of OpenSSL), then the GnuTLS
defaults will, by default, be applied to connections.  As the GnuTLS
library is rebuilt on newer versions, new default values chosen by
GnuTLS will apply to Exim: rather than impose cryptographic policy, we
prefer/try to accept the policy from the library as defaults, and
provide configuration options to let the site operator override.

The only place Exim chooses a value which might match 2048 relating to
DH is when generating fresh server-side parameters, as the default size
to generate, if not told otherwise; the actual value is:
  gnutls_sec_param_to_pk_bits(GNUTLS_PK_DH, GNUTLS_SEC_PARAM_NORMAL)
but clamped down to a maximum of 2236, to avoid interop issues with NSS
clients such as Thunderbird, because until fairly recently NSS did not
support larger sizes and would hard-error.

Assuming an Exim version of at least 4.80, then the Exim option
tls_require_ciphers is interpreted, for GnuTLS, as a Priority String;
those are documented at:

  http://gnutls.org/manual/html_node/Priority-Strings.html

Note that Exim has tls_require_ciphers both as a main section
configuration option, applying to Exim-as-server, and as an option on
SMTP Transports, applying to Exim-as-client.

It's been a while since I touched the GnuTLS integration and I don't
currently have time to test/experiment and confirm, but I believe that
overriding the GnuTLS library defaults to tell it "Weak" should be
sufficient to get Exim happy to talk with smaller DH values.

More documentation on Exim's TLS handling can be found at:

  http://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html

Regards,
- -Phil, [hidden email] and one of the last two people to touch the GnuTLS
       and OpenSSL integration in Exim
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlIju5oACgkQQDBDFTkDY39HkwCeObzhmF7IxL4XuCB9mfCNoKxs
hbEAoJVh15uHfpDnl2siOcJv9/QXqv9O
=e03D
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Wietse Venema
I will keep my anaswer short.

First, the primary mission of Postfix is to deliver mail, not to
force someone into adopting a particular world view. I have asked
Viktor what patch would restore interoperability.

Second, we have to be mindful that Postfix and Exim are not the
only MTAs in existence. If placating Exim results in the loss of
interoperability with other MTAs, then we may have to reconsider
our approach.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Viktor Dukhovni
On Sun, Sep 01, 2013 at 07:02:00PM -0400, Wietse Venema wrote:

> I will keep my anaswer short.
>
> First, the primary mission of Postfix is to deliver mail, not to
> force someone into adopting a particular world view. I have asked
> Viktor what patch would restore interoperability.
>
> Second, we have to be mindful that Postfix and Exim are not the
> only MTAs in existence. If placating Exim results in the loss of
> interoperability with other MTAs, then we may have to reconsider
> our approach.

I don't think there is anything obivously correct that Postfix can
do.  It seems most likely that the issue is in GnuTLS, assuming
the original user report is correct.  It is I think not right for
GnuTLS client software to introduce an aggressive default minimum
value on peer server DH primes.  Since the group size is not
negotiated any such limits just break interoperability.

We could perhaps argue that this is a TLS specification bug, since
there is no mechanism for the client and server to agree on a
suitable group, but that's not terribly productive.  The server
chooses a group, that choice should be reasonable and the client
needs to accept that choice.

One thing that Postfix could do is always return a 2048-bit group
when OpenSSL asks for 1024-bits (i.e. *not export*).  This would
be at a non-trivial performance penalty, but SMTP server connection
rates are orders of magnitude lower than HTTP server connection
rates, so arguably, the cost is acceptable.  What we don't know is
which client implementations will break because 2048 is too big!

This problem has just now been reported for the first time, perhaps
because someone updated GnuTLS to a recent version that exhibits
this behaviour.  I think the right place for the fix is in GnuTLS
or applications that use it.

Another possible Postfix work-around is to disable prime EDH
altogether, leaving just EECDH, but this is a bit severe.  With
any luck, there are as yet very few Exim sites impacted by this,
and ideally they can take appropriate steps (tune GnuTLS to allow
1024-bit MODP DH groups).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Viktor Dukhovni
On Sun, Sep 01, 2013 at 11:11:12PM +0000, Viktor Dukhovni wrote:

> This problem has just now been reported for the first time, perhaps
> because someone updated GnuTLS to a recent version that exhibits
> this behaviour.  I think the right place for the fix is in GnuTLS
> or applications that use it.

According to:

    http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676563

it seems recent Exim versions have code to lower the client-side
DH_BITS to 1024.  If Peer Heinlein would be kind enough to post
the Exim version that exhibits the problem and any relevant settings,
that would help narrow down the problem.

I ran "openssl dhparam 1024" 20 times, each time the high-bit of
the 1024-bit prime was set, so it seems that OpenSSL does not
generate 1024-bit DH groups that have slightly shorter primes.  So
if the Exim client is configured to accept 1024-bit DH groups it
should work.  If it is only willing to do 2048-bits, it will fail
with most non-Exim TLS servers.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Viktor Dukhovni
On Mon, Sep 02, 2013 at 01:25:02AM +0000, Viktor Dukhovni wrote:

> If Peer Heinlein would be kind enough to post
> the Exim version that exhibits the problem and any relevant settings,
> that would help narrow down the problem.

Also the version of GnuTLS with which Exim is linked.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Viktor Dukhovni
On Mon, Sep 02, 2013 at 03:03:36AM +0000, Viktor Dukhovni wrote:

> On Mon, Sep 02, 2013 at 01:25:02AM +0000, Viktor Dukhovni wrote:
>
> > If Peer Heinlein would be kind enough to post
> > the Exim version that exhibits the problem and any relevant settings,
> > that would help narrow down the problem.
>
> Also the version of GnuTLS with which Exim is linked.

Looking at the source code of GnuTLS 3.2.4 (really master branch
from "git" which is 3.2.4 plus some new code) I see that with GnuTLS
priority strings the "Normal" security level defaults to a minimum
DH bit length of 2432, which is perhaps sound cryptography, but poor
engineering:

  typedef struct
  {
    const char *name;
    gnutls_sec_param_t sec_param;
    unsigned int bits;                     /* security level */
    unsigned int pk_bits;                  /* DH, RSA, SRP */
    unsigned int dsa_bits;                 /* bits for DSA. Handled differently since
                                   * choice of key size in DSA is political.
                                   */
    unsigned int subgroup_bits;            /* subgroup bits */
    unsigned int ecc_bits;                 /* bits for ECC keys */
  } gnutls_sec_params_entry;

  static const gnutls_sec_params_entry sec_params[] = {
    {"Insecure", GNUTLS_SEC_PARAM_INSECURE, 0, 0, 0, 0, 0},
    {"Export", GNUTLS_SEC_PARAM_EXPORT, 42, 512, 0, 0, 0},
    {"Very weak", GNUTLS_SEC_PARAM_VERY_WEAK, 64, 727, 0, 0, 0},
    {"Weak", GNUTLS_SEC_PARAM_WEAK, 72, 1008, 1024, 160, 160},
    {"Low", GNUTLS_SEC_PARAM_LOW, 80, 1248, 2048, 160, 160},
    {"Legacy", GNUTLS_SEC_PARAM_LEGACY, 96, 1776, 2048, 192, 192},
    {"Normal", GNUTLS_SEC_PARAM_NORMAL, 112, 2432, 3072, 224, 224},
    {"High", GNUTLS_SEC_PARAM_HIGH, 128, 3248, 3072, 256, 256},
    {"Ultra", GNUTLS_SEC_PARAM_ULTRA, 256, 15424, 3072, 512, 512},
    {NULL, 0, 0, 0, 0, 0}
  };

The point is that the TLS protocol does not support negotiation of
the DH parameters between client and server, so client enforcement
of strong DH parameters that exceed common practice is rather unwise.

Clearly at least some versions of Exim work around the problem by
expliciting setting a floor of 1024-bits (which interoperates with
OpenSSL, ...).  It seems there may be some versions of Exim in which
the work-around is absent or not effective.

More fundamentally, this is a problem with GnuTLS pushing the
envelope too aggressively.  Before TLS clients start being pedantic
about key lengths in auxiliary algorithms, most server implementations
need to be updated to implement said key lengths with corresponding
SSL cipher-suites.

This means that the GnuTLS developers need to talk to the NSS,
OpenSSL, Microsoft Crypto API, ... developers and reach consensus
on server EDH implementations before rather than just field
non-interoperable clients and push the problem to users and
applications.  This may require a TLSv1.3 revision in which
MODP DH key lengths are also negotiated (and more efficient
DH agreement is supported via DSA-style parameters with a
secure subgroup whose size is double the symmetric key size as
in the RFC 5114 groups).

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Postfix User-2
On Mon, 2 Sep 2013 22:14:42 +0000
Viktor Dukhovni articulated:

> On Mon, Sep 02, 2013 at 03:03:36AM +0000, Viktor Dukhovni wrote:
>
> > On Mon, Sep 02, 2013 at 01:25:02AM +0000, Viktor Dukhovni wrote:
> >
> > > If Peer Heinlein would be kind enough to post
> > > the Exim version that exhibits the problem and any relevant
> > > settings, that would help narrow down the problem.
> >
> > Also the version of GnuTLS with which Exim is linked.
>
> Looking at the source code of GnuTLS 3.2.4 (really master branch
> from "git" which is 3.2.4 plus some new code) I see that with GnuTLS
> priority strings the "Normal" security level defaults to a minimum
> DH bit length of 2432, which is perhaps sound cryptography, but poor
> engineering:
>
>   typedef struct
>   {
>     const char *name;
>     gnutls_sec_param_t sec_param;
>     unsigned int bits;                     /* security level */
>     unsigned int pk_bits;                  /* DH, RSA, SRP */
>     unsigned int dsa_bits;                 /* bits for DSA. Handled
> differently since
>   * choice of key size in DSA is
> political. */
>     unsigned int subgroup_bits;            /* subgroup bits */
>     unsigned int ecc_bits;                 /* bits for ECC keys */
>   } gnutls_sec_params_entry;
>
>   static const gnutls_sec_params_entry sec_params[] = {
>     {"Insecure", GNUTLS_SEC_PARAM_INSECURE, 0, 0, 0, 0, 0},
>     {"Export", GNUTLS_SEC_PARAM_EXPORT, 42, 512, 0, 0, 0},
>     {"Very weak", GNUTLS_SEC_PARAM_VERY_WEAK, 64, 727, 0, 0, 0},
>     {"Weak", GNUTLS_SEC_PARAM_WEAK, 72, 1008, 1024, 160, 160},
>     {"Low", GNUTLS_SEC_PARAM_LOW, 80, 1248, 2048, 160, 160},
>     {"Legacy", GNUTLS_SEC_PARAM_LEGACY, 96, 1776, 2048, 192, 192},
>     {"Normal", GNUTLS_SEC_PARAM_NORMAL, 112, 2432, 3072, 224, 224},
>     {"High", GNUTLS_SEC_PARAM_HIGH, 128, 3248, 3072, 256, 256},
>     {"Ultra", GNUTLS_SEC_PARAM_ULTRA, 256, 15424, 3072, 512, 512},
>     {NULL, 0, 0, 0, 0, 0}
>   };
>
> The point is that the TLS protocol does not support negotiation of
> the DH parameters between client and server, so client enforcement
> of strong DH parameters that exceed common practice is rather unwise.
>
> Clearly at least some versions of Exim work around the problem by
> expliciting setting a floor of 1024-bits (which interoperates with
> OpenSSL, ...).  It seems there may be some versions of Exim in which
> the work-around is absent or not effective.
>
> More fundamentally, this is a problem with GnuTLS pushing the
> envelope too aggressively.  Before TLS clients start being pedantic
> about key lengths in auxiliary algorithms, most server implementations
> need to be updated to implement said key lengths with corresponding
> SSL cipher-suites.
>
> This means that the GnuTLS developers need to talk to the NSS,
> OpenSSL, Microsoft Crypto API, ... developers and reach consensus
> on server EDH implementations before rather than just field
> non-interoperable clients and push the problem to users and
> applications.  This may require a TLSv1.3 revision in which
> MODP DH key lengths are also negotiated (and more efficient
> DH agreement is supported via DSA-style parameters with a
> secure subgroup whose size is double the symmetric key size as
> in the RFC 5114 groups).

Viktor, that is an extremely sound, well thought out approach. However,
those happy folks at GunTLS rarely talk to or even acknowledge the
"OpenSSL" folks. I have no idea what their feeling are towards
Microsoft, etcetera, but I doubt that it is favorable. Personally, this
is one reason I stear clear of GnuTLS whenever possible.

Just my 2¢.

--
Jerry ✌
[hidden email]
_____________________________________________________________________
TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html

Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Phil Pennock
In reply to this post by Wietse Venema
-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

On 2013-09-01 at 19:02 -0400, Wietse Venema wrote:
> Second, we have to be mindful that Postfix and Exim are not the
> only MTAs in existence. If placating Exim results in the loss of
> interoperability with other MTAs, then we may have to reconsider
> our approach.

Okay, I have identified the root cause.  The systems that need to be
placated are older Debian installs, and the method should be broadly
compatible.

Debian used to patch, in their build system, the value passed to
gnutls_dh_set_prime_bits() from 1024 to 2048.  This is the value of the
size of the DH parameters which is the "minimum considered acceptable".
So Debian broke interop with "66_enlarge-dh-parameters-size.dpatch".

Those maintaining Exim/Postfix setups should upgrade Exim to a recent
version; after my overhaul back in 4.80, Debian stopped changing the
value in their patches.

The most compatible thing I know of for Postfix users to do is to
generate DH parameters of size 2048, or very slightly larger, but *not*
larger than 2236, which was for some time the NSS value of
DH_MAX_P_BITS.

If anyone knows of an MTA with which interop would be broken by using
server DH parameters of size 2048, please do let me know.

- -Phil
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAlImO3EACgkQQDBDFTkDY39a6ACaA2XfA32nQ/x4m83xpFEjoB7r
zK0AmQGZ9HSdaNELVjWQ+YaOZhXMMN0c
=vd9e
-----END PGP SIGNATURE-----
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Peer Heinlein
Am 03.09.2013 21:41, schrieb Phil Pennock:


Hi,

> Debian used to patch, in their build system, the value passed to
> gnutls_dh_set_prime_bits() from 1024 to 2048.  This is the value of the
> size of the DH parameters which is the "minimum considered acceptable".
> So Debian broke interop with "66_enlarge-dh-parameters-size.dpatch".
>
> Those maintaining Exim/Postfix setups should upgrade Exim to a recent
> version; after my overhaul back in 4.80, Debian stopped changing the
> value in their patches.

Great. Thanks to Phil and Viktor for their great work. Really THANKS.

Debian should release a security fix update for their old packages...
That would be the best, fastest and most secure way to solve the problem
finally.

Peer


--
Heinlein Support GmbH
Schwedter Str. 8/9b, 10119 Berlin

http://www.heinlein-support.de

Tel: 030 / 405051-42
Fax: 030 / 405051-19

Zwangsangaben lt. §35a GmbHG: HRB 93818 B / Amtsgericht
Berlin-Charlottenburg,
Geschäftsführer: Peer Heinlein -- Sitz: Berlin
Reply | Threaded
Open this post in threaded view
|

Re: Exim, DH, GnuTLS & interop

Viktor Dukhovni
In reply to this post by Phil Pennock
On Tue, Sep 03, 2013 at 12:41:46PM -0700, Phil Pennock wrote:

> Okay, I have identified the root cause.  The systems that need to be
> placated are older Debian installs, and the method should be broadly
> compatible.
>
> Debian used to patch, in their build system, the value passed to
> gnutls_dh_set_prime_bits() from 1024 to 2048.  This is the value of the
> size of the DH parameters which is the "minimum considered acceptable".
> So Debian broke interop with "66_enlarge-dh-parameters-size.dpatch".

Thanks, this is very useful.  So the Postfix work-around for servers
that want to receive email over TLS from the broken Debian systems is:

    # cd /etc/postfix
    # openssl dhparam -out dh2048.pem 2048
    # postconf -e 'smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem'

If your openssl(1) version is 1.0.0 or higher, your server may
perform faster if you generate DSA-style parameters:

    # openssl dhparam -dsaparam -out dh2048.pem 2048

The "smtpd_tls_dh1024_param_file" is in effect the DH parameter
set for all non-export cipher-suites.  It is OK to use a 2048-bit
prime group in this context, provided the CPU cost is acceptable
(generally TLS handshake CPU cost is not on the critical path for
SMTP throughput) and no SMTP clients choke on the larger DH prime.

No changes should be necessary for the default Postfix EECDH curve,
it is strong enough to meet the default lower bounds for GnuTLS,
and Debian likely did not patch this value (in GnuTLS rather than Exim).

Only the "Ultra" priority String in GnuTLS requires EC curves with
more than 256-bits:

    {
     "Ultra", /* Name */
     GNUTLS_SEC_PARAM_ULTRA, /* Enum */
     256, /* Symmetric bits */
     15424, /* RSA/EDH modulus bits */
     3072, /* DSA bits */
     512, /* subgroup bits */
     512 /* EC bits */
    },

We can reasonably assume that no MTA is configured to use the
"Ultra" security level as a default for all Internet destinations.

--
        Viktor.