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

Re: Problem using TLS: lost connection after STARTTLS

Expand Messages
  • Viktor Dukhovni
    ... Disable TLSv1.1 and TLSv1.2 for this destination. Use the protocols attribute in the Postfix policy table. ... My suggestion for Wietse was to include
    Message 1 of 15 , Jun 15, 2013
    • 0 Attachment
      On Sun, Jun 16, 2013 at 01:58:27AM +0200, Jan P. Kessler wrote:

      > The openssl update from 0.9.8k to 1.0.1e solved the client certificate
      > issue. Unfortunately now we see another problem with the outgoing
      > instance, trying to send to another partner with mandatory TLS:

      > mail.info] setting up TLS connection to mxtls.allianz.com[194.127.3.21]:25
      > Jun 16 00:28:54 rv-smtpext-101 postfix-OUT/smtp[28488]: [ID 197553

      Disable TLSv1.1 and TLSv1.2 for this destination. Use the protocols
      attribute in the Postfix policy table.

      > > If you're interested, I now have another option for you, a Postfix
      > > patch that will likely enable support for SHA-2 digests even when
      > > Postfix is compiled and linked with OpenSSL 0.9.8.
      >
      > May I ask if this would have a chance to be included in future postfix
      > releases? Just to know if postfix has to be patched again with updates.

      My suggestion for Wietse was to include this in 2.10.1, and any
      future updates for earlier releases. I'll also add another small
      patch to solve bitrot with the server TLS session cache that is
      triggered by OpenSSL enabling TLSv1 session tickets. (Basically,
      just add SSL_OP_NO_TICKETS to the server-side session options).

      > # postconf -c /etc/postfix/OUT smtp_tls_loglevel = 3

      Don't enable levels higher than 2 unless requested.

      > Jun 16 00:54:43 rv-smtpext-101 postfix-OUT/smtp[3022]: [ID 197553
      > mail.info] write to 000AD358 [000F6020] (363 bytes => 363 (0x16B))
      > Jun 16 00:54:43 rv-smtpext-101 postfix-OUT/smtp[3022]: [ID 197553
      > mail.info] SSL_connect:SSLv2/v3 write client hello A
      > Jun 16 00:54:43 rv-smtpext-101 postfix-OUT/smtp[3022]: [ID 197553
      > mail.info] read from 000AD358 [000E8098] (7 bytes => -1 (0xFFFFFFFF))

      Server hangs up after client SSL hello. Perhaps too many ciphers,
      or perhaps protocol compatibility issues, or something else entirely,
      but what's new with 1.0.1e is mostly more ciphers and new protocols.

      Try adding "protocols=TLSv1" to the policy entry for this site,
      and if your Postfix is sufficiently new (and knows about TLSv1.1
      and TLSv1.2) all other protocols will be disabled, and you may find
      that TLS works for you again.

      You've sure had some wicked bad luck with picking TLS partner sites. :-(

      --
      Viktor.
    • Jan P. Kessler
      ... Thanks, that worked (postfix 2.8.13): policy_table: [mxtls.allianz.com] verify protocols=SSLv3:TLSv1 # postqueue -c /etc/postfix/OUT -i
      Message 2 of 15 , Jun 16, 2013
      • 0 Attachment
        Am 16.06.2013 05:00, schrieb Viktor Dukhovni:
        > On Sun, Jun 16, 2013 at 01:58:27AM +0200, Jan P. Kessler wrote:
        >
        > > The openssl update from 0.9.8k to 1.0.1e solved the client certificate
        > > issue. Unfortunately now we see another problem with the outgoing
        > > instance, trying to send to another partner with mandatory TLS:
        >
        > > mail.info] setting up TLS connection to mxtls.allianz.com[194.127.3.21]:25
        > > Jun 16 00:28:54 rv-smtpext-101 postfix-OUT/smtp[28488]: [ID 197553
        >
        > Disable TLSv1.1 and TLSv1.2 for this destination. Use the protocols
        > attribute in the Postfix policy table.

        Thanks, that worked (postfix 2.8.13):

        policy_table:
        [mxtls.allianz.com] verify protocols=SSLv3:TLSv1

        # postqueue -c /etc/postfix/OUT -i 704A35DD5
        Jun 16 10:31:04 rv-smtpext-101 postfix-OUT/smtp[20600]: [ID 197553
        mail.info] setting up TLS connection to mxtls.allianz.com[194.127.3.22]:25
        Jun 16 10:31:05 rv-smtpext-101 postfix-OUT/smtp[20600]: [ID 197553
        mail.info] Trusted TLS connection established to
        mxtls.allianz.com[194.127.3.22]:25: TLSv1 with cipher DHE-RSA-AES256-SHA
        (256/256 bits)
        Jun 16 10:31:06 rv-smtpext-101 postfix-OUT/smtp[20600]: [ID 197553
        mail.info] 704A35DD5: to=<XXX.YYY@...>,
        relay=mxtls.allianz.com[194.127.3.22]:25, delay=98794,
        delays=98792/0/0.43/1.8, dsn=2.0.0, status=sent (250 2.0.0
        r5G8V4q9023307 Message accepted for delivery)

        > > # postconf -c /etc/postfix/OUT smtp_tls_loglevel = 3
        >
        > Don't enable levels higher than 2 unless requested.

        Yes, of course. Our normal setting is 1. Used this only for a second.

        > Try adding "protocols=TLSv1" to the policy entry for this site,
        > and if your Postfix is sufficiently new (and knows about TLSv1.1
        > and TLSv1.2) all other protocols will be disabled, and you may find
        > that TLS works for you again.
        >
        > You've sure had some wicked bad luck with picking TLS partner sites. :-(

        Yep, that's what I thought, too ;)

        Currently I fear, that other partners might be also affected about this.
        Now the queues are almost empty but most traffic with other mandatory
        TLS partner sites will start to continue during work hours Mo-Fr and
        I'll be out of office for a week. What do you think about deactivating
        v1.1 and v1.2 globally?

        Currently:
        smtp_tls_mandatory_protocols = !SSLv2
        smtp_tls_protocols = !SSLv2

        Suggestion:
        smtp_tls_mandatory_protocols = !SSLv2 !TLSv1.1 !TLSv1.2
        smtp_tls_protocols = !SSLv2

        Will this work or are we expected to run into other compatibility issues
        with that from your experience?

        P.S.: On one machine I tried to switch to a shared openssl 1.0.1e build
        which also seems to work fine:

        # ldd /opt/vrnetze/postfix/libexec/smtpd|grep -i ssl
        libssl.so.1.0.0 => /opt/vrnetze/openssl/lib/libssl.so.1.0.0
        libcrypto.so.1.0.0 => /opt/vrnetze/openssl/lib/libcrypto.so.1.0.0

        Am I right concluding that this won't require a postfix rebuild on new
        openssl 1.0.x versions?

        Again, thank you very much for your time and thoughts!
      • /dev/rob0
        Beside the point, yet possibly of interest: ... snip ... Excerpt from s_client(1) manual: CONNECTED COMMANDS If a connection is established with an SSL
        Message 3 of 15 , Jun 16, 2013
        • 0 Attachment
          Beside the point, yet possibly of interest:

          On Sun, Jun 16, 2013 at 03:07:01AM +0200, Jan P. Kessler wrote:
          > # /opt/vrnetze/openssl/bin/openssl s_client -connect
          > mxtls.allianz.com:25 -starttls smtp
          > CONNECTED(00000004)
          snip
          > ---
          > 250 HELP
          > HELO mail.EXAMPLE.COM
          > 250 mailgw.allianz.de Hello mail.EXAMPLE.COM [91.235.236.8],
          > pleased to meet you
          > MAIL FROM:jpk@...
          > 250 2.1.0 jpk@...... Sender ok
          > RCPT TO:XXX.YYY@...
          > RENEGOTIATING
          > [CTRL+C]

          Excerpt from s_client(1) manual:

          "
          CONNECTED COMMANDS
          If a connection is established with an SSL server then any data
          received from the server is displayed and any key presses will be
          sent to the server. When used interactively (which means neither
          -quiet nor -ign_eof have been given), the session will be
          renegotiated if the line begins with an R, and if the line begins
          with a Q or if end of file is reached, the connection will be closed
          down.
          "

          Your workaround is to use lowercase "r" in your RCPT TO command:

          rcpt to:<XXX.YYY@...>
          rCPT TO:<XXX.YYY@...>
          --
          http://rob0.nodns4.us/ -- system administration and consulting
          Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
        • Viktor Dukhovni
          ... With the destination domain in [], or when match=... is explicitly specified, the verify and secure levels are identical, otherwise I would probably
          Message 4 of 15 , Jun 18, 2013
          • 0 Attachment
            On Sun, Jun 16, 2013 at 11:13:05AM +0200, Jan P. Kessler wrote:

            > > Disable TLSv1.1 and TLSv1.2 for this destination. Use the protocols
            > > attribute in the Postfix policy table.
            >
            > Thanks, that worked (postfix 2.8.13):
            >
            > policy_table:
            > [mxtls.allianz.com] verify protocols=SSLv3:TLSv1

            With the destination domain in [], or when "match=..." is explicitly
            specified, the "verify" and "secure" levels are identical, otherwise
            I would probably shun "verify" and use "secure" with explicit "match"
            clauses as required.

            > Currently I fear, that other partners might be also affected about this.
            > Now the queues are almost empty but most traffic with other mandatory
            > TLS partner sites will start to continue during work hours Mo-Fr and
            > I'll be out of office for a week. What do you think about deactivating
            > v1.1 and v1.2 globally?

            Unlikely to cause any harm, and may help with some destinations.
            You lose support for AEAD modes which protect against "CRIME" and
            "BEAST", but those attacks are browser-specific.

            > smtp_tls_mandatory_protocols = !SSLv2
            > smtp_tls_protocols = !SSLv2
            >
            > Suggestion:
            > smtp_tls_mandatory_protocols = !SSLv2 !TLSv1.1 !TLSv1.2
            > smtp_tls_protocols = !SSLv2

            You can set both the same for now. Ideally there'll be some pressure
            on sites with broken TLSv1.2 (TLSv1.1 is a far more modest change)
            to get their implementations upgraded. But if you have critical
            traffic, it may be reasonable to be conservative in what you send...

            > Will this work or are we expected to run into other compatibility issues
            > with that from your experience?

            TLSv1 is tried and true and largely sufficient, it is a very safe choice.

            > P.S.: On one machine I tried to switch to a shared openssl 1.0.1e build
            > which also seems to work fine:
            >
            > # ldd /opt/vrnetze/postfix/libexec/smtpd|grep -i ssl
            > libssl.so.1.0.0 => /opt/vrnetze/openssl/lib/libssl.so.1.0.0
            > libcrypto.so.1.0.0 => /opt/vrnetze/openssl/lib/libcrypto.so.1.0.0
            >
            > Am I right concluding that this won't require a postfix rebuild on new
            > openssl 1.0.x versions?

            I can't speak for the stability of the OpenSSL ABI. It is *supposed*
            to work, whether it will, only time will tell. Many other users will
            rely on this stability on systems where 1.0.0 or 1.0.1 is the default
            OpenSSL library:

            $ openssl version
            OpenSSL 1.0.1e 11 Feb 2013

            $ ldd $(type -p openssl) |
            grep /usr/lib |
            awk '{printf "%-20s %s\n", $1,$3}'
            libssl.so.1.0.0 /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0
            libcrypto.so.1.0.0 /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0

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