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; rs...@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
signature.asc
Description: This is a digitally signed message part.
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev