On Friday 16 October 2015 09:55:41 Matt Caswell wrote: > On 16/10/15 09:53, Matt Caswell via RT wrote: > > On 13/10/15 12:31, Hubert Kario via RT wrote: > >> On Tuesday 13 October 2015 09:22:53 Matt Caswell via RT wrote: > >>> On 12/10/15 17:19, Matt Caswell via RT wrote: > >>>> On 12/10/15 16:39, Matt Caswell via RT wrote: > >>>>> The value of "in_read_app_data" not being true when it is > >>>>> supposed > >>>>> to > >>>>> appears to be running into a slightly different bug. It's also > >>>>> present in 1.0.2 but you have to switch off version negotiation. > >>>>> So running s_server like this in 1.0.2 and rerunning Hubert's > >>>>> test > >>>>> will hit it: > >>>>> > >>>>> openssl s_server -www -tls1_2 > >>>>> > >>>>> The 1.0.2 version negotiation is hiding the issue. In master > >>>>> version neg has been completely rewritten and simplified - but > >>>>> in > >>>>> doing so no longer hides the problem. :-( > >>>> > >>>> Having done some more digging it seems the problem only occurs if > >>>> you > >>>> get the initial handshake, following by a second reneg handshake > >>>> *and* interleaved app data all within the scope of a *single* > >>>> SSL_read call. AFAICT if SSL_read returns between the first > >>>> handshake and the second, you don't get the problem. > >>> > >>> Ok, updated version of the patch attached. This is for 1.0.2 but > >>> should pass Hubert's tests even when you run s_server with > >>> "-tls1_2". > >> > >> yup, looks good with -tls1_2 now too > >> > >> for some reason my side can't negotiate TLS 1.1 or TLS 1.0 > >> correctly so can't test -tls1_1 or -tls1 (I'm likely generating > >> malformed CKE there, but need to check to be sure) > > > > I raised the ambiguity in the spec about when in the handshake > > interleaved app data is allowed with the TLS WG. You can see the > > thread here: > > https://www.ietf.org/mail-archive/web/tls/current/threads.html#18017 > > > > I got a few responses, not all of which were consistent, and giving > > different views. To summarise what I interpret as the main points: > > > > 1) Where a view was given it seemed to concur with the views > > expressed here that the most sensible interpretation of the spec > > wording is that interleaved app data is allowed up until the CCS, > > but not between CCS and Finished. > > 2) There was also a view expressed that, regardless of what the spec > > says, allowing interleaved app data is *dangerous*! > > 3) There seemed to be differing views on just how dangerous ranging > > from it being "a highly dangerous idea" to "...there is a need for > > caution, but in reality, it's not like you can use renegotiation to > > hand-off to someone else entirely. The person you are talking to > > hasn't changed. What is dangerous is making assertions about *new* > > things that the renegotiation introduces", although the same person > > who made that last observation also provided a list of very onerous > > mitigations that we should put in place if were to do it (none of > > which are likely to be adopted IMO without some form of official > > advice from the TLS WG). > > > > So now I really don't know what the "right" way forward is. Should > > we be applying the patch or not? > > I should add that another interesting point was that BoringSSL > prohibits interleaved app data.
just like OpenSSL now :) -- Regards, Hubert Kario 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
