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

[Matt Caswell]

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.

Matt