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

[Matt Caswell via RT]

On 23/10/15 15:33, Albe Laurenz wrote:
> 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.

No, that's not what I meant. The attacker eavesdrops on the initial
handshake between a legitimate client (where that client has presented a
certificate) and the server and makes a note of the session id.

The attacker then creates a completely new anonymous connection (they
don't use the session id yet). Then they initiate a renegotiation, but
this time present the stolen session id. Before they complete the reneg
handshake they start sending application data. That application data
will be processed by the server application in the context of the
certificate associated with the stolen session, but before the CCS has
been processed.

Matt