[openssl-dev] [openssl.org #3712] TLS Renegotiation with Java is broken

[Hubert Kario]

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
-------------- 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/20151016/0b1f2566/attachment-0001.sig>