On Wed, May 08, 2013 at 07:19:36PM +0000, Viktor Dukhovni wrote:
> On Wed, May 08, 2013 at 06:01:52PM +0000, Viktor Dukhovni wrote:
>
> > posttls-finger: Untrusted TLS connection established to
> > rho.salmi.ch[178.63.9.175]:587: TLSv1 with cipher DHE-RSA-AES256-SHA
> > (256/256 bits)
> > posttls-finger: Reconnecting after 1 seconds
> > posttls-finger: < 220 rho.salmi.ch ESMTP
> > posttls-finger: reloaded session
> > posttls-finger:[178.63.9.175]:587:5047F1BB983E07DEFDB7D1A973BC5FFD00A6C9735C2BB76A405107195320BB07
> > from memory cache
> > posttls-finger: SSL_connect error to rho.salmi.ch[178.63.9.175]:587: 0
> > posttls-finger: warning: TLS library problem: 21961:error:1408C06F:SSL
> > routines:SSL3_GET_FINISHED:bad digest length:s3_both.c:264:
> > posttls-finger: remove session
> > posttls-finger:[178.63.9.175]:587:5047F1BB983E07DEFDB7D1A973BC5FFD00A6C9735C2BB76A405107195320BB07
> > from client cache
> >
> > Indeed handshakes fail for resumed sessions. What version of
> > Postfix and OpenSSL is installed on rho.salmi.ch?
>
> When I try a server running Postfix (2.11-20130506-nonprod) and
> OpenSSL 1.0.1e session resumption works. This appears to be a
> server-side bug with resumed sessions. I'll take a look at wireshark
> analysis later.
What we see is that the encrypted server "finished" message is 32
bytes instead of the expected 48 (AES256-SHA). Normally we have:
"0x14 0x00 0x00 0x0c" + [(type 20, length 12)]
12 bytes finished +
20 bytes SHA = 36 bytes +
AES padding = 48.
The encrypted finished message from rho.salmi.ch is 32 bytes, with gdb we see
that the first four bytes decrypt to:
"0x14 0x00 0x00 0x00" + [(type 20, length 0)]
0 bytes finished +
20 bytes SHA = 24 bytes +
AES padding = 32.
So this server generated an empty SSL "finished" message. Can't
say why, but this is definitely not right, and appears to be
something special about this server.
While the problem Ralf reported looks similar, tests against the
server he reported fail to discover any support for session reuse,
so either one has to be very lucky to re-use a session (possible
with forking servers without a shared cache) or Ralf ran into a
slightly different problem.
Further progress depends on detailed information about the software
on rho.salmi.ch.
There's not much we can do on the Postfix client side. One could
imagine some sort of negative caching in tlsmgr, where a handshake
failures a resumed session writes a "do not cache" entry into the
tlsmgr cache, with the same TTL as positive entries (1 hour seems
popular). This way, you get 1 failed handshake per-hour instead
of 50% failure.
This would be a complex feature, and I'm not sure it is worth the
trouble unless the problem is widespread.
--
Viktor.
