[openssl-dev] [openssl.org #2021] sni bug
The code in this area has changed significantly so it is far from clear whether this report is still relevant. Therefore closing. Please open a new ticket if required. Matt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2021] sni bug
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
Re: [openssl-dev] [openssl.org #2021] sni bug
> 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. Yes, but right now we've got what we've got :) > Actually it seems that you could influence the server behavoiur if you change > the order of extensions in the clienthello. Probably. > sni first or last for example. > That makes server application code difficult. Yes. It would be great to have a single function that got all parsed extensions. Sadly, I don't know if we'll get it fixed before the final API-change deadline. :( -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2021] sni bug
> 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. Yes, but right now we've got what we've got :) > Actually it seems that you could influence the server behavoiur if you change > the order of extensions in the clienthello. Probably. > sni first or last for example. > That makes server application code difficult. Yes. It would be great to have a single function that got all parsed extensions. Sadly, I don't know if we'll get it fixed before the final API-change deadline. :( -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #2021] sni bug
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. best -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #2021] sni bug
Is this still a bug? -- Rich Salz, OpenSSL dev team; rs...@openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=2021 Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
