Loading ...
Sorry, an error occurred while loading the content.

Exim, DH, GnuTLS & interop

Expand Messages
  • Phil Pennock
    ... Hash: RIPEMD160 Folks, sorry this isn t threading: I subscribed to this list to post after being pointed by Viktor at:
    Message 1 of 10 , Sep 1, 2013
    • 0 Attachment
      -----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, pdp@... 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-----
    • 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
      Message 2 of 10 , Sep 1, 2013
      • 0 Attachment
        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
      • Viktor Dukhovni
        ... 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
        Message 3 of 10 , Sep 1, 2013
        • 0 Attachment
          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.
        • Viktor Dukhovni
          ... 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
          Message 4 of 10 , Sep 1, 2013
          • 0 Attachment
            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.
          • Viktor Dukhovni
            ... Also the version of GnuTLS with which Exim is linked. -- Viktor.
            Message 5 of 10 , Sep 1, 2013
            • 0 Attachment
              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.
            • Viktor Dukhovni
              ... 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
              Message 6 of 10 , Sep 2, 2013
              • 0 Attachment
                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.
              • Jerry
                On Mon, 2 Sep 2013 22:14:42 +0000 ... Viktor, that is an extremely sound, well thought out approach. However, those happy folks at GunTLS rarely talk to or
                Message 7 of 10 , Sep 3, 2013
                • 0 Attachment
                  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 ✌
                  postfix-user@...
                  _____________________________________________________________________
                  TO REPORT A PROBLEM see http://www.postfix.org/DEBUG_README.html#mail
                  TO (UN)SUBSCRIBE see http://www.postfix.org/lists.html
                • Phil Pennock
                  ... Hash: RIPEMD160 ... Okay, I have identified the root cause. The systems that need to be placated are older Debian installs, and the method should be
                  Message 8 of 10 , Sep 3, 2013
                  • 0 Attachment
                    -----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-----
                  • Peer Heinlein
                    Am 03.09.2013 21:41, schrieb Phil Pennock: Hi, ... Great. Thanks to Phil and Viktor for their great work. Really THANKS. Debian should release a security fix
                    Message 9 of 10 , Sep 3, 2013
                    • 0 Attachment
                      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
                    • Viktor Dukhovni
                      ... 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
                      Message 10 of 10 , Sep 3, 2013
                      • 0 Attachment
                        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.
                      Your message has been successfully submitted and would be delivered to recipients shortly.