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

Re: "bad digest length:s3_both.c:239:" when sending to mail.vex.net?

Expand Messages
  • Viktor Dukhovni
    ... No, all client versions I tried, ranging from 0.9.8j through 1.0.1e exhibit the issue. All evidence so far points to a server bug. The system that
    Message 1 of 37 , May 9, 2013
    • 0 Attachment
      On Thu, May 09, 2013 at 02:03:38PM -0400, D'Arcy J.M. Cain wrote:

      > On Thu, 9 May 2013 19:42:16 +0200
      >
      > > > > > When sending several mails in succession, failure and success
      > > > > > seem to alternate (i.e. exactly one failed handshake, then a
      > > > > > successful one, then a failed one again, etc.). And not using
      > > > > > a TLS session cache for smtp(8)
      > > > > > (smtp_tls_session_cache_database) seems to work around the
      > > > > > problem.
      >
      > Odd. No one else has mentioned this issue. Could it be a combination
      > of versions between the client and server?

      No, all client versions I tried, ranging from 0.9.8j through 1.0.1e
      exhibit the issue. All evidence so far points to a server bug.
      The system that exhibits the bug consistently is also running NetBSD 5.1.

      NetBSD often has two versions of OpenSSL installed, one as part of
      the base system in /usr/bin, and another from pkgsrc in /usr/pkg/bin.

      > > > > Looks like at least two servers behind a loadbalancer?
      > > >
      > > > No. A signle server with OpenSSL library bugs (broken support for
      > > > TLSv1 session tickets).
      >
      > Definitely a single server. The openssl version is 1.0.1e. That's the
      > latest version issued three months ago.

      Are you sure that Postfix is using the 1.0.1e OpenSSL from pkgsrc?
      Are you running the pkgsrc Postfix or the base system Postfix.
      The latter is almost certainly linked to an older OpenSSL shipped
      in the base system image.

      > > > Back your original problem, do you know anyone who can report what
      > > > software is running at mail.vex.net? Is this also a NetBSD
      > > > 0.9.9-dev snapshot?
      >
      > NetBSD 5.1 stable release.

      My strong suspicion is that this is NOT 1.0.1e, at least not for
      Postfix. Please take a look at the other messages in this thread.

      --
      Viktor.
    • Viktor Dukhovni
      ... Yes it is better now, though it took many tries to get a cached session, since session ticket support in OpenSSL 1.0 makes the Postfix SMTP server session
      Message 37 of 37 , Jul 7, 2013
      • 0 Attachment
        On Sun, Jul 07, 2013 at 08:02:53PM -0400, D'Arcy J.M. Cain wrote:

        > > > > > > > When sending several mails in succession, failure and
        > > > > > > > success seem to alternate (i.e. exactly one failed
        > > > > > > > handshake, then a successful one, then a failed one again,
        > > > > > > > etc.). And not using a TLS session cache for smtp(8)
        > > > > > > > (smtp_tls_session_cache_database) seems to work around the
        > > > > > > > problem.
        > > >
        > > > Odd. No one else has mentioned this issue. Could it be a
        > > > combination of versions between the client and server?
        > >
        > > No, all client versions I tried, ranging from 0.9.8j through 1.0.1e
        > > exhibit the issue. All evidence so far points to a server bug.
        > > The system that exhibits the bug consistently is also running NetBSD
        > > 5.1.
        >
        > I have just upgraded all of my systems. Postfix and SSL are now both
        > in the base system. Can you test it again please.

        Yes it is better now, though it took many tries to get a cached
        session, since session ticket support in OpenSSL 1.0 makes the
        Postfix SMTP server session cache mostly ineffective. This will
        be fixed in Postfix 2.11 and 2.10.2 (Wietse has patches for both
        in his queue):

        [ Most SMTP servers don't have high enough traffic loads to be
        overly concerned about lack of TLS session caching, so don't worry
        about that, but you can upgrade when 2.10.2 comes out ]

        $ posttls-finger -c -Lsummary,cache,debug -r 1 "[mail.vex.net]:25"
        posttls-finger: initializing the client-side TLS engine
        posttls-finger: Connected to mail.vex.net[98.158.139.68]:25
        posttls-finger: setting up TLS connection to mail.vex.net[98.158.139.68]:25
        posttls-finger: mail.vex.net[98.158.139.68]:25: TLS cipher list "aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH:!aNULL"
        posttls-finger: looking for session [98.158.139.68]:25&4DFC02A9282C7A786072E811D659A26A14B1127FA5522B7475BFC43B2DB05765 in memory cache
        posttls-finger: SSL_connect:before/connect initialization
        posttls-finger: SSL_connect:SSLv2/v3 write client hello A
        posttls-finger: SSL_connect:SSLv3 read server hello A
        posttls-finger: mail.vex.net[98.158.139.68]:25: depth=1 verify=0 subject=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO SSL CA
        posttls-finger: mail.vex.net[98.158.139.68]:25: depth=1 verify=0 subject=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO SSL CA
        posttls-finger: mail.vex.net[98.158.139.68]:25: depth=0 verify=1 subject=/OU=Domain Control Validated/OU=Hosted by Tucows/OU=COMODO SSL Wildcard/CN=*.vex.net
        posttls-finger: SSL_connect:SSLv3 read server certificate A
        posttls-finger: SSL_connect:SSLv3 read server key exchange A
        posttls-finger: SSL_connect:SSLv3 read server done A
        posttls-finger: SSL_connect:SSLv3 write client key exchange A
        posttls-finger: SSL_connect:SSLv3 write change cipher spec A
        posttls-finger: SSL_connect:SSLv3 write finished A
        posttls-finger: SSL_connect:SSLv3 flush data
        posttls-finger: SSL_connect:SSLv3 read server session ticket A
        posttls-finger: SSL_connect:SSLv3 read finished A
        posttls-finger: save session [98.158.139.68]:25&4DFC02A9282C7A786072E811D659A26A14B1127FA5522B7475BFC43B2DB05765 to memory cache
        posttls-finger: certificate verification failed for mail.vex.net[98.158.139.68]:25: untrusted issuer /C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
        posttls-finger: mail.vex.net[98.158.139.68]:25: subject_CN=*.vex.net, issuer_CN=COMODO SSL CA, fingerprint=D7:7B:08:13:41:F8:B8:B1:CA:DC:A8:5D:56:98:69:25:0A:FD:B4:86, pkey_fingerprint=AD:60:1D:5E:A9:65:65:84:D1:2C:44:29:74:29:2E:F7:B6:BD:C2:BC
        posttls-finger: Untrusted TLS connection established to mail.vex.net[98.158.139.68]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
        posttls-finger: Reconnecting after 1 seconds
        posttls-finger: looking for session [98.158.139.68]:25&4DFC02A9282C7A786072E811D659A26A14B1127FA5522B7475BFC43B2DB05765 in memory cache
        posttls-finger: reloaded session [98.158.139.68]:25&4DFC02A9282C7A786072E811D659A26A14B1127FA5522B7475BFC43B2DB05765 from memory cache
        posttls-finger: SSL_connect:before/connect initialization
        posttls-finger: SSL_connect:SSLv3 write client hello A
        posttls-finger: SSL_connect:SSLv3 read server hello A
        posttls-finger: SSL_connect:SSLv3 read finished A
        posttls-finger: SSL_connect:SSLv3 write change cipher spec A
        posttls-finger: SSL_connect:SSLv3 write finished A
        posttls-finger: SSL_connect:SSLv3 flush data
        posttls-finger: mail.vex.net[98.158.139.68]:25: Reusing old session
        posttls-finger: mail.vex.net[98.158.139.68]:25: re-using session with untrusted certificate, look for details earlier in the log
        posttls-finger: Untrusted TLS connection established to mail.vex.net[98.158.139.68]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

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