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

[Albe Laurenz via RT]

Hubert Kario wrote:
> On Friday 16 October 2015 08:53:06 Matt Caswell via RT wrote:
>> 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 can't think of a way to exploit it if two assumptions hold:
>  1). we have secure renegotiation
>  2). API calls return metadata (certificates especially) from *active*
>      context, not one currently negotiated

I tend to agree.
But isn't point 2) exactly what Matt calls a "very onerous mitigation"?

Reading the replies Matt got from the TLS WG I got the impression that
they go "yuck" when they hear the word "renegotiation", but that's hardly
an option if you want to implement a RFC that says otherwise.

Being the one who reported the problem, I am not impartial as to whether
the patch should go in or not.

Would it be an option to have the patch as it is, and if it is too
hard to have all API calls return data pertaining to the old context,
have them throw an error in that case?

That would keep things on the safe side and improve interoperability.

Yours,
Laurenz Albe