On Thu, May 09, 2013 at 05:58:14PM +0200, Dr. Stephen Henson wrote:
> > However disabling TLS extensions in the client does. With "no-tlsext",
> > the server does not resume past sessions. Perhaps the server's
> > implementation of session tickets is the culprit. Has anyone else
> > observed such servers in the wild?
> >
>
> Try it with -no_ticket
Yes, that works, as does using SSLv3. With SMTP however, one cannot
reasonably keep track of which destinations need a particular
work-around unless they are very few in number. Otherwise, one is
forced to apply the work-around globally, and I am reluctant to
disable session tickets for all mail deliveries. (Stable Postfix
releases don't yet have the means to do this).
So I'm more interested in any leads about which servers are prone
to this misbehaviour. Did any past OpenSSL versions mishandle
session tickets and acccept the session only to then fail to
negotiate correctly (zero length finished)?
It seems likely that the servers are running some OpenSSL version
or other, but so far I only have directl access to the client, not
the server.
Is there anything in past versions of OpenSSL that would have
trouble with session tickets? Maybe a poor interaction between
tickets and an external session cache? (Postfix uses the session
callbacks to save and restore sessions from an on-disk shared
database). I've tried a bunch of different OpenSSL versions, and
can't reproduce the issue with any server I compile. (I am not
fool enough to break this foolproof system).
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
