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

[Albe Laurenz]

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

Thanks for the explanation, I had indeed misunderstood the problem.

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

I understand.
Thanks for taking the time to explain.

Yours,
Laurenz Albe