Re: [TLS] Handshake not under protection

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> Martin Rex wrote:
> >
> > Marsh Ray wrote:
> > >
> > > 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.
> > 
> > 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'm not sure I can follow why you think it is protected.

RFC-5246, 7.4.3.  Server Key Exchange Message

      struct {
          select (KeyExchangeAlgorithm) {
              case dh_anon:
                  ServerDHParams params;
              case dhe_dss:
              case dhe_rsa:
                  ServerDHParams params;
                  digitally-signed struct {
                      opaque client_random[32];
                      opaque server_random[32];
                      ServerDHParams params;
                  } signed_params;
              case rsa:
              case dh_dss:
              case dh_rsa:
                  struct {} ;
                 /* message is omitted for rsa, dh_dss, and dh_rsa */
              /* may be extended, e.g., for ECDH -- see [TLSECC] */
          };
      } ServerKeyExchange;

There is signed_params in the Server Key Exchange Message, but
it does _not_ seem to protect from MitM (when the attackers objective
is to elicit a Certificate message with the client's identity
from the attacked client).

If an attacker has a rogue server that wants to determine the client's
identity, then this attacker could open a connection to the particular
server to which it knows the client will reveal his identity,
resend the ClientHello just received and obtain a ServerHello and
ServerKeyExchange that match and then replay this information to
the client (i.e. the server_random used by the real server and
the signed_params sent by the real server.


-Martin