Understanding TLS Handshakes: RSA vs ECDHE and TLS 1.3 Explained

1. Introduction

HTTPS adds SSL/TLS between TCP and HTTP.

It solves the following HTTP problems:

Information encryption: communication cannot be intercepted.

Verification mechanism: tampering is detectable.

Identity certificates: trusted identification.

2. TLS 1.2 Handshake Process

In TLS, the basic unit is a record; multiple records can be combined into a single TCP packet.

2.1 RSA TLS Handshake

2.1.1 RSA Handshake Process Analysis

The diagram shows that each box is a record; the RSA handshake consists of four steps with a latency of 2 RTT.

Client initiates a TLS handshake request.

Server sends its public key (contained in the TLS certificate) to the client.

Client generates a key, encrypts it with the server’s public key, and sends it back.

Server decrypts with its private key to obtain the same key.

Afterward, the negotiated symmetric key is used for symmetric encryption of data.

Full handshake process is shown in the following diagram.

2.1.1.1 First TLS Handshake (RSA)

Client sends Client Hello with TLS version, supported cipher suites, and a random number A.

2.2.1.2 Second TLS Handshake (RSA)

Record 1: Server Hello

Server sends Server Hello with confirmed TLS version, cipher suite, and random number B.

Cipher suite format = key‑exchange algorithm + signature algorithm + WITH + symmetric encryption algorithm + hash algorithm.

Example: TLS_RSA_WITH_AES_128_GCM_SHA256 means RSA key exchange and signature, AES‑128‑GCM symmetric encryption, and SHA‑256 hash.

Record 2: Certificate

The record contains a digital certificate used by the client to verify the server’s identity.

Record 3: Server Hello Done

Indicates the end of the second handshake.

2.2.1.3 Client Certificate Verification

After receiving the certificate, the client verifies its trustworthiness before proceeding.

2.2.1.3.1 Digital Certificate and CA

A digital certificate is a signed document containing the entity’s public key and identity information, signed by a trusted Certificate Authority (CA).

Key components:

Public key.

Owner information (name, email, etc.).

Digital signature from the CA.

CA information for chain validation.

2.2.1.3.2 Certificate Issuance and Verification Process

Issuance: CA hashes the certificate data, encrypts the hash with its private key to create the signature, and attaches the signature to the certificate.

Verification: The client hashes the certificate data, decrypts the signature with the CA’s public key, and compares the two hashes.

2.2.1.3.3 Certificate Chain

When a leaf certificate is issued by an intermediate CA, the client retrieves the intermediate certificate, validates it against a trusted root CA, and then validates the leaf certificate.

证书链存在的原因:为了确保根证书的绝对安全性，将根证书隔离地越严格越好，如果根证书失守，那么整个信任链都有问题。

2.2.1.4 Third TLS Handshake (RSA)

After successful certificate verification, the client proceeds.

Record 1: Client Key Exchange

Client sends Client Key Exchange containing a new random number (pre‑master) encrypted with the server’s RSA public key.

Record 2: Change Cipher Spec

Both parties now share three random values (Client Random, Server Random, pre‑master) and derive the AES‑128‑GCM symmetric key. The client then sends Change Cipher Spec to inform the server to start using the symmetric key.

Record 3: Encrypted Handshake Message

Client sends Encrypted Handshake Message containing a hash of all previous handshake data, encrypted with the session key, allowing the server to verify integrity and that encryption works.

2.2.1.5 Fourth TLS Handshake (RSA)

Server sends Change Cipher Spec and Encrypted Handshake Message. If both sides verify successfully, the handshake is complete.

2.1.2 RSA Defects

RSA key exchange does not provide forward secrecy.

If the server’s private key is compromised, all previously captured TLS ciphertext can be decrypted.

2.2 ECDHE TLS Handshake

ECDHE provides forward secrecy and is widely used, while RSA is less common.

2.2.1 DH Algorithm

ECDHE evolves from DH; the core idea is the discrete logarithm problem.

2.2.1.1 Discrete Logarithm

Given base G and modulus P, the exponent x (logarithm) is easy to compute from y = G^x mod P, but recovering x from y is hard when P is a large prime.

2.2.1.2 DH Key Exchange

Assume Alice and Bob agree on P and G. Each generates a private key ( a and b) and computes a public key ( A = G^a mod P, B = G^b mod P). They exchange public keys and compute the shared secret K = B^a mod P = A^b mod P, which becomes the symmetric session key.

2.2.1.3 DHE Algorithm

DH can be implemented as static DH (deprecated) or DHE (ephemeral). Static DH uses a fixed private key on the server, making it vulnerable to long‑term key compromise. DHE generates a fresh private key for each session, providing forward secrecy.

2.2.2 ECDHE Algorithm

ECDHE builds on DHE using elliptic curve cryptography, offering faster key computation.

Both parties agree on an elliptic curve and base point G.

Each generates a private scalar d and computes the public point Q = d·G.

After exchanging public points, each computes d₁·Q₂ = d₂·Q₁; the x‑coordinate is the shared secret.

2.2.2 ECDHE TLS Handshake Process

2.2.2.1 First Handshake (ECDHE)

Client sends Client Hello with TLS version, supported cipher suites, and random number A (same as RSA).

2.2.2.2 Second Handshake (ECDHE)

Record 1: Server Hello

Server sends Server Hello with confirmed TLS version, cipher suite, and random number B.

Example cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 – key exchange ECDHE, signature RSA, symmetric AES‑256‑GCM, hash SHA‑384.

Record 2: Certificate

The certificate allows the client to verify the server’s identity.

Record 3: Server Key Exchange

Because the server chose ECDHE, it sends a Server Key Exchange message containing the chosen elliptic curve (e.g., x25519) and the server’s public key.

Selects curve x25519 (defines base point G).

Generates a random private key for the curve.

Computes the corresponding public key and sends it to the client.

Record 4: Server Hello Done

Marks the end of the second handshake.

2.2.2.3 Third Handshake (ECDHE)

Record 1: Client Key Exchange

After certificate verification, the client generates its own ephemeral private key, computes its public key, and sends a Client Key Exchange message.

Record 2: Change Cipher Spec

Both parties now have each other’s public keys, their own private keys, and the curve base point. They compute the shared point; the x‑coordinate becomes the pre‑master secret. The final session key is derived from Client Random + Server Random + x.

Both sides send Change Cipher Spec to start using the symmetric key.

Record 3: Encrypted Handshake Message

Client sends Encrypted Handshake Message containing a hash of all previous handshake data, encrypted with the newly derived session key, allowing the server to verify integrity and that encryption works.

2.2.2.4 Fourth Handshake (ECDHE)

Server sends Change Cipher Spec and Encrypted Handshake Message. If both sides verify successfully, the handshake is complete.

2.3 Comparison of RSA and ECDHE Handshakes

RSA does not provide forward secrecy; ECDHE does.

RSA requires four round‑trips before application data can be sent; ECDHE can send encrypted application data after the second round‑trip, saving one RTT.

ECDHE includes a Server Key Exchange message in the second handshake; RSA does not.

3. TLS 1.3 Handshake Process

TLS 1.3 establishes a connection with only 1 RTT; session resumption can be 0 RTT.

In TLS 1.3, most handshake messages are encrypted, and application data can be transmitted immediately after the handshake completes.