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

Re: TLS errors with GMX/web.de

Expand Messages
  • Sebastian Wiesinger
    ... I found the problem... In addition to my normal certificate, I had an EC certificate. smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt As
    Message 1 of 11 , Aug 20, 2013
    • 0 Attachment
      * DTNX Postmaster <postmaster@...> [2013-08-20 12:57]:
      > Self-signed, 2048 bits certificate from our own root. Picks the same cipher and TLS version as in Heiko's example, it seems. Perhaps it's your certificate, perhaps your Postfix settings? No odd overrides for the defaults anywhere, forced cipher suites or anything?
      >
      > Aside from the certificate and key, these are our only non-default settings;

      I found the problem... In addition to my normal certificate, I had an
      EC certificate.

      smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt

      As soon as I removed that line it started working...

      Noone else had a problem with that certificate. For completeness here
      is the cert output:

      Certificate:
      Data:
      Version: 3 (0x2)
      Serial Number: 133035 (0x207ab)
      Signature Algorithm: sha1WithRSAEncryption
      Issuer: O=CAcert Inc., OU=http://www.CAcert.org, CN=CAcert Class 3 Root
      Validity
      Not Before: Aug 13 11:39:24 2013 GMT
      Not After : Aug 13 11:39:24 2015 GMT
      Subject: CN=*.karotte.org
      Subject Public Key Info:
      Public Key Algorithm: id-ecPublicKey
      Public-Key: (384 bit)
      pub:
      04:6d:69:d6:06:1f:7c:b2:8d:2b:6b:a5:0e:d9:8f:
      c9:6c:cf:ad:32:3d:35:3b:82:a6:58:ea:38:66:ae:
      3d:43:ac:b0:cd:41:28:c6:7a:f7:3f:da:cf:50:be:
      93:a5:90:30:cb:98:9c:b7:a1:07:93:39:bf:32:7f:
      01:9c:59:04:8a:7d:fc:72:e9:78:a9:e5:22:e7:22:
      5d:b5:80:bf:77:e1:be:65:3d:ce:10:c4:f3:5c:52:
      73:aa:80:56:81:02:29
      ASN1 OID: secp384r1
      X509v3 extensions:
      X509v3 Basic Constraints: critical
      CA:FALSE
      X509v3 Key Usage: critical
      Digital Signature, Key Encipherment, Key Agreement
      X509v3 Extended Key Usage:
      TLS Web Client Authentication, TLS Web Server Authentication, Netscape Server Gated Crypto, Microsoft Server Gated Crypto
      Authority Information Access:
      OCSP - URI:http://ocsp.cacert.org/

      X509v3 CRL Distribution Points:

      Full Name:
      URI:http://crl.cacert.org/class3-revoke.crl

      X509v3 Subject Alternative Name:
      DNS:*.karotte.org, othername:<unsupported>, DNS:karotte.org, othername:<unsupported>
      Signature Algorithm: sha1WithRSAEncryption
      04:ca:17:b7:09:b5:00:e0:9f:ac:9b:25:9f:4b:78:d9:fb:a5:
      ...

      Regards

      Sebastian

      --
      GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
      'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
      -- Terry Pratchett, The Fifth Elephant
    • Viktor Dukhovni
      ... Though I think OpenSSL will generally detect attempts to configure a public key (certificate) without a matching private key, you should check that the
      Message 2 of 11 , Aug 20, 2013
      • 0 Attachment
        On Tue, Aug 20, 2013 at 01:27:01PM +0200, Sebastian Wiesinger wrote:

        > I found the problem... In addition to my normal certificate, I had an
        > EC certificate.
        >
        > smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt

        Though I think OpenSSL will generally detect attempts to configure
        a public key (certificate) without a matching private key, you
        should check that the private key and certificate match:

        (
        # Adjust as necessary
        certfile=/etc/postfix/certs/cacert-karotte-ec.crt # cert
        pkeyfile=/etc/postfix/certs/cacert-karotte-ec.crt # private key

        # Digest of public key from certificate:
        openssl x509 -in ${certfile} -noout -pubkey |
        openssl pkey -pubin -outform DER |
        openssl dgst -sha1 -c

        # Digest of public key from private key:
        openssl pkey -in ${pkeyfile} -pubout -outform DER |
        openssl dgst -sha1 -c
        ) | uniq -c

        This should output a single digest with a count of "2".

        > As soon as I removed that line it started working...

        If you're willing to test briefly with the EC certificate re-enabled,
        it would be helpful to capture a full packet capture tcpdump (aka
        pcap) file with a failed delivery from gmx.de/web.de. Viewing this
        with "wireshark" will show exactly where in the handshake the problem
        ocurred and may shed some light on the reason.

        After capturing all traffic from the source in question for a period of
        time that includes at least one complete failed session, extract just that
        session from the capture file by identifying the TCP source port of such a
        session and running:

        client_source_port=58459 # example adjust to match reality
        tcpdump -s0 -r /tmp/full-capture.pcap -w /tmp/session-capture.pcap \
        tcp port $client_source_port

        The resulting output file should contain just a single TCP session with
        three way handshake (SYN, SYN-ACK, ACK) and three-way shutdown
        (FIN, FIN, ACK or in some cases either FIN or final ACK may be an RST).

        Please post a URL to the binary PCAP file.

        > Certificate:
        > Subject Public Key Info:
        > Public Key Algorithm: id-ecPublicKey
        > Public-Key: (384 bit)
        > pub:
        > 04:6d:69:d6:06:1f:7c:b2:8d:2b:6b:a5:0e:d9:8f:
        > c9:6c:cf:ad:32:3d:35:3b:82:a6:58:ea:38:66:ae:
        > 3d:43:ac:b0:cd:41:28:c6:7a:f7:3f:da:cf:50:be:
        > 93:a5:90:30:cb:98:9c:b7:a1:07:93:39:bf:32:7f:
        > 01:9c:59:04:8a:7d:fc:72:e9:78:a9:e5:22:e7:22:
        > 5d:b5:80:bf:77:e1:be:65:3d:ce:10:c4:f3:5c:52:
        > 73:aa:80:56:81:02:29
        > ASN1 OID: secp384r1

        There are no known practical attacks on 256-bit EC keys and 384-bit
        EC is slower. AES-128 with EC-256 is sufficiently secure for SMTP
        TLS. Though I expect that if the sender has trouble with 384-bit
        EC, they'll have trouble with EC in general.

        --
        Viktor.
      • Sebastian Wiesinger
        ... Hi, yes I checked and they are matching. ... I just did, here is the PCAP: http://www.karotte.org/smtp-gmx.pcap ... I found no real guidance in regards to
        Message 3 of 11 , Aug 21, 2013
        • 0 Attachment
          * Viktor Dukhovni <postfix-users@...> [2013-08-20 16:51]:
          > > I found the problem... In addition to my normal certificate, I had an
          > > EC certificate.
          > >
          > > smtpd_tls_eccert_file=/etc/postfix/certs/cacert-karotte-ec.crt
          >
          > Though I think OpenSSL will generally detect attempts to configure
          > a public key (certificate) without a matching private key, you
          > should check that the private key and certificate match:

          Hi,

          yes I checked and they are matching.

          > If you're willing to test briefly with the EC certificate re-enabled,
          > it would be helpful to capture a full packet capture tcpdump (aka
          > pcap) file with a failed delivery from gmx.de/web.de. Viewing this
          > with "wireshark" will show exactly where in the handshake the problem
          > ocurred and may shed some light on the reason.

          I just did, here is the PCAP:

          http://www.karotte.org/smtp-gmx.pcap

          > There are no known practical attacks on 256-bit EC keys and 384-bit
          > EC is slower. AES-128 with EC-256 is sufficiently secure for SMTP
          > TLS. Though I expect that if the sender has trouble with 384-bit
          > EC, they'll have trouble with EC in general.

          I found no real guidance in regards to EC so I chose a higher one.

          Regards

          Sebastian

          --
          GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
          'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
          -- Terry Pratchett, The Fifth Elephant
        • Viktor Dukhovni
          ... The client sends an internal error alert. It is not clear what problem it is encountering. The server elects: Cipher Suite:
          Message 4 of 11 , Aug 23, 2013
          • 0 Attachment
            On Wed, Aug 21, 2013 at 10:44:40PM +0200, Sebastian Wiesinger wrote:

            > I just did, here is the PCAP:
            >
            > http://www.karotte.org/smtp-gmx.pcap

            The client sends an "internal error" alert. It is not clear what
            problem it is encountering. The server elects:

            Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)

            and the client purports to support the curve in the server certificate.
            I don't have the expertise to try to debug the server's key exchange
            message, but it it is typically secp256r1 aka prime256v1, which the
            client purports to support.

            > > There are no known practical attacks on 256-bit EC keys and 384-bit
            > > EC is slower. AES-128 with EC-256 is sufficiently secure for SMTP
            > > TLS. Though I expect that if the sender has trouble with 384-bit
            > > EC, they'll have trouble with EC in general.
            >
            > I found no real guidance in regards to EC so I chose a higher one.

            It may be overkill, but it should work. I am afraid the best path
            forward is for GMX to debug this with their client software.

            --
            Viktor.
          • Sebastian Wiesinger
            ... Yeah I m not holding my breath for that. Is there a way to exclude the web.de/GMX mailservers from the EC certificate? Let postfix always use the other
            Message 5 of 11 , Aug 26, 2013
            • 0 Attachment
              * Viktor Dukhovni <postfix-users@...> [2013-08-24 05:27]:
              >
              > > I just did, here is the PCAP:
              > >
              > > http://www.karotte.org/smtp-gmx.pcap
              >
              > The client sends an "internal error" alert. It is not clear what
              > problem it is encountering. The server elects:
              >
              > Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
              >
              > and the client purports to support the curve in the server certificate.
              > I don't have the expertise to try to debug the server's key exchange
              > message, but it it is typically secp256r1 aka prime256v1, which the
              > client purports to support.
              >
              > It may be overkill, but it should work. I am afraid the best path
              > forward is for GMX to debug this with their client software.

              Yeah I'm not holding my breath for that. Is there a way to exclude the
              web.de/GMX mailservers from the EC certificate? Let postfix always
              use the other certificate for them?

              Regards

              Sebastian

              --
              GPG Key: 0x93A0B9CE (F4F6 B1A3 866B 26E9 450A 9D82 58A2 D94A 93A0 B9CE)
              'Are you Death?' ... IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
              -- Terry Pratchett, The Fifth Elephant
            • Viktor Dukhovni
              ... Send them (postmaster@) a pointer to this thread, over time they ll have similar problems with more sites. ... Only by redirecting their connections to a
              Message 6 of 11 , Aug 26, 2013
              • 0 Attachment
                On Mon, Aug 26, 2013 at 12:04:28PM +0200, Sebastian Wiesinger wrote:

                > > It may be overkill, but it should work. I am afraid the best path
                > > forward is for GMX to debug this with their client software.
                >
                > Yeah I'm not holding my breath for that.

                Send them (postmaster@) a pointer to this thread, over time they'll
                have similar problems with more sites.

                > Is there a way to exclude the
                > web.de/GMX mailservers from the EC certificate? Let postfix always
                > use the other certificate for them?

                Only by redirecting their connections to a different port via NAT.
                The Postfix SMTP server has very minimal client-specific TLS policy:

                - You can disable STARTTLS support for a set of clients.

                smtpd_discard_ehlo_keyword_address_maps

                - You can do access control based on client certificates

                smtpd_tls_ask_ccert
                permit_tls_clientcerts
                check_ccert_access

                One of the main problems is that while the client knows who the
                server is (it chose to connect there), the server has little idea
                who the client is (IP address ranges change over time).

                Policies intended to improve interoperability with legitimate clients
                (that don't lie about their identity) could in principle do lookups
                based on the client EHLO name. Postfix does not yet have such features.

                --
                Viktor.
              Your message has been successfully submitted and would be delivered to recipients shortly.