[openssl-dev] [openssl.org #2021] sni bug

Hubert Kario hkario at redhat.com
Tue Feb 9 15:09:35 UTC 2016


On Saturday 06 February 2016 21:24:26 Peter Sylvester via RT wrote:
> On 06/02/2016 15:50, Rich Salz via RT wrote:
> > Is this still a bug?
> > --
> > Rich Salz, OpenSSL dev team; rsalz at openssl.org
> 
> I don't know, there have been many changes to the extension treatment.
> I have not followed the stuff since 5 years.
> 
> The extension handling is not what I had in the original design and
> seems to be broken.
> 
> There was no split into two functions two functions that communicate
> through the session.;
> 
> Some callbacks are done in the check loop (as far as I remember) .
> Unfortunately this split occured almost in parallel to our
> contribution in 2006 when some EC stuff was added.
> 
> A correct logic is one single function(the code of check and parse
> combined) that collects the values of extensions
> and then treat them calls callbacks in a defined order.
> 
> Actually it seems that you could influence the server behavoiur if you
> change the order of extensions in the clienthello.
> sni first or last for example.
> That makes server application code difficult.

I'm not sure if I understand.

Is the problem in OpenSSL internal handling of extensions or is it in 
the treatment that callbacks get?

And which exact extensions interact badly with each other? Is it 
server_name[1] and any other extension (e.g supported_groups)?

Can I trigger it with just s_server?

I'm asking, as that's one of the test scenarios I want to cover in the 
tlsfuzzer - verification that server behaviour stays the same no matter 
the order of extensions in Client Hello. 

 1 - https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160209/c48fbabf/attachment.sig>


More information about the openssl-dev mailing list