TLS-RSA vs TLS-ECDHE-RSA vs static DH

Question

I understand there are a lot of articles explaining this subject and, before I post my question, this is my current understanding about it:

ECDHE-RSA = The server randomly generates a DH-key pair because the certificate has not sufficient information to send over to the client for master secret generation. The DH public key is sent in a "server key exchange" packet. The secret will never be sent over the wire. The "RSA" in the cipher suite refers to the random DH public key signature, but not to the certificate signature.

Static DH = The server has a fixed DH public key in the certificate, it will be used by the client for shared secret generation. The secret will never be sent over the wire. Since this information is enough, the server key-exchange message is not needed.

RSA = The client will use server's public key to encrypt the PMS and send it over to the server. The server will decrypt the PMS and generate the same PMS. The secret is sent over the wire.

Put static DH aside for now as it is not commonly used on the Internet - I can't find one with Wireshark.

This is my question:

I compare the pcap between TLS-RSA and TLS-ECDHE-RSA, finding that:

• In the certificate presented by the server, both contain an RSA public key (subject public key) and the certificate has an RSA signature (Sha256withRSAencryption)

• In the "server key exchange" packet for TLS-ECDHE-RSA, there is a DH key with RSA signature.

The RSA signature for the "dh key" and "certificate" is used for authentication purposes / digital signature for the server to prove it is who it claims to be.

"RSA public key" in the certificate, for TLS-RSA, is used by the client to encrypt the PMS. It can be seen at the "client key exchange" packet. Then, what is its function in the case of TLS-ECDHE-RSA?

Answer 1

I am assuming you are talking about these in context of TLS, particularly TLS ciphers. There seems to be some confusion around the what each component does. It is all easier to understand if you see the whole picture so here it is.

During a TLS handshake the following things happen: authentication, key exchange. The details about these depend on the so called cipher suite. Here is a sample.

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

This basically says the following.

1. The server will serve a certificate, which contains an RSA public key. This will be used for authentication.
2. The key exchange will be done using ECDHE.
3. The symmetric cipher used after the key exchange will be AES-GCM with a 128 bit key.
4. The PRF (pseudo-random function) to use during the exchange is SHA256 (it may also indicate the MAC w/ older TLS versions).

Look closely and you will see how all these are represented in the cipher suite.

Now let's see what these might mean: ECDHE-RSA, Static DH, RSA

ECDHE-RSA = server randomly generate a DH-key pair because the certificate has no sufficient information to send over to client for master secret generation. The DH public key is sent in "server key exchange" packet. The secret will never be sent in the wire. The "RSA" in the cipher suite refers to the random DH public key signature, but not the certificate signature

You are on the right track here, and now, with the knowledge about the whole picture, it is easier to understand this. During a "classic" key exchange, the public key in the certificate (and its private pair) is used to agree on a symmetric key. This, however, creates problems if the server's key is ever compromised. If private key corresponding to the public key in the certificate is ever stolen, previously recorded traffic can be decrypted at ease.

This is something we generally want to avoid. Enter Forward Secrecy. The protocol introduces the possibility to have a separate key exchange which does not depend on the RSA key pair that much. The algorithm usually used for this is called Diffie-Hellman.

For DH to work you need the so called DH-parameters, which are basically a prime modulus and a generator. These parameters are public. These are precomputed during the server setup time and shared with each client during the key exchange. Clients in cooperation with the server then use these parameters to agree on a key without actually sending it over the wire, just like you said. Here is a great video about this from the Khan Academy. The DH-key pair's private key is essentially the private number in the video. While the public key is what is sent on the wire.

To sum it up, ECDHE is Ephemeral Elliptic Curve Diffie-Hellman, which is DH over elliptic curves. The ephemeral part refers to the fact that each connection uses a different, randomly generated DH-key pair.

Static DH = server has a fix DH public key in the certificate, it will be used by the client for share secret generation. The secret will never be sent in the wire. Since information is enough, server key exchange message is not needed

Static DH refers to the server choosing the same DH key-pair for every client connection (private number in the video). Or, like you suggested, it can be embedded in the certificate. This allows passive monitoring of TLS connections. This essentially disables forward secrecy.

RSA = Client will use server's public key to encrypt the PMS and send over to server, server will decrypt the PMS and generate the same PMS. The secret is sent in the wire

Exactly so.

Now, arriving at your question.

"RSA public key" in the certificate, for TLS-RSA, is used by the client to encrypt the PMS. It can be seen at "client key exchange" packet. Then What is its function in the case of TLS-ECDHE-RSA?

Now, this is easy to answer. When there is an explicit key exchange algorithm, the key in the certificate (RSA public key in this case) is only used for authentication. Making sure you connect to the host you intend to by validating the certificate chain and verifying that the server holds the private key for the given certificate's public one. It will also sign the DH-public key it sends to the client with its RSA private key, which the client verifies during the handshake.

Answer 2

"RSA" in the cipher suite refers to the random DH public key signature, but not the certificate signature

"RSA" refers to both DH key signature and server certificate's public key.

The keys used to sign/verify the DH public key come from certificate exchange, or we can't make sure we're using the actual public key of the server.

the certificate has an RSA signature (Sha256withRSAencryption)

As for the certificate's signature algorithm(Sha256withRSAencryption), it is up to the issuer of the server certificate and is used for verifying the server certificate. It doesn't take part in actual data exchange and is irrelevant here.

Then What is its function in the case of TLS-ECDHE-RSA?

As you've pointed out, "ECDHE" makes sure that the symmetric secret key isn't sent on the wire. So even if the server certificate's secret key compromises one day, the previously exchanged secret key won't be decrypted and the previously sent data will remain safe. It is known as "forward secrecy".

Answer 3

"RSA public key" in the certificate, for TLS-RSA, is used by the client to encrypt the PMS. It can be seen at the "client key exchange" packet. Then, what is its function in the case of TLS-ECDHE-RSA?

Short answer: in ECDHE-RSA, the RSA public key in the certificate is used to verify the RSA signature on the ephemeral ECDH public parameters that the server sends.

---

All Diffie-Hellman key exchanges are anonymous by default, meaning you have no information who you're exchanging keys with. This is obviously undesirable because a network attacker (with a man-in-the-middle position) could substitute their own key parameters for the ones each side (client and server) want to send the other. To avoid this, the server signs its key parameters with its private key. Specifically, it uses the private key which corresponds to the public key in the server's certificate. That way, the client has a public key, which it knows to belong to the server, and which it can then use to verify that the [EC]DH parameters the server sent over are the ones it received.