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

[Albe Laurenz]

Matt Caswell wrote:
> On 16/10/15 16:05, Hubert Kario via RT wrote:
>> we may actually be able to patch this up partially in 1.0.x
>>
>> the original problem description mentions server being unable to process
>> application data before Certificate/Client Key Exchange, not in any
>> place what so ever
>>
>> (Albe, please double check if you didn't saw Java sending app data at
>> any different point)
>>
>> unless the server is completely asynchronous, it's unlikely it will send
>> application data messages between handshake messages from a single
>> flight, it will send app data only between different flights
>>
>> in other words, we should still be able to accept this data before the
>> client responses had any chance to modify the certificates in the
>> server.
> 
> I think this is also not safe, in a slight amendment to my previous exploit.
> 
> Imagine an attacker who is able to eavesdrop on messages between a
> legitimate client who presents a client certificate to the server during
> the initial handshake. As it is during the initial handshake this
> happens in the clear, including the server responding with a session id.
> 
> Ordinarily knowing the session id does not help very much because the
> attacker does not know the associated keys so any attempt to reuse that
> session id will fail. However with the proposed patch in place the
> attacker can first establish a connection to the server anonymously.
> Then they send a new ClientHello, but this time provide the eavesdropped
> session id. The server updates the s->session value from the session
> cache which *includes* the peer certificate. The exploit can then
> proceed as before. The attacker does not continue the renegotiation
> handshake but instead sends application data attempting a privileged
> operation and the server application successfully verifies the identity.

Do you mean that the attacker pretends to be the legitimate client
and initiates renegotiation on their behalf?

I thought that the ClientHello would have to be encrypted in that case,
something which the attacker couldn't do.

If I misunderstood and that is indeed not safe, wouldn't that mean that
sending application data interleaved with renegotiation, like Java does,
is a security leak?

In that case it should be reported to Oracle.

Yours,
Laurenz Albe