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.