Public key on Server Key Exchange Generation vs Public key on Server's Certificate

Question

To understand the distinction between TLS 1.2 and TLS 1.3. I am stuck in the past understanding for TLS and the current reference I am studying:

As I know certificate goes with owner's public key, and its public key is used for key exchange between client and server to generate long-term pre-shared key.

But I feel confused with this understanding when I look into the phase Server Key Exchange Generation in TLS 1.2.

It says public key derived from server for key exchange is not the attached one but the new one derived from random number $2^{256} -1$ as private key.

Which one is right? I have heard about both in different references. Also it makes me breed another question about prevention from man-in-middle-attack via certificate as follows:

If a user's browser is tampered with spoofed DNS resolver which returns fake server's IP address that serves same host name of website with the certificate fetched from real website. How the browser verifies the integrity if the TLS handshake uses two different key pairs in certificate verification and key exchange?

Answer 1

TLS ≤1.2 allows different types of handshakes where the key exchange and the authentication rely on different mechanisms. The type of handshake is determined by the choice of cipher suite. The page you link to illustrates the most common type, where key exchange and server authentication work independently. This type of handshake is the one used by ciphersuites with ECDHE or DHE in their name.

For this type of handshake, the key exchange uses an [elliptic curve] Diffie-Hellman key agreement algorithm with an ephemeral (i.e. single-use) key. To generate the ServerKeyExchange message, the server generates an (EC)DH private key, and the ServerKeyExchange message contains the corresponding public key. The client does the same for the ClientKeyExchange message. The two sides then perform a Diffie-Hellman key agreement algorithm using their own private key and the other side's public key to generate a shared secret. By the design of DH, the two sides generate the same shared secret. This shared secret is the premaster secret for the TLS protocol.

In the specific example in your link, the server chose the X25519 group for the key agreement. For this particular group, a private key is an integer between $0$ and $2^{256}-1$.

None of this allows the client to know who it's exchanged data with. This comes from a different part of the ServerKeyExchange message: the signature. The server sends a signature of the important handshake data so far made with its private key. Specifically, the signed data includes the client nonce from the ClientHello message, the server nonce from the ServerHello message, and the DH public key. Previously, the server sent a Certificate message containing its certificate. The client verifies that:

• The signature sent by the server is a correct signature of the appropriate handshake messages, made with the private key corresponding to the public key in the certificate sent by the server.
• The certificate is signed by a certificate authority (CA) that the client trusts, or more generally that there is a chain of trust going from a trusted CA to the server's certificate.
• The subject name in the certificate matches the server name that the client was attempting to contact.

A man-in-the-middle attacker who spoofs DNS records won't be able to get all of these verifications to pass.

• The attacker can send the expected certificate and replay a good signature from a past exchange that it observed with the legitimate server, but then this signature won't be correct, because the handshake messages include a random nonce sent by the client.
• The attacker can forward the ClientHello message to the legitimate server, get the legitimate server's ServerExchangeMessage and forward that to the client. Since the signature in that message includes the DH public key chosen by the server, the attacker won't have a way to find the shared secret. In this case, the exchange can go through if the attacker keeps forwarding both sides' messages intact, but the attacker won't be able to decrypt the messages or to modify them undetected. Since the attacker isn't able to violate the expected security properties of the TLS protocol, they aren't actually attacking anything: they're just a TCP router.
• The attacker can send the expected certificate and a signature made with its own private key, but then the signature won't be correct, because the attacker would need the legitimate server's private key to make a correct signature.
• The attacker can send a certificate containing fake data, but then the client will detect that the certificate is not internally consistent or that the certificate is not signed by a CA that it trusts.
• The attacker can send a valid certificate made by a CA that the client trusts, but then (assuming the CA has done its job correctly) this certificate will contain a subject name that the attacker owns, and not the subject name that the client was trying to contact.