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

Re: TLS errors with GMX/web.de

Expand Messages
  • Viktor Dukhovni
    ... The client sends an internal error alert. It is not clear what problem it is encountering. The server elects: Cipher Suite:
    Message 1 of 11 , Aug 23, 2013
      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 2 of 11 , Aug 26, 2013
        * 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 3 of 11 , Aug 26, 2013
          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.