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

EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

Expand Messages
  • lists@rhsoft.net
    postfix/smtp[7411]: warning: TLS library problem: 7411:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316 maybe
    Message 1 of 16 , Oct 21 12:43 PM
      postfix/smtp[7411]: warning: TLS library problem: 7411:error:100AE081:elliptic curve
      routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316

      maybe relevant to "only ECC NIST Suite B curves support"?
      postfix was compiled against exactly this openssl build
      as far as i can see fallback to unecrypted connection

      http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
      * Wed Oct 16 2013 Tomáš Mráz <tmraz@...> 1.0.1e-28
      - only ECC NIST Suite B curves support
      - drop -fips subpackage

      * Mon Oct 14 2013 Tom Callaway <spot@...>
      - 1.0.1e-27
      - resolve bugzilla 319901 (phew! only took 6 years & 9 days)
    • Viktor Dukhovni
      ... Until recently, there was no ECC support in RedHat (and Fedora) OpenSSL packages. It seems that a few weeks ago they finally enabled ECC, but could not
      Message 2 of 16 , Oct 21 2:04 PM
        On Mon, Oct 21, 2013 at 09:43:50PM +0200, lists@... wrote:

        > postfix/smtp[7411]: warning: TLS library problem: 7411:error:100AE081:elliptic curve
        > routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316
        >
        > maybe relevant to "only ECC NIST Suite B curves support"?
        > postfix was compiled against exactly this openssl build
        > as far as i can see fallback to unecrypted connection
        >
        > http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
        > * Wed Oct 16 2013 Tom?? Mr?z <tmraz@...> 1.0.1e-28
        > - only ECC NIST Suite B curves support
        > - drop -fips subpackage
        >
        > * Mon Oct 14 2013 Tom Callaway <spot@...>
        > - 1.0.1e-27
        > - resolve bugzilla 319901 (phew! only took 6 years & 9 days)

        Until recently, there was no ECC support in RedHat (and Fedora)
        OpenSSL packages. It seems that a few weeks ago they finally
        enabled ECC, but could not resist the urge to cripple it a bit. :-)

        Instead of improving the world by finally supporting EC, they've
        made things worse! Previously clients negotiated something other
        than EECDH key exchange, now they negotiate it and fail! Sorry to
        say so, but the RedHat engineers need adult supervision.

        What site was your SMTP client connecting to? IIRC Suite B supports
        prime256v1 (aka secp256r1) and secp384r1. Perhaps the SMTP server
        decided to live on the bleeding edge with "secp521r1".

        An Exim server with GnuTLS? A Postfix administrator who did not
        believe my advice?

        tls_eecdh_strong_curve (default: prime256v1)

        The elliptic curve used by the Postfix SMTP server for
        sensibly strong ephemeral ECDH key exchange. This curve is
        used by the Postfix SMTP server when "smtpd_tls_eecdh_grade
        = strong". The phrase "sensibly strong" means approximately
        128-bit security based on best known attacks. The selected
        curve must be implemented by OpenSSL (as reported by
        ecparam(1) with the "-list_curves" option) and be one of
        the curves listed in Section 5.1.1 of RFC 4492. You should
        not generally change this setting.

        tls_eecdh_ultra_curve (default: secp384r1)

        The elliptic curve used by the Postfix SMTP server for
        maximally strong ephemeral ECDH key exchange. This curve
        is used by the Postfix SMTP server when "smtpd_tls_eecdh_grade
        = ultra". The phrase "maximally strong" means approximately
        192-bit security based on best known attacks. This additional
        strength comes at a significant computational cost, most
        users should instead set "smtpd_tls_eecdh_grade = strong".
        The selected curve must be implemented by OpenSSL (as
        reported by ecparam(1) with the "-list_curves" option) and
        be one of the curves listed in Section 5.1.1 of RFC 4492.
        You should not generally change this setting.

        On an "improved" RedHat system you may be better off with kEECDH
        ciphers disabled on the client side:

        smtp_tls_exclude_ciphers = kEECDH

        --
        Viktor.
      • lists@rhsoft.net
        ... looks so ... since you sound very knowledgeable about SSL may you consider to make a comment there? https://bugzilla.redhat.com/show_bug.cgi?id=1019251
        Message 3 of 16 , Oct 21 2:17 PM
          Am 21.10.2013 23:04, schrieb Viktor Dukhovni:
          > On Mon, Oct 21, 2013 at 09:43:50PM +0200, lists@... wrote:
          >
          >> postfix/smtp[7411]: warning: TLS library problem: 7411:error:100AE081:elliptic curve
          >> routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316
          >>
          >> maybe relevant to "only ECC NIST Suite B curves support"?
          >> postfix was compiled against exactly this openssl build
          >> as far as i can see fallback to unecrypted connection
          >>
          >> http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
          >> * Wed Oct 16 2013 Tom?? Mr?z <tmraz@...> 1.0.1e-28
          >> - only ECC NIST Suite B curves support
          >> - drop -fips subpackage
          >>
          >> * Mon Oct 14 2013 Tom Callaway <spot@...>
          >> - 1.0.1e-27
          >> - resolve bugzilla 319901 (phew! only took 6 years & 9 days)
          >
          > Until recently, there was no ECC support in RedHat (and Fedora)
          > OpenSSL packages. It seems that a few weeks ago they finally
          > enabled ECC, but could not resist the urge to cripple it a bit. :-)

          looks so

          > Instead of improving the world by finally supporting EC, they've
          > made things worse! Previously clients negotiated something other
          > than EECDH key exchange, now they negotiate it and fail! Sorry to
          > say so, but the RedHat engineers need adult supervision.

          since you sound very knowledgeable about SSL may you consider
          to make a comment there?

          https://bugzilla.redhat.com/show_bug.cgi?id=1019251

          fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=471397
          crippled: http://koji.fedoraproject.org/koji/buildinfo?buildID=471781

          with the first build no single error

          > What site was your SMTP client connecting to? IIRC Suite B supports
          > prime256v1 (aka secp256r1) and secp384r1. Perhaps the SMTP server
          > decided to live on the bleeding edge with "secp521r1"

          as far as i can see in all 8 cases currently to GMX

          Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to mx00.gmx.net[213.165.67.99]:25: -1
          Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:100AE081:elliptic curve
          routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
          Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:1408D010:SSL
          routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
          Oct 21 22:29:22 mail postfix/smtp[12289]: 3d3Tvy5Cdsz23: Cannot start TLS: handshake failure
        • Viktor Dukhovni
          ... I have enough fish to fry. The problem is obvious, client promises EECDH support, server sends a standard curve name and the client promptly fails because
          Message 4 of 16 , Oct 21 2:40 PM
            On Mon, Oct 21, 2013 at 11:17:25PM +0200, lists@... wrote:

            > > Instead of improving the world by finally supporting EC, they've
            > > made things worse! Previously clients negotiated something other
            > > than EECDH key exchange, now they negotiate it and fail! Sorry to
            > > say so, but the RedHat engineers need adult supervision.
            >
            > since you sound very knowledgeable about SSL may you consider
            > to make a comment there?
            >
            > https://bugzilla.redhat.com/show_bug.cgi?id=1019251

            I have enough fish to fry. The problem is obvious, client promises
            EECDH support, server sends a standard curve name and the client
            promptly fails because its list of supported curves is incomplete.

            Of course you should capture a session with wireshark and see what
            curve the server sends back to confirm this obvious interpretation.

            > fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=471397
            > crippled: http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
            >
            > with the first build no single error

            I think you know what to do...

            > > What site was your SMTP client connecting to? IIRC Suite B supports
            > > prime256v1 (aka secp256r1) and secp384r1. Perhaps the SMTP server
            > > decided to live on the bleeding edge with "secp521r1"
            >
            > as far as i can see in all 8 cases currently to GMX
            >
            > Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to
            > mx00.gmx.net[213.165.67.99]:25: -1
            > Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:100AE081:elliptic curve
            > routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
            > Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:1408D010:SSL
            > routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
            > Oct 21 22:29:22 mail postfix/smtp[12289]: 3d3Tvy5Cdsz23: Cannot start TLS: handshake failure
            >

            When I test connections to this host, I always get "AES256-SHA",
            and no EDH or kEECDH ciphers are accepted. Did gmx.de change their
            configuration to work around this? Can you build posttls-finger (from 2.11)
            and test with:

            $ posttls-finger -t30 -T 180 -p TLSv1.2 -Ldebug \
            -o tls_medium_cipherlist='kEECDH:kEDH:kRSA' \
            "[213.165.67.99]"

            do you get handshake failures?

            --
            Viktor.
          • lists@rhsoft.net
            ... looking at the logs where ECDHE worked fine with the intermediate openssl and started to fail to mx00.gmx.net after the crippleded update i think the
            Message 5 of 16 , Oct 21 2:49 PM
              Am 21.10.2013 23:40, schrieb Viktor Dukhovni:
              > On Mon, Oct 21, 2013 at 11:17:25PM +0200, lists@... wrote:
              >
              >>> Instead of improving the world by finally supporting EC, they've
              >>> made things worse! Previously clients negotiated something other
              >>> than EECDH key exchange, now they negotiate it and fail! Sorry to
              >>> say so, but the RedHat engineers need adult supervision.
              >>
              >> since you sound very knowledgeable about SSL may you consider
              >> to make a comment there?
              >>
              >> https://bugzilla.redhat.com/show_bug.cgi?id=1019251
              >
              > I have enough fish to fry. The problem is obvious, client promises
              > EECDH support, server sends a standard curve name and the client
              > promptly fails because its list of supported curves is incomplete.
              >
              > Of course you should capture a session with wireshark and see what
              > curve the server sends back to confirm this obvious interpretation.

              looking at the logs where ECDHE worked fine with the intermediate openssl
              and started to fail to "mx00.gmx.net" after the crippleded update i
              think the situation is clear

              >> fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=471397
              >> crippled: http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
              >>
              >> with the first build no single error
              >
              > I think you know what to do...

              maintain openssl at my own is above my scope i fear :-(

              well, i rebuild the package with "rpm --rebuild" but they strip parts out of the
              source-tarball and even in my situation building dovecot/postfix/httpd with
              complete own packages it leaves a bad taste of danger try to maintain a
              different openssl in context of other packages

              i hate it to ask but is there any change postfix avoids ECDHE for such destinations
              in case of this situation and continues to use DHE if the requested curve is not
              available in the linked openssl library?

              >> as far as i can see in all 8 cases currently to GMX
              >>
              >> Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to
              >> mx00.gmx.net[213.165.67.99]:25: -1
              > When I test connections to this host, I always get "AES256-SHA",
              > and no EDH or kEECDH ciphers are accepted. Did gmx.de change their
              > configuration to work around this? Can you build posttls-finger (from 2.11)
              > and test with:
              >
              > $ posttls-finger -t30 -T 180 -p TLSv1.2 -Ldebug \
              > -o tls_medium_cipherlist='kEECDH:kEDH:kRSA' \
              > "[213.165.67.99]"
              >
              > do you get handshake failures?

              no "posttls-finger" here but the logs below are a clear language i think
              Oct 21 20:16:43 Updated: 1:openssl-libs-1.0.1e-28.fc18.x86_64

              Oct 21 19:08:27 mail postfix/smtp[13875]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25:
              TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
              Oct 21 19:36:37 mail postfix/smtp[15749]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25:
              TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
              Oct 21 19:59:48 mail postfix/smtp[17217]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25:
              TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

              https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3
            • lists@rhsoft.net
              ... also interesting, from one postfix to another using the same postfix/openssl builds exactly the same previously to GMX used ciphers are still fine - leaves
              Message 6 of 16 , Oct 21 2:55 PM
                Am 21.10.2013 23:49, schrieb lists@...:
                > i hate it to ask but is there any change postfix avoids ECDHE for such destinations
                > in case of this situation and continues to use DHE if the requested curve is not
                > available in the linked openssl library?
                >
                >>> as far as i can see in all 8 cases currently to GMX
                >>>
                >>> Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to
                >>> mx00.gmx.net[213.165.67.99]:25: -1
                >> When I test connections to this host, I always get "AES256-SHA",
                >> and no EDH or kEECDH ciphers are accepted. Did gmx.de change their
                >> configuration to work around this? Can you build posttls-finger (from 2.11)
                >> and test with:
                >>
                >> $ posttls-finger -t30 -T 180 -p TLSv1.2 -Ldebug \
                >> -o tls_medium_cipherlist='kEECDH:kEDH:kRSA' \
                >> "[213.165.67.99]"
                >>
                >> do you get handshake failures?
                >
                > no "posttls-finger" here but the logs below are a clear language i think
                > Oct 21 20:16:43 Updated: 1:openssl-libs-1.0.1e-28.fc18.x86_64
                >
                > Oct 21 19:08:27 mail postfix/smtp[13875]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25:
                > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
                > Oct 21 19:36:37 mail postfix/smtp[15749]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25:
                > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
                > Oct 21 19:59:48 mail postfix/smtp[17217]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25:
                > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
                >
                > https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3

                also interesting, from one postfix to another using the same postfix/openssl builds
                exactly the same previously to GMX used ciphers are still fine - leaves the question
                open what exactly does "mx00.gmx.net" differently to fail now

                Oct 21 23:52:45 localhost postfix/smtp[27178]: Trusted TLS connection established to *****:25: TLSv1.2 with cipher
                ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
              • Viktor Dukhovni
                ... What is less clear is what EC curve gmx.de actually sends down the wire. Is it something exotic, that few sites would support, or is it something more
                Message 7 of 16 , Oct 21 3:51 PM
                  On Mon, Oct 21, 2013 at 11:49:48PM +0200, lists@... wrote:

                  > >> since you sound very knowledgeable about SSL may you consider
                  > >> to make a comment there?
                  > >>
                  > >> https://bugzilla.redhat.com/show_bug.cgi?id=1019251
                  > >
                  > > I have enough fish to fry. The problem is obvious, client promises
                  > > EECDH support, server sends a standard curve name and the client
                  > > promptly fails because its list of supported curves is incomplete.
                  > >
                  > > Of course you should capture a session with wireshark and see what
                  > > curve the server sends back to confirm this obvious interpretation.
                  >
                  > looking at the logs where ECDHE worked fine with the intermediate openssl
                  > and started to fail to "mx00.gmx.net" after the crippleded update I
                  > think the situation is clear

                  What is less clear is what EC curve gmx.de actually sends down the
                  wire. Is it something exotic, that few sites would support, or is
                  it something more vanilla like secp521r1 which RedHat seem to have
                  deliberately left out of their implementation.

                  > >> fine: http://koji.fedoraproject.org/koji/buildinfo?buildID=471397
                  > >> crippled: http://koji.fedoraproject.org/koji/buildinfo?buildID=471781
                  > >>
                  > >> with the first build no single error
                  > >
                  > > I think you know what to do...
                  >
                  > maintain openssl at my own is above my scope i fear :-(

                  No, you report the bug. You're running their software, you can
                  reproduce failure cases. Make it clear to them that half-implementing
                  EC support is worse than not implementing EC support.

                  > i hate it to ask but is there any change postfix avoids ECDHE for such destinations
                  > in case of this situation and continues to use DHE if the requested curve is not
                  > available in the linked openssl library?

                  Postfix allows you to skip EECDH and ECDSA globally or for selected sites via
                  smtp_tls_policy_maps.

                  main.cf:
                  # SMTP client only:
                  smtp_tls_exclude_ciphers = ECDH

                  tls_policy:
                  example.com encrypt exclude=ECDH protocols=!SSLv2,!SSLv3

                  If you disable SSLv3 (as well as SSLv2) your SMTP client will send
                  the list of supported EC curves to the server via a suitable TLSv1
                  extension.

                  Some servers may be able to make use of this to choose a compatible
                  curve. Postfix is not among these yet, as OpenSSL does not yet
                  (before the unreleased 1.0.2 version) expose the requisite API
                  functions to allow server applications to register multiple curves
                  or leave the choice to OpenSSL.

                  So mostly, you lose, until RedHat fixes the bug.

                  > > When I test connections to this host, I always get "AES256-SHA",
                  > > and no EDH or kEECDH ciphers are accepted. Did gmx.de change their
                  > > configuration to work around this? Can you build posttls-finger (from 2.11)
                  > > and test with:
                  > >
                  > > $ posttls-finger -t30 -T 180 -p TLSv1.2 -Ldebug \
                  > > -o tls_medium_cipherlist='kEECDH:kEDH:kRSA' \
                  > > "[213.165.67.99]"
                  > >
                  > > do you get handshake failures?
                  >
                  > no "posttls-finger" here but the logs below are a clear language i think

                  The idea is to compile it from 2.11 snapshot sources.

                  --
                  Viktor.
                • Viktor Dukhovni
                  ... The author of comment #4 is not getting it. The problem is NOT that Postfix fails to negotiate EECDH, rather the problem is that it does! Once EECDH is
                  Message 8 of 16 , Oct 21 5:33 PM
                    On Mon, Oct 21, 2013 at 11:55:38PM +0200, lists@... wrote:

                    > > https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3

                    The author of comment #4 is not getting it. The problem is NOT
                    that Postfix fails to negotiate EECDH, rather the problem is that
                    it does! Once EECDH is negotiated, the server (gmx) selects an
                    unsupported (by RedHat's crippled OpenSSL) curve and the handshake
                    fails.

                    This is NOT progress. No support for EC is better than broken
                    support for EC. Either implement EC support or don't.

                    > also interesting, from one postfix to another using the same postfix/openssl builds
                    > exactly the same previously to GMX used ciphers are still fine - leaves the question
                    > open what exactly does "mx00.gmx.net" differently to fail now
                    >
                    > Oct 21 23:52:45 localhost postfix/smtp[27178]:
                    > Trusted TLS connection established to *****:25:
                    > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

                    I don't understand what you mean, feel free to elaborate.

                    --
                    Viktor.
                  • lists@rhsoft.net
                    ... this guy did the absusive change too :-( ... yes, frsutrating, but better start with something crippeled and hope it improves than wait another 6 years ...
                    Message 9 of 16 , Oct 21 6:19 PM
                      Am 22.10.2013 02:33, schrieb Viktor Dukhovni:
                      > On Mon, Oct 21, 2013 at 11:55:38PM +0200, lists@... wrote:
                      >
                      >>> https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3
                      >
                      > The author of comment #4 is not getting it. The problem is NOT
                      > that Postfix fails to negotiate EECDH, rather the problem is that
                      > it does! Once EECDH is negotiated, the server (gmx) selects an
                      > unsupported (by RedHat's crippled OpenSSL) curve and the handshake
                      > fails.

                      this guy did the absusive change too :-(

                      > This is NOT progress. No support for EC is better than broken
                      > support for EC. Either implement EC support or don't.

                      yes, frsutrating, but better start with something crippeled and
                      hope it improves than wait another 6 years

                      >> also interesting, from one postfix to another using the same postfix/openssl builds
                      >> exactly the same previously to GMX used ciphers are still fine - leaves the question
                      >> open what exactly does "mx00.gmx.net" differently to fail now
                      >>
                      >> Oct 21 23:52:45 localhost postfix/smtp[27178]:
                      >> Trusted TLS connection established to *****:25:
                      >> TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
                      >
                      > I don't understand what you mean, feel free to elaborate.

                      my two postfix servers are using exactly the same ciphers as
                      was used before the change with success to GMX, but maybe i
                      am not knoledgeable enough to understand the deep details...
                    • Viktor Dukhovni
                      ... I disagree. Shipping non-interoperable broken code that everyone else is forced to work-around is not progress. ... I can t connect to gmx s SMTP servers
                      Message 10 of 16 , Oct 21 7:35 PM
                        On Tue, Oct 22, 2013 at 03:19:41AM +0200, lists@... wrote:

                        > > This is NOT progress. No support for EC is better than broken
                        > > support for EC. Either implement EC support or don't.
                        >
                        > yes, frustrating, but better start with something crippled and
                        > hope it improves than wait another 6 years.

                        I disagree. Shipping non-interoperable broken code that everyone
                        else is forced to work-around is not progress.

                        > > > also interesting, from one postfix to another using the same
                        > > > postfix/openssl builds exactly the same previously to GMX used
                        > > > ciphers are still fine - leaves the question open what exactly does
                        > > > "mx00.gmx.net" differently to fail now
                        > > >
                        > > > Oct 21 23:52:45 localhost postfix/smtp[27178]:
                        > > > Trusted TLS connection established to *****:25:
                        > > > TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
                        > >
                        > > I don't understand what you mean, feel free to elaborate.
                        >
                        > My two postfix servers are using exactly the same ciphers as
                        > was used before the change with success to GMX, but maybe I
                        > am not knowledgeable enough to understand the deep details...

                        I can't connect to gmx's SMTP servers on port 25 from my laptop
                        since I am on a residential dynamic IP. On port 587 however, I
                        can definitely confirm that [smtp.gmx.de]:587 is using secp521r1,
                        which is one of the curves removed by RedHat. It seems likely
                        that they do the same on port 25.

                        If you have a server that negotiates EECDH with gmx.de, either your
                        OpenSSL runtime is not crippled, or they're using a different curve
                        on that server.

                        In wireshark, if you select the server Certificate packet for a fresh
                        (not resumed) session, it will contain multiple Handshake messages.
                        One of these will be the "Server Key Exchange" message, if you
                        click on its length field, wireshark will show the corresponding
                        3 bytes in the hex packet dump. Immediately after these, is the
                        actual payload, which for an ECDHE ciphersuite with a named curve
                        will start with "03" and then a 2-byte curve id. The ids of
                        interest are:

                        sect163k1 (0x0001), sect163r1 (0x0002), sect163r2 (0x0003),
                        sect193r1 (0x0004), sect193r2 (0x0005), sect233k1 (0x0006),
                        sect233r1 (0x0007), sect239k1 (0x0008), sect283k1 (0x0009),
                        sect283r1 (0x000a), sect409k1 (0x000b), sect409r1 (0x000c),
                        sect571k1 (0x000d), sect571r1 (0x000e), secp160k1 (0x000f),
                        secp160r1 (0x0010), secp160r2 (0x0011), secp192k1 (0x0012),
                        secp192r1 (0x0013), secp224k1 (0x0014), secp224r1 (0x0015),
                        secp256k1 (0x0016), secp256r1 (0x0017), secp384r1 (0x0018),
                        secp521r1 (0x0019)

                        The "strong" and "ultra" curves for Postfix SMTP servers default
                        to (and *really* should not at this time be changed from) secp256r1
                        (or 0x0017) and secp384r1 (or 0x0018) respectively. The wireshark
                        trace from gmx.de has a Server Key Exchange payload starting with:

                        03 00 19

                        so their PRISM knee-jerk response was to switch to secp521r1, thus
                        ensuring non-interoperability with RedHat's OpenSSL client software.

                        I don't believe gmx.de runs Postfix, so I can't accuse them of
                        failing to read the tls_eecdh_strong_curve and tls_eecdh_ultra_curve
                        parameter documentation. They're shooting themselves in the foot
                        without ignoring my advice. :-)

                        --
                        Viktor.
                      • Viktor Dukhovni
                        ... Not knowing how TLS works in real life, should disqualify one from ... Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4), there is either a
                        Message 11 of 16 , Oct 21 11:07 PM
                          On Tue, Oct 22, 2013 at 03:19:41AM +0200, lists@... wrote:

                          > >>> https://bugzilla.redhat.com/show_bug.cgi?id=1019390#c3
                          > >
                          > > The author of comment #4 is not getting it. The problem is NOT
                          > > that Postfix fails to negotiate EECDH, rather the problem is that
                          > > it does! Once EECDH is negotiated, the server (gmx) selects an
                          > > unsupported (by RedHat's crippled OpenSSL) curve and the handshake
                          > > fails.
                          >
                          > this guy did the abusive change too :-(

                          Not knowing how TLS works in real life, should disqualify one from
                          meddling with TLS implementations. From the bug report:

                          ---
                          Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4),
                          there is either a bug in the server or the client isn't offering
                          the extension advertising the curves it supports.
                          ---

                          * Firstly, client TLS extensions are not possible when the client starts
                          with an SSLv2 compatible SSL HELLO. So the list of supported curves
                          is not sent by clients that are backwards compatible with SSLv2 (though
                          of course by now SSLv2 should be disabled in most clients).

                          * Secondly, the OpenSSL server API does not expose the client's
                          supported EC curves to the server application which is expected
                          to configure the EECDH curve. Thus the extension from RFC 4492
                          is almost never used, most servers choose the EECDH curve blindly.

                          * Auto-configuration of the server curve (in response to client
                          extensions) is coming in OpenSSL 1.0.2 which is not yet released!

                          ---
                          You need to get the protocol message trace in order to determine
                          which. If it's client-side, the bug is (probably) against
                          Postfix. If you want openssl to support more curves, you should
                          file a new bug.
                          ---

                          Postfix just calls SSL_connect() after configuring the protocol mask
                          and cipherlist. It has little influence over the SSL HELLO extension
                          processing (with DANE in 2.10 it may request SNI).

                          The RedHat OpenSSL EC implementation with most of the curves missing
                          is worse than no EC. I don't care whether a new bug report is
                          filed or not, but they need to fix the mess.

                          --
                          Viktor.
                        • Viktor Dukhovni
                          On Tue, Oct 22, 2013 at 06:07:49AM +0000, Viktor Dukhovni wrote: Follow-up, comments after a brief email discussion with Paul Wouters ... This is still an
                          Message 12 of 16 , Oct 23 1:57 PM
                            On Tue, Oct 22, 2013 at 06:07:49AM +0000, Viktor Dukhovni wrote:

                            Follow-up, comments after a brief email discussion with Paul Wouters
                            of RedHat:

                            > * Firstly, client TLS extensions are not possible when the client starts
                            > with an SSLv2 compatible SSL HELLO. So the list of supported curves
                            > is not sent by clients that are backwards compatible with SSLv2 (though
                            > of course by now SSLv2 should be disabled in most clients).

                            This is still an issue, but nobody should enable SSLv2, so perhaps
                            breakage when you do is tolerable. RedHat could disable client-side
                            ECDH ciphers for SSL connections for which SSLv2 is enabled.

                            > * Secondly, the OpenSSL server API does not expose the client's
                            > supported EC curves to the server application which is expected
                            > to configure the EECDH curve. Thus the extension from RFC 4492
                            > is almost never used, most servers choose the EECDH curve blindly.

                            While OpenSSL does not currently allow the server's choice of curve
                            to adjust to client capabilities, it does in fact check whether
                            the server's curve is on the client's list, and if not, the OpenSSL
                            server code with disable ECDH cipher-suites.

                            The problem turns out to be that RedHat's patch did not prune the
                            list of curves advertised by the TLS client! They're going to
                            update the code to only advertise secp{256,384}r1, which will make
                            connections to gmx.de work again (but without EECDH).

                            --
                            Viktor.
                          • lists@rhsoft.net
                            ... thank you so much for that! ... understood ... understood ... sounds good and thank you again to point this out so we can expect a fixed package soon and
                            Message 13 of 16 , Oct 23 2:06 PM
                              Am 23.10.2013 22:57, schrieb Viktor Dukhovni:
                              > On Tue, Oct 22, 2013 at 06:07:49AM +0000, Viktor Dukhovni wrote:
                              >
                              > Follow-up, comments after a brief email discussion with Paul Wouters
                              > of RedHat:

                              thank you so much for that!

                              >> * Firstly, client TLS extensions are not possible when the client starts
                              >> with an SSLv2 compatible SSL HELLO. So the list of supported curves
                              >> is not sent by clients that are backwards compatible with SSLv2 (though
                              >> of course by now SSLv2 should be disabled in most clients).
                              >
                              > This is still an issue, but nobody should enable SSLv2, so perhaps
                              > breakage when you do is tolerable. RedHat could disable client-side
                              > ECDH ciphers for SSL connections for which SSLv2 is enabled.

                              understood

                              >> * Secondly, the OpenSSL server API does not expose the client's
                              >> supported EC curves to the server application which is expected
                              >> to configure the EECDH curve. Thus the extension from RFC 4492
                              >> is almost never used, most servers choose the EECDH curve blindly.
                              >
                              > While OpenSSL does not currently allow the server's choice of curve
                              > to adjust to client capabilities, it does in fact check whether
                              > the server's curve is on the client's list, and if not, the OpenSSL
                              > server code with disable ECDH cipher-suites.

                              understood

                              > The problem turns out to be that RedHat's patch did not prune the
                              > list of curves advertised by the TLS client! They're going to
                              > update the code to only advertise secp{256,384}r1, which will make
                              > connections to gmx.de work again (but without EECDH)

                              sounds good and thank you again to point this out
                              so "we" can expect a fixed package soon and disable workarounds

                              in the meantime "smtp_tls_policy_maps" works like a charme
                              sooner or later i will have the whole postfix-documentatin in my configs :-)

                              /etc/postfix/tls_policy
                              gmx.de encrypt exclude=ECDH
                              gmx.at encrypt exclude=ECDH
                              gmx.net encrypt exclude=ECDH
                              gmx.com encrypt exclude=ECDH
                            • Patrick Lists
                              On 10/23/2013 10:57 PM, Viktor Dukhovni wrote: [snip] ... Apologies if this is too OT but did Paul mention why they are ripping out curves? Regards, Patrick
                              Message 14 of 16 , Oct 24 2:11 AM
                                On 10/23/2013 10:57 PM, Viktor Dukhovni wrote:
                                [snip]
                                > The problem turns out to be that RedHat's patch did not prune the
                                > list of curves advertised by the TLS client! They're going to
                                > update the code to only advertise secp{256,384}r1, which will make
                                > connections to gmx.de work again (but without EECDH).

                                Apologies if this is too OT but did Paul mention why they are ripping
                                out curves?

                                Regards,
                                Patrick
                              • lists@rhsoft.net
                                ... if you look at the history of the 6 years standing original bugreport clearly because patent trolls and the fact Redhat is a US company
                                Message 15 of 16 , Oct 24 2:15 AM
                                  Am 24.10.2013 11:11, schrieb Patrick Lists:
                                  > On 10/23/2013 10:57 PM, Viktor Dukhovni wrote:
                                  > [snip]
                                  >> The problem turns out to be that RedHat's patch did not prune the
                                  >> list of curves advertised by the TLS client! They're going to
                                  >> update the code to only advertise secp{256,384}r1, which will make
                                  >> connections to gmx.de work again (but without EECDH).
                                  >
                                  > Apologies if this is too OT but did Paul mention why they are ripping out curves?

                                  if you look at the history of the 6 years standing original bugreport
                                  clearly because patent trolls and the fact Redhat is a US company

                                  https://bugzilla.redhat.com/show_bug.cgi?id=319901
                                  https://bugzilla.redhat.com/show_bug.cgi?id=319901#c17
                                • Patrick Lists
                                  ... Thanks you. Regards, Patrick
                                  Message 16 of 16 , Oct 24 2:18 AM
                                    On 10/24/2013 11:15 AM, lists@... wrote:
                                    >
                                    > Am 24.10.2013 11:11, schrieb Patrick Lists:
                                    >> On 10/23/2013 10:57 PM, Viktor Dukhovni wrote:
                                    >> [snip]
                                    >>> The problem turns out to be that RedHat's patch did not prune the
                                    >>> list of curves advertised by the TLS client! They're going to
                                    >>> update the code to only advertise secp{256,384}r1, which will make
                                    >>> connections to gmx.de work again (but without EECDH).
                                    >>
                                    >> Apologies if this is too OT but did Paul mention why they are ripping out curves?
                                    >
                                    > if you look at the history of the 6 years standing original bugreport
                                    > clearly because patent trolls and the fact Redhat is a US company
                                    >
                                    > https://bugzilla.redhat.com/show_bug.cgi?id=319901
                                    > https://bugzilla.redhat.com/show_bug.cgi?id=319901#c17

                                    Thanks you.

                                    Regards,
                                    Patrick
                                  Your message has been successfully submitted and would be delivered to recipients shortly.