Kaspar Brand wrote: > Kamesh Jayachandran, >> [Mon Oct 26 15:48:22 2009] [warn] [client 10.2.0.88] >> ssl_init_ssl_connection: options=0x1114fff >> </snip> >> >> The tcpdump for this failure is at, >> >> http://www.livecipher.com/tlsext_dump/tlsext.dmp.4 > > Thanks - this shows that session tickets are indeed disabled on the > server side (0x...4fff means SSL_OP_ALL | SSL_OP_NO_TICKET), and from > the packet dump it can be seen that the server does not send any session > ticket extensions in its ServerHellos. > > With the client, the difference to the case where tickets are enabled is > the fact that for the third connection, it includes an empty session > ticket extension in the ClientHello (indicating that a NewSessionTicket > message would be accepted). The server then again replies with a > ServerHello with a server_name extension - which is immediately rejected > by the client with SSL_AD_DECODE_ERROR. I therefore assume that it still > ends up in the "if (!s->hit && tlsext_servername == 1)" code block, > irrespective of whether the server uses SSL_OP_NO_TICKET or not. >
That's very strange. It seems like that shouldn't happen because a stateful session resumption should occur and s->hit == 1. Will analyse it more when I have access to my main test setup later today. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
