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

Re: TLS errors with GMX/web.de

Expand Messages
  • Heiko Wundram
    ... Hash: SHA1 ... Official certificate by StartSSL on this host, but I m also getting inbound mail from web.de without problems on other systems that have
    Message 1 of 11 , Aug 20, 2013
    • 0 Attachment
      -----BEGIN PGP SIGNED MESSAGE-----
      Hash: SHA1

      Am 20.08.2013 12:12, schrieb Sebastian Wiesinger:
      > * Heiko Wundram <modelnine@...> [2013-08-20 12:09]:
      >> Still delivers fine for me (and my mail-server) running Postfix
      >> 2.10.1:
      >>
      >> Received: from mout.web.de (mout.web.de [212.227.15.3]) (using
      >> TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No
      >> client certificate requested) by mail.modelnine.org (Postfix)
      >> with ESMTPS id 8854E3640A for <modelnine@...>; Tue, 20
      >> Aug 2013 08:35:39 +0200 (CEST)
      >
      > what kind of certificate do you have? Official, selfsigned? I have
      > one from CACert and I wonder if that is the problem...

      Official certificate by StartSSL on this host, but I'm also getting
      inbound mail from web.de without problems on other systems that have
      self-singled certificates and do offer STARTTLS.

      I'd rather take a guess that your SSL library doesn't advertise a
      cipher spec that's accepted by the web.de servers (although I wouldn't
      know about restrictions they impose) - you might also simply want to
      try and test whether openssl s_client has anything to say about your
      exposed configuration.

      Anyway, testing mx.karotte.org from mail.modelnine.org seems to show
      that the connection should work in principle (I'm getting the same
      results as to SSL session negotiation as when I'm connecting to my MX):

      New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
      Server public key is 1024 bit
      Secure Renegotiation IS supported
      Compression: zlib compression
      Expansion: zlib compression
      SSL-Session:
      Protocol : TLSv1.2
      Cipher : ECDHE-RSA-AES256-GCM-SHA384

      except for the fact that my key is 2048 bits, and yours is 1024 bits.

      - --
      - --- Heiko.
      -----BEGIN PGP SIGNATURE-----
      Version: GnuPG v2.0.20 (MingW32)
      Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

      iQEcBAEBAgAGBQJSE0PuAAoJEDMqpHf921/SoWoIAJo5Vz2AJv7d2NJr4C6g88se
      8Y/ItWFynoYmWuHmYgKYgmtHnLW7WQFq08k0TDrL1SsNJvc2al0T3cNvqEUTnENZ
      UoTsye0rfg6Zp9TIdj85DmmyBkKjKtMBgaEu+aeXB29CR6g5P1FcWIpNbpu1U+Cg
      f0pngeVVWGpMZdiCC0cctbROllarFaMQBtX9Cuxw74m92mRkMArDzErsFtB/dc6Z
      TSJtbb2BmH0uCduAGcBzrzMHHcP6eULIZgubp6gxGSNddlT+jEMPDTj/N2PPj7pi
      gcWk/Eh5eU/QcyeE7Q2kaZmVf5C7AZ70xD2nPFyDU80XUstKTCYXZM9ylFWMQTE=
      =PZ2s
      -----END PGP SIGNATURE-----
    • DTNX Postmaster
      ... Same Postfix, same Debian, from yesterday afternoon; == postfix/smtpd[25199]: connect from mout.web.de[212.227.15.14] postfix/smtpd[25199]: Anonymous TLS
      Message 2 of 11 , Aug 20, 2013
      • 0 Attachment
        On Aug 20, 2013, at 11:48, Sebastian Wiesinger <postfix-users@...> wrote:

        > GMX and web.de started an initiative for secure E-Mail made in
        > Germany... they turned TLS on.
        >
        > But in addition to that bold move the did something else that causes
        > the following errors when they try to send mail to my postfix:
        >
        > postfix/smtpd[28706]: connect from mout.web.de[212.227.15.14]
        > postfix/smtpd[28706]: SSL_accept error from mout.web.de[212.227.15.14]: 0
        > postfix/smtpd[28706]: warning: TLS library problem: 28706:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1256:SSL alert number 80:
        > postfix/smtpd[28706]: lost connection after STARTTLS from mout.web.de[212.227.15.14]
        > postfix/smtpd[28706]: disconnect from mout.web.de[212.227.15.14]
        >
        > Postfix 2.9.6 running on Debian 7.1.
        >
        > This error ONLY occurs with their servers. My question is if anyone
        > has an idea what could cause this error. My first guess is that they
        > check certificates for validity and I only have an CACert certificate.
        > Also I would like to know if anyone else sees this on their postfix?
        >
        > Currently I've disabled STARTTLS for their mailservers but of course I
        > would like to use TLS if possible. Would increasing the tls log level
        > reveal additional helpful information?

        Same Postfix, same Debian, from yesterday afternoon;

        ==
        postfix/smtpd[25199]: connect from mout.web.de[212.227.15.14]
        postfix/smtpd[25199]: Anonymous TLS connection established from mout.web.de[212.227.15.14]: TLSv1.2 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)
        postfix/smtpd[25199]: 3cJRKD6cRCz5G: client=mout.web.de[212.227.15.14]
        postfix/smtpd[25199]: disconnect from mout.web.de[212.227.15.14]
        ==

        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;

        smtpd_tls_loglevel = 1
        smtpd_tls_security_level = may

        HTH,
        Joni
      • 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 3 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 4 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 5 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 6 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 7 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 8 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.