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

[Albe Laurenz]

Hubert Kario wrote:
> On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote:
>> My concern though is broader than this specific case. I have given two
>> *examples* of exploits that we may open ourselves up to if we attempt
>> to process this application data without some fairly significant
>> refactoring of the code to separate out state currently in the
>> process of being negotiated from state for the current epoch. We
>> could probably patch things up to work around these two specific
>> examples but I worry that without the more significant refactoring
>> work, we may open ourselves up to other attacks that we haven't
>> thought of.
> 
> unfortunately I have to agree. Those two examples show in rather clear
> terms that openssl as it is now in stable branches, can't be easily
> patched up to handle even specific situations of interleaved app data
> with handshake data in renegotiated handshakes. So breaking such
> connections is a safer option.
> 
> That being said, Java behaviour is dangerous only if they expose to the
> application the "in negotiation" context instead of the "currently
> active" context. Not exactly easy to test.

Sorry for being obtuse, but I don't see yet why these concerns should
prevent a simple fix.

If interleaved application data are only allowed
a) before Change Cipher Spec
b) during a renegotiation, i.e., when the connection is encrypted

your second example and similar exploits would not work, because the
application data would have to be encrypted with a cipher that is
known to be secure.

That leaves us with the first problem, namely that calls like
SSL_get_peer_certificate() will return incorrect values when renegotiation
has started but is not yet complete.

I agree that the window for such a mistake will be widened somewhat
if the client were allowed to send application data after renegotiation
has started, but the problem already exists in the current code, right?

What keeps the client from first sending the application data that cause
the dangerous call by the server and immediately afterwards starting a
renegotiation with a certificate for which they have no private key?

So I think that that is a separate issue that should not be held against
an improvement like the one this patch would provide.
Maybe it can be fixed by disallowing callbacks that would return
incorrect data while renegotiation is in progress.

Yours,
Laurenz Albe