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

[Albe Laurenz]

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

I think I get you - you are talking of an "abbreviated handshake" to duplicate
an existing session.

But RFC 5246 writes:

   When the client and server decide to resume a previous session or
   duplicate an existing session (instead of negotiating new security
   parameters), the message flow is as follows:

   The client sends a ClientHello using the Session ID of the session to
   be resumed.  The server then checks its session cache for a match.
   If a match is found, and the server is willing to re-establish the
   connection under the specified session state, it will send a
   ServerHello with the same Session ID value.  At this point, both
   client and server MUST send ChangeCipherSpec messages and proceed
   directly to Finished messages.  Once the re-establishment is
   complete, the client and server MAY begin to exchange application
   layer data.

That seems to spell out in pretty uncertain terms that no application data
may be exchanged until the handshake is complete, so OpenSSL should just
error out in that case.

Or are you saying that it is difficult to disambiguate between this case and
a renegotiation from within the code?

Yours,
Laurenz Albe