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

[Matt Caswell via RT]

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.
> 
> of course, that doesn't allow us to fix it for the other side of 
> connection - where the application data is sent by server after Server 
> Hello Done and before server Change Cipher Spec

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.

Matt