# TLS: Does Diffie-Hellman make private keys useless

When we are using TLS these days we use DH to establish a session key. So where in the TLS protocol do we determine that the host that we're talking to actually possesses the private key corresponding to the x509 certificate that it provided earlier? Or is this no longer required?

• The host signs his public DH key. – SEJPM May 20 '17 at 21:53

When we are using TLS these days we use DH to establish a session key.

That depends, the RSA_ ciphersuites - that encrypt the session key using the RSA public key of the server key pair - can still be used even with TLS 1.2. They will be completely deprecated for TLS 1.3 as it looks now.

There are the ephemeral-static protocols as well - DH_ instead of DHE - although these are commonly not used in practice; they require a special X.509 certificate with DH or ECDH keys.

So where in the TLS protocol do we determine that the host that we're talking to actually possesses the private key corresponding to the x509 certificate that it provided earlier?

Absolutely. Let's take a look at the 1.2 standard:

When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSA or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In either case, the client can verify the certificate or signature to ensure that the parameters belong to the server.

And this is apparent in the ServerKeyExchange message (in C):

case dhe_rsa:
ServerDHParams params;
digitally-signed struct {
opaque client_random[32];
opaque server_random[32];
ServerDHParams params;
} signed_params;

signed_params
For non-anonymous key exchanges, a signature over the server's
key exchange parameters.


Or is this no longer required?

Of course this is required, unless another method of authentication - such as a pre-shared key (PSK) - is used. How would you otherwise authenticate the server?

Just possessing the public certificate is obviously not enough; the server needs to show that it can use the private key associated with the server certificate (within the verified & validated chain of certificates build by the client).