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. Kaspar
