Dr Stephen Henson wrote: > 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. >
That is most peculiar. The server is sending back a zero length session ID in the server hello which it shouldn't be doing if tickets are disabled. Is the server somehow using an older version of OpenSSL? There has been a bug in the past which might do that but it was fixed well before 0.9.8k. Steve. -- Dr Stephen N. Henson. Senior Technical/Cryptography Advisor, Open Source Software Institute: www.oss-institute.org OpenSSL Core team: www.openssl.org
