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

[Hubert Kario via RT]

On Sunday 25 October 2015 22:52:36 Matt Caswell via RT wrote:
> 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.

+1

> 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.

exactly

> 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.

unfortunately I have to agree. Those two examples show in rather clear 
terms that openssl as it is now in stable branches, can't be easily 
patched up to handle even specific situations of interleaved app data 
with handshake data in renegotiated handshakes. So breaking such 
connections is a safer option.

That being said, Java behaviour is dangerous only if they expose to the 
application the "in negotiation" context instead of the "currently 
active" context. Not exactly easy to test.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20151029/d0787f99/attachment-0001.sig>