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

[Matt Caswell via RT]

On 25/10/15 11:12, Albe Laurenz via RT wrote:
> 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.

I don't think that it does say that. At least not the way I read it. The
Client does not know that its request to reuse a session has been
accepted by the server until it processes the ServerHello. I see nothing
in the above which says a client is not allowed to send application data
after it has sent its ClientHello but before it has processed the
ServerHello.

>From a server perspective if it receives ApplicationData after it has
sent the ServerHello it would have to assume that it is "in transit"
application data sent from the client before it has processed the
ServerHello.

My concern though is broader than this specific case. I have given two
*examples* of exploits that we may open ourselves up to if we attempt to
process this application data without some fairly significant
refactoring of the code to separate out state currently in the process
of being negotiated from state for the current epoch. We could probably
patch things up to work around these two specific examples but I worry
that without the more significant refactoring work, we may open
ourselves up to other attacks that we haven't thought of.

Matt