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

[Matt Caswell via RT]

On 02/11/15 10:16, Albe Laurenz via RT wrote:
> 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.

I don't they you have understood the exploit. In my second example the
*attacker* initiates the connection to the server *and* the subsequent
renegotiation. Therefore the attacker already knows the keys negotiated
during the initial handshake. She does *not* know the keys associated
with the session that is going to be renegotiated. But she doesn't need
to know those because she sends application data before that encryption
context is in place, but after the new identity has been associated with
the connection. This attack is about stealing an identity not about
eavesdropping encrypted data.


> 
> 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?

No. In the current code, once renegotiation has started then no
application data will be returned to the application until it has
completed (or if application data is encountered then the connection
will abort). So there will never be a scenario where application data is
returned and the connection is in an intermediate state.

> 
> 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.

It isn't just callbacks. A call to SSL_read will return to the calling
application mid-renegotiation if application data is encountered.

Matt