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

Matt Caswell via RT rt at openssl.org
Fri Oct 16 08:53:06 UTC 2015



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?

Matt




More information about the openssl-dev mailing list