Re: [TLS] MITM Attacks on Client Authentication after Resumption

[[e-mail] (Martin Rex)]

Andrei Popov wrote:
>
> Ø  I would note that the renegotiation handshake we are speaking about
> is not exactly a standalone authentication protocol.

But we know since at least late 2009 that TLS server that use/allow
delayed authentication through renegotiation abuse the rengotiation
handshake in EXACTLY such a fashion, they have been turning the mere
technical successful completion of a TLS renegotiation handshake into
an OTP scheme that authorizes a previously received, unauthenticated
request.
 
As I wrote in my 2009 posting about the problem:

  The victim [] TLS server has no means to detect that it has been
  attacked.  Whether the TLS client cares about receiving a different
  TLS server cert in the renegotiation handshake and what it will
  do about it -- if anything, depends entirely on the application
  of the TLS client.  At the TLS level, everything looks just fine.

  I'm not sure that all clients will repeat the server authentication.
  They can be expected to verify the server certificate before sending
  off their request.  Depending on the API architecture, they may not
  always realize or care that a renegotiation was performed while they
  were sitting on SSL_read() waiting for the server reply.

  And even if they decide to perform an additional server endpoint
  identification, they might be doing it after the renegotiate
  handshake has been successfully completed -- a point where the
  victim [] TLS server has started performing the action requested
  in the anonymous request from the MITM.


Because of the nature of this problem, that the server reinterprets
a technically successful renegotiation handshake into an OTP authentication
scheme to authenticate a previously received, unrelated and unauthenticated
request, the following guidance was added to rfc5746:

  http://tools.ietf.org/html/rfc5746#section-5

   While this extension mitigates the man-in-the-middle attack described
   in the overview, it does not resolve all possible problems an
   application may face if it is unaware of renegotiation.  For example,
   during renegotiation, either the client or the server can present a
   different certificate than was used earlier.  This may come as a
   surprise to application developers (who might have expected, for
   example, that a "getPeerCertificates()" API call returns the same
   value if called twice), and might be handled in an insecure way.

   TLS implementations SHOULD provide a mechanism to disable and enable
   renegotiation.

   TLS implementers are encouraged to clearly document how renegotiation
   interacts with the APIs offered to applications (for example, which
   API calls might return different values on different calls, or which
   callbacks might get called multiple times).

   To make life simpler for applications that use renegotiation but do
   not expect the certificate to change once it has been authenticated,
   TLS implementations may also wish to offer the applications the
   option to abort the renegotiation if the peer tries to authenticate
   with a different certificate and/or different server name (in the
   server_name extension) than was used earlier.  TLS implementations
   may alternatively offer the option to disable renegotiation once the
   client certificate has been authenticated. 


>
> It is the second handshake on a connection, with different client or
> server identity than the first handshake. This leaves room for confusion:
> should an implementation associate the connection to the first set
> of principals or the second?

The guidance from rfc5746 should be clear.

The server which is doing delayed authentication through renegotiation
is still comitting the sin here.  Currently, it dumps the problem and its
mitigation for this risky server-side behaviour entirely on the client.


> 
> When a renegotiation happens, the TLS client must validate the newly
> negotiated parameters, including the server cert, the cipher suites,
> Finished hash, etc. A TLS client that neglects to validate the server
> certificate after renegotiation simply has a bug.

The problem can easily be an "added value" provided transparently by the
underlying TLS client implementation, and the application client may not
be aware that it has to cover the ass of the server, who is abusing
the renegotiatiation handshake for delayed authentication.


> 
> It appears that the attack described is only feasible when two
> implementation defects are present:
> 
> 1.  TLS implementation error in the client (failure to validate
>     the server cert),  and

After rfc5746 this would be a defect of an rfc5746-enhanced TLS client
to "transparently" replace the server cert after the first handshake
completed without being explicitly authorized by the application caller
to do so.

> 
> 2. A server application that associates data received from an
>    unauthenticated client with the data received after enabling
>    TLS client authentication.

Requesting TLS clients through renegotiation rather than upfront seems
to be pretty common (it even seems to be the default in IIS 7.x),
and some browser even have small difficulties being asked for a
certificate upfront (such as Safari).


> 
> While we cannot prevent the latter at the TLS protocol layer,
> I believe fixing the bug in the TLS client effectively thwarts this attack.


The original renegotiation problem and the newly describe session resumption
problem are very similar:  flawed assumptions about a cryptographic binding
that doesn't exist.  But until you write down the exact properties and
think about it, you may not notice the problem.  As soon as you write it
down, the problem becomes obvious.

The abbreviated TLS handshake authenticates only the MasterSecret.
But the MasterSecret is derived exclusively from ClientHello.random,
ServerHello.random and the keyExchange transform, there is no cryptographic
binding to any identities that are authenticated during the TLS handshake.


So the fix of the abbreviated TLS handshake needs to account for the
(re-)authentication of the identities of the original full handshake,
either by modifying the MasterSecret computation or by authenticating
the original full handshake during the abbreviated TLS handshake
through a TLS extension similar to how the renegotiation_info extension
does this in the renegotiation handshake.


-Martin