# TLS Handshake : Server authentication or only Server ‘s Certificate authentication?

I have some difficulty understanding the way in which the Server is really authenticated by Client in TLS handshake (in case of using RSA key exchange).

When Client receives Server ‘s Certificate and verifies it with using CA root public key, I fully understand that at this time, Client can consider that such received Certificate is valid and authentic if verification is ok

But if Server’s certificate is checked sucessfully by Client, how is it possible to consider that Server has been authenticated by Client, while at this time none message signed with Server’s private key has been sent to the Client and verified by it ? Can’t intruder possess and send real Server's certificate to the Client ?

• Note : I agree that if Server is not the real one and so doesn't possess real Server private key, it will not be able to decrypt the pre-master key sent by Client, but this appears as indirect / implicit authentication, rather than explicit authentication

More generally (outside case of TLS), is it correct to talk about « Authentication by Certificate » (assuming based on Certificate verification via CA root public key) instead of authentication via digital signature ?

• Note: If you use DHE / ECDHE key exchanges, the server signs its DH share. So there you have the explicit authentication. I assume your question is about the RSA key exchange. (Which is dropped starting with TLS v1.3) – SEJPM Aug 29 '15 at 20:16
• sejpm - thanks for precision - yes you're fully right with using DHE . ECDHE as Client receives messages signed by Server's private key. So effectively my post & question concerned specifically case of RSA key exchange. – william_fr Aug 29 '15 at 20:38
• Note that in TLS 1.3, server authentication happens explicitly using CertificateVerify message (tools.ietf.org/html/rfc8446#section-4.4.3) – mskd96 Mar 21 at 15:14

But if Server’s certificate is checked sucessfully by Client, how is it possible to consider that Server has been authenticated by Client, while at this time none message signed with Server’s private key has been sent to the Client and verified by it ?

If only consider the key exchange to be what the RFC says it is, then yes this key-exchange can be broken by an attacker having the right certificate.

However this is not how TLS works in practice. In practice you'd never stop after the ClientKeyExchange message as you have set-up the connection to actually do something. This is why most formal analysis considers ChangeCipherSpec and the Finished messages as part of the key-exchange for their proofs.
And it only matters that the server is successfully authenticated after they complete key-exchange, not at some "randomly chosen" point in the protocol.

The exchange turns out to be secure and properly authenticated by verifying the Finished message which contains a MAC on all previous (handshake) messages. Because a fake server can't decrypt the pre-master secret and hence can't compute the master secret, he can't compute the neccessary MAC and the client will respond with a fatal_alert, killing the connection.

I don't know why the designers of TLS chose this "through the backdoor" authentication method but I can only guess they wanted to avoid yet another computationally intensive private key based operation for the server.

TL;DR: The finished message gives you authentication with its MAC only being available to the private key holder.

Is it correct to talk about "Authentication by Certificate" (assuming based on Certificate verification via CA root public key) instead of authentication via digital signature?

You never authenticate by only presenting a certificate.
The only situation where you may do it is with secure tokens holding key-files to access some physically restricted facility where the tokens will never actually be plugged into a real computer (aside from new file assignment).

In an internet-based scenario you'd never do this as every eavesdropper could impersonate the owner of the certificate, rendering it completely useless.

What TLS does (and may be meant by your question) is encryption-based / certificate-based authentication. This is basically some sort of challenge-response protcol, where you send some party a random nonce and an asymmetrically encrypted key and expect the MAC on the nonce using that key as response. One can do that, but this is rather "abusing" the encryption to do things it was not intended to, as we have dedicated constructions for that: digital signatures.
So usually a designer would rather go with a digital signature and an encryption ( / decryption) (or even better DH) as today it's pretty cheap to do both operations, whereas you may need to use the encryption based approach for very constrained devices where only one such operation is "allowed" / feasible or where actually can't perform signatures (by padding, rather unusual).

TL;DR: Solely certificate based authentication is bad and only feasible in physical access restriction scenarios and otherwise you can do challenge-response with encryption but should prefer signatures.

• sejpm - Thanks it is more clear now for TLS handshake when considering in reality a combined authentication & key exchange operation which is closed by FINISHED message, rather than (as seen is some articles) considering a standalone authentication step followed by standalone key exchange step which confused me in case of RSA key exchange. – william_fr Aug 30 '15 at 11:15

As far as I understand the handshake: I think if the Certificate Authority is compromised and mallory gives you a faked but "valid" certificate, then you have no chance to find out, that you are not connected to bob.