httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dr Stephen Henson <shen...@oss-institute.org>
Subject Re: Strange error(parse tlsext bug) in mod_ssl since httpd-2.2.12
Date Tue, 27 Oct 2009 13:13:03 GMT
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

Mime
View raw message