Re: [TLS] MITM attack on delayed TLS-client auth through renegotiation

[Nicolas Williams <[e-mail]>]

Martin,

You're right, of course, but this attack is easily defeated by the
client checking that the server certificate is the same for the outer
TLS connection as for the inner one.  It's also easily defeated by the
server sending a ChangeCipherSpec in the re-negotiation: the MITM will
not be able to decrypt or tamper with the record layer for the inner
connection (and if the MITM pretends to the client to be the server end
of the inner connection then it will not be able to authenticate as the
client to the real server).

But suppose the MITM can get the client to accept an TLS_DH_anon_*
cipher suite for the outer connection: then there's no way for the
client to ensure that the server end-points of the two connections are
the same.  The best way to defeat this now then is to have the server
*always* send a ChangeCipherSpec in the re-negotiation.

Re-negotiation handshakes are tunneled in the record layer of a previous
TLS connection, and the only links between the two connections (inner
and outer) are the authentication credentials of the two end-points.
Usually the client end-point will be anonymous in the outer connection,
and not anonymous in the inner one.  And usually the server certificate
must be the same in both cases.  Checking that the latter is the case
and/or sending a ChangeCipherSpec in the re-negotiation, is and should
be sufficient; it should also be required.

Another solution would be to use bind the outer connection into the
inner connection's PRF, so as to ensure that the Finished messages can
only check out if both end-points of the inner connection are also the
same end-points for the outer connection.  This is what we call channel
binding.  The additional PRF inputs extension would provide the
necessary channel binding facility.

In general I prefer the channel binding approach because it's easier to
make it work in all cases.  Anon-anon cipher-suites?  No problem.

Note that there is a security consideration here for the TLS channel
bindings then, particularly tls-unique: if the inner and outer channels
are not bound somehow (either by having the same server end-point cert,
or by channel binding of the inner to the outer) then we should want the
TLS channel binding see by the application to be that of the of the
inner channel, _and_ we should want the inner channel's negotiation to
have included a ChangeCipherSpec.

Thanks for bringing this to light.

Nico
--