3

I am trying to understand the working of TLS. I understand that there are various way to generate the master secret used to encrypting the data. Such as DH (Ephemeral DHE) and RSA. I understand that, when using RSA, the client generated pre-master key is encrypted by server's public key and is sent back to server for the computation of the master secret. But what about the process when using DHE?

I see that DH public keys of both client and server is used to compute the Master secret? But, is the DH public key the same as the Server's public key?

In Layman's term, is the RSA public key considered as the server's public key?

2

Short answer: it can be, but it's complicated and it depends on what kind of certificate the server has and which TLS cipher suites it's configured to use.

This answer is essentially a copy of this openssl wiki page. Let's go through some examples.

Pure RSA

For these, the server's certificate will contain an RSA key and you will use a cipher suite like

TLS_RSA_WITH_....

The session key will be generated client-side and sent to the server encrypted with the server's RSA key. For the authentication part of the handshake, the server will use the same RSA key to produce a signature (I think).

Static DH - anonymous

For these, the server uses the same DH keys for each connection, however there is no certificate, so no way for the client to check that this key actually belongs to the server and not to a man-in-the-middle. You will use a cipher suite like

TLS_DH_anon_WITH_....

Note: clearly this is insecure.

Static DH - with certificate

For these, the server uses the same DH keys for each connection and the public key will be placed in the server's certificate (a DH certificate rather than the more common RSA certificate). You will use a cipher suite like

TLS_DH_RSA_WITH_...

As noted here, the signature algorithm (RSA/DSS) indicates which signature algorithm the CA used to sign the certificate and there is no signature as part of the handshake; if the server arrives at the same session key, then it must have the matching DH private key.

Note: this is old and deprecated, people prefer DHE now.

Ephemeral DHE + RSA

For these, the server's certificate will contain an RSA key and you will use a cipher suite like

TLS_DHE_RSA_WITH_...

Since the DH is ephemeral, a new DH key will be generated for each new connection so there is no need to put it in a certificate. The RSA key is used to sign a challenge response to prove that the server is who they say they are. These are the preferred ciphers these days.

  • OP is talking about the use of DH vs RSA as a KEM, not certificates. – forest Jul 20 '18 at 3:46
  • @forest Why not both? The question asks about "the server's public key",, which by definition is the certificate. When're using a KEM other than DHE, it's the KEM key that goes in the certificate. – Mike Ounsworth Jul 20 '18 at 11:45
  • 1
    DH_anon (and ECDH_anon) uses no certificate at all; that's what 'anonymous' means in the SSL/TLS context. DH_$auth (and ECDH_$auth) (even though which $auth is ignored in 1.2) does use a certificate containing a long-term DH (or ECDH) key. – dave_thompson_085 Jul 20 '18 at 12:16
  • @dave_thompson_085 Right, thanks for calling out my misunderstanding :) – Mike Ounsworth Jul 20 '18 at 12:47
  • My browser suggested "@dave_thompson_085 pointed out some stupids that I made." for the Edit Comment, so this is not the first time you've kept me honest. I thank you for it :P – Mike Ounsworth Jul 20 '18 at 12:59
3

CloudFlare explains that Diffie-Hellman and RSA, both used in key exchange mechanisms, have advantages.RSA and DH handshake Keyless SSL: The Nitty Gritty Technical Details .

The RSA and DH handshakes both have their advantages and disadvantages. The RSA handshake only uses one public key algorithm operation, RSA. A DH handshake with an RSA certificate requires the same RSA operation, but with an additional DH operation. Given that the certificate is RSA, the RSA handshake is faster to compute. Public key algorithms like RSA and DH use a lot of CPU and are the slowest part of the TLS handshake. A laptop can only perform a couple hundred RSA encryptions a second versus around ten million per second of the symmetric cipher AES.

The DH handshake requires two algorithms to run, but the advantage it brings is that it allows key establishment to happen independently of the server’s private key. This gives the connection forward secrecy, a useful property that protects conversations from being decrypted after the fact if the private key is somehow exposed. The DH version of the handshake also opens up the possibility of using non-RSA certificates that can improve performance, including ECDSA keys. Elliptic curves provide the same security with less computational overhead. A DH handshake with and elliptic curve DSA certificate and elliptic curve Diffie-Hellman key agreement can be faster than a one-operation RSA handshake.

I believe Diffie-Hellman and its TLS/SSL usage will further explain.

Presuming the "server's public key" is used for authentication, then no. The DH public key and the server public key, are not the same. However, I have seen very much mixed opinions on this matter. TLS 1.2 appears to use DH and RSA for the key exchange mechanism. DH is used to produce the symmetric key for a symmetric algorithm. DH in itself is not a data encryption algorithm necessarily, but a way to agree on a secret key via a public network.

  • My mistake, I associated public-key cryptography with asymmetric cryptography. DH is used to produce the symmetric key for a symmetric algorithm. DH in itself is not a data encryption algorithm necessarily, but a way to agree on a secret key via a public network. I will correct the mistake to prevent further confusion! – safesploit Jul 16 '18 at 18:07
  • I hadn't thought of using DH for authentication before, but it does seem that's possible with a static key, so thanks for pointing that out! It looks like TLS actually does support it, it's just not very common. – AndrolGenhald Jul 16 '18 at 18:10
  • I understand this. From your last paragraph of answer, is the DH server key exchange signed by the server? – Anonymous Platypus Jul 17 '18 at 7:17
  • 1
    CloudFlare stats that their SSL handshake (DH) the server's private key signs the client random, server random and public key certificate. The server then sends the client the DH parameter and a signature. "The server also needs a way to prove that it has control of the private key, so the server computes a digital signature of all the messages up to this point "Message 2: “Server Hello”. Both the Diffie-Hellman parameters and the signature are sent in this message." [ blog.cloudflare.com/content/images/2014/Sep/… ] So yes, the DH key exchange is signed. – safesploit Jul 17 '18 at 16:55
  • 1
    (@safesploit) cloudflare's text is wrong, although the picture is actually right (through 1.2): the ingoing orange arrows are on the two randoms/nonces and the server DH parameters, and that is in fact what is signed in DHE_RSA (DHE_DSS also, but cloudflare doesn't use that); see rfc5246 7.4.3 et pred. (1.3 proposes to change this to a transcript signature, similar to the client side in current versions.) – dave_thompson_085 Jul 20 '18 at 12:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.