Kaspar Brand wrote:
>
> As Joe observed in an earlier message, there are only two places in
> t1_lib.c:ssl_parse_serverhello_tlsext() which set SSL_AD_DECODE_ERROR,
> and it seems very likely that the following code is hit:
>
>> if (!s->hit && tlsext_servername == 1)
>> {
>> if (s->tlsext_hostname)
>> {
>> if (s->session->tlsext_hostname == NULL)
>> {
>> s->session->tlsext_hostname =
>> BUF_strdup(s->tlsext_hostname);
>> if (!s->session->tlsext_hostname)
>> {
>> *al = SSL_AD_UNRECOGNIZED_NAME;
>> return 0;
>> }
>> }
>> else
>> {
>> *al = SSL_AD_DECODE_ERROR;
>> return 0;
>> }
>> }
>> }
>
> I'll defer to the OpenSSL gurus for further analysis, but apparently
> it has to do with the fact that the client reuses an SSL session
> (s->session->tlsext_hostname is non-null), but this case is not
> expected by ssl_parse_serverhello_tlsext(). It would also explain,
> however, why the issue does not show up immediately, but only after
> a couple of minutes (i.e., when a session is really being reused).
>
OK that makes sense. I can now reproduce this with OpenSSL s_server and
s_client and stateless session resumption. A fix for this would have to be in
the client code, I'll look into that.
It doesn't occur when tickets are disabled so setting the SSL_OP_NO_TICKET
should be a workaround on the server as long as it is set in all relevant
SSL_CTX structures.
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
