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 _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
