DHE exchange and client authentication

Question

If a server has a known public key and a Diffie-Hellman exchange is performed and signed by that key, is there any benefit to authenticating the client before establishing a secure channel instead of after establishing the secure channel? It seems to me that signing only one side of the exchange still prevents a man-in-the-middle attack.

Inspired by https://stackoverflow.com/questions/6156227/does-the-certificate-a-ssl-connection-state-points-to-change-if-i-load-a-new-ce

Answer 1

Client authentication is for the benefit of the server. Preventing a man-in-the-middle is a distinct matter.

If the key exchange uses DH with a signature by the server (relatively to a public key which is known to the client) then the client is protected from a man-in-the-middle: the client has a strong notion of who it should be talking to, and the signature by the server prevents an attacker from impersonating the server in any way (e.g. as a "man-in-the-middle", which is just a specific kind of impersonation).

Without client authentication, the server does not know who is contacting it. The rest of the protocol (e.g. SSL/TLS) will still provide protection against attacks in the following sense: it will be the same client all along the session, and no other party may spy on the data contents or alter the data in an undetected way. As such, a "man-in-the-middle" (as in: an attacker who acts as a relay, decrypting and re-encrypting data on the fly) is averted, because the client has verified the signature from the server, and therefore used the "right" Diffie-Hellman key, keeping any attacker out of the key exchange.

Client authentication as a signature, computed by the client with his own private key and corresponding to a public key known to the server, could help preventing a man-in-the-middle in a devious situation where the client does not (stupidly) check the signature from the server. Nothing can prevent this moronic client from connecting to a fake server, since it checks nothing and can thus be embezzled at will. However, client authentication is enough for the server to make sure that if the client talks to it at all, then it will do so in a secure way.

The key point here is a matter of definition. What is a "man-in-the-middle" ? This is a case where an attacker impersonates the intended peer (for it to be a "true middle", the attacker impersonates the server with regards to the client and the client with regards to the server). This makes sense only insofar as there is an "intended peer". If the server does not care who is contacting it, then there is no notion of "man-in-the-middle".

In the usual HTTPS scenario, the client is authenticated through a password: the client needs to be sure to talk to the right server right at the beginning (using the server certificate) because the client does not wish to send his password to anybody. The server just wants to have continuity: if it got a correct password through a SSL tunnel then the tunnel is good and will keep on being so.

Answer 2

Well... yes, the benefit is exactly that: authenticating the client.

In the primary use case today, the server's certificate is used to authenticate the server ("Verisign says this really is amazon.com") and to set up encryption (preventing snooping as well as man-in-the-middle).

Because it is rarely used, people do not think of the capability to authenticate the client. There is a practical reason for this, which is that a client "user" (human) may access the server from any number of client "machines" (computers), and if client keys are used they need to be securely distributed to all of them, the client machines need to be relatively trusted, etc. etc. But scenarios do exist where using (SSL) client authentication makes sense.

If smartcards had ever taken off, then you'd be seeing it all over the place. But they didn't. (Or just haven't yet, I honestly don't know).

Answer 3

Doing server authentication only will assure the client that it's speaking to the server. It will assure the server that the client that performed the handshake is the client that is doing the communication. It doesn't give the server any other information - in other words, the server won't know who the client is.

For some cases, that may be fine - for example, if login is accomplished through username/password after the session is set up.

It isn't good enough if you have a situation that requires client authentication via cryptographic proof of private key. In those cases, you'd either need to add some higher level transmission where the client signed something, or you'd have to require client auth during SSL session setup.

It all depends on the application.