Re: [TLS] Handshake not under protection

[Geoffrey Keating <[e-mail]>]

Michael D'Errico <[e-mail]> writes:

> Martin Rex wrote:
> > Marsh Ray wrote:
> >> Martin Rex wrote:
> >>> Marsh Ray wrote:
> >>>
> >>>> At the TLS level, it's possible for the current session to be
> >>>> anon-anon-DH, which provides no protection.
> >>> And which rfc-5246 requires to _not_ request a client certificate:
> >>>
> >>>    7.4.4.  Certificate Request
> >>>
> >>>    When this message will be sent:
> >>>
> >>>        A non-anonymous server can optionally request a certificate from
> >>>        the client, if appropriate for the selected cipher suite.
> >> The client cert is requested in the renegotiating handshake, not the
> >> initial one.  An anon-anon-DH session provides no "protection" for the
> >> client cert passed in renegotiation.
> >>
> >> But it probably makes some people feel more secure to not see the
> >> details (usernames, emails, phone numbers, street addresses) flying by
> >> on the wire.
> > OK.  You are correct.
> > That provision in 7.4.4. is about the _current_ handshake only
> > and refers to the fact that a server has sent a "Certificate"
> > message prior to CertificateRequest.  Since at the point of
> > the handshake, the Server is _not_ authenticated.  There could have
> > been a certificate path validation of the server certificate,
> > but there is no proof yet, that the alleged server knows the
> > necessary private key to the presented certificate, so this
> > restriction in 7.4.4. does not provide security.
> 
> If a DHE cipher suite is used, then the server can be authenticated
> using only Certificate and ServerKeyExchange.  With RSA cipher suites,
> you are correct that a client doesn't authenticate the server until
> Finished verifies.

I think that still doesn't prove that there is no man in the middle.
The MITM could forward the ClientHello to the real server, which will
return a signed ServerKeyExchange with the correct client_random and
server_random.  The MITM won't be able to use the associated DH
parameters but they aren't necessary until later in the exchange.

Even sending the client certificate by renegotiating under an
anonymous connection provides protection against any attacker who can
see traffic but cannot (or does not want to) perform an active attack.
I don't think it's generally useful to do start off anonymous, though,
because the server is going to have to provide a certificate later
anyway.

Another approach, of course, is to not put unnecessary personal
information in the client certificate in the first place.