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

Re: TLS errors with GMX/web.de

Expand Messages
  • 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 1 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 2 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 3 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 4 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.