A client securely connects to a web server via the TLS 1.2 transport encryption protocol. This is a process that starts with asymmetric cryptography and ends with symmetric cryptography. As a refresher, recall that asymmetric cryptography uses a public and private key pair, whereas symmetric cryptography uses only one shared key.

I published a blog post several months ago illustrating a simplified step-by-step process of how https and the TLS handshake typically work. BUT! There is an alternative approach that uses a key agreement protocol called Diffie-Hellman Ephemeral (DHE). This is a process of creating a secret key in plainsight using modular arithmetic.

---

I’ve come to find that there doesn’t appear to be an agreed upon consensus for this process. Different sources describe their own rendition of DHE in the TLS handshake process. All the interpretations I’ve researched have slight deviations in their models, so if I’m wrong about this, I’m sorry! I would definitely invite you to research this topic further on your own.

---

Step 1: ClientHello

During the initial ClientHello message to the web server, the client sends a ClientRandom, which is a cryptographically-generated pseudorandom number (or “nonce”).

Just like the usual ClientHello, the client also provides a list of available cipher suites that it can perform. Cipher suites are just combinations of encryption algorithms and protocols that are responsible for providing encryption, authentication, and integrity.

Inside the ClientHello message, the client also requests to see the Web server’s X.509-compliant digital certificate. Certificates are issued by trusted Certificate Authorities (CAs), which manage, validate, and revoke certificates. Certificates may also be self-signed if it’s using a Web of Trust. Certificates come with useful information, such as:

• The Serial Number that uniquely identifies the certificate. This number can be used to reveal if the certificate is on a Certificate Revocation List.
• The Issuer, which is the Certificate Authority, e.g., VeriSign.
• The Validity Dates, meaning dates in which the certificate is “valid to” and “valid from.”
• The Subject, which is the owner of the certificate, usually identified with an email or domain name.
• And, the Public Key used for asymmetric encryption. (Note: the private key will NOT be on the certificate).

The important thing to remember is that the certificate contains the RSA public key of the server. It is available to any client that wishes to securely connect to the server. However, only the server knows the RSA private key. If public keys encrypt information, then only the private key can decrypt it. Here is an example of what a certificate might look like:

You can even look up the certificates yourself by clicking the “lock” icon on the url bar next to “https://.” See for yourself.

Step 2: ServerHello

In the ServerHello message, the server replies with its own ServerRandom, which is also a cryptographically-generated pseudorandom number (or “nonce”).

The server sends the client a DH parameter (I will explain what this is in step 4).

The server looks through the list of cipher suites provided in the ClientHello message and chooses the strongest cipher suite both parties can perform. For illustrative purposes, let’s say that the cipher suite just happens to be TLS_DHE_RSA_WITH_AES_256_CBC_SHA. This means that the client and the server will use the TLS transport encryption protocol alongside the Diffie-Hellman Ephemeral (DHE) key agreement protocol. The authentication method will use Rivest, Shamir, and Adelman (RSA). This will be used in conjunction with the Advanced Encryption Standard (AES) symmetric encryption algorithm with a 256-bit key and a SHA-256 hashing algorithm to maintain data integrity during the transfer of information.

Before continuing to step 3, the server encrypts a hash of its digital signature with its RSA private key and sends this to the client as well.

Step 3: Client Responds to ServerHello

The client receives the web server’s certificate and it checks to ensure that it is not expired. The client will also query the CA to request a copy of the “Certificate Revocation List (CRL).” This ensures that the certificate hasn’t been revoked for any reason, such as a key compromise, certificate hold, expiration date, and anything else that might make the certificate invalid. Let’s assume that the certificate is valid.

The client also verifies the digital signature by decrypting the SHA-256 hash with the public key and then hashes it again to see if both hashes match.

Likewise, the client also sends its own DH parameter.

Step 4: Key Derivation

The client and server must agree on a shared pre-master secret (K) before they can send encrypted messages to each other. This can be accomplished using a Key Agreement Protocol called Diffie-Hellman Ephemeral (DHE). The process of DHE involves a lot of modular arithmetic (x mod p). Fetchingly, DHE already began in steps 2 an 3 when the server and client sent their DH parameter.

To obtain the value of X, the server picks a generator (g) and a prime modulus (p). Let’s say the server picks g = 3 and p = 17 and sends it to the client. The server picks a secret number (x) and calculates g^x mod p = X, where X = server’s DH parameter. Note: the client or an eavesdropper do not know the value of x. If x = 54, then the calculation for X  is 3^54 mod 17 = 15. This answer is sent to the client in plaintext. 

To obtain the value of Y, the client will respond using the same g and p. The client also picks a secret number (y) and calculates g^y mod p = Y, where Y = Client’s DH parameter. Note: the server or an eavesdropper do not know the value of y. If y =24, then the calculation for Y is 3^24 mod 17 = 16. This answer is sent to the server in plaintext.

The server can compute  K = Y^x mod p and the client can compute K = X^y mod p. These calculations give us:

Server: g^(yx) mod p = K, which is  3^(24 x 54) mod 17 = 1

This is the same as:

Client: g^(yx) mod p = K, which is 3^(54 x 24) mod 17 = 1

Therefore, using DHE, the client and the server can create a pre-master secret together (K = 1). An eavesdropper cannot know K unless he knows x and y. Calculating K is computationally difficult for larger numbers.

K can then be fed through an HMAC-based Extract-and-Expand Key Derivation Function (HKDF) to create ephemeral cryptographically secure session keys.

Step 5 and 6: Finish

Once a master secret is created, the client sends a ClientFinish and then the server responds with a ServerFinish. At this point, asymmetric cryptography stops and symmetric cryptography can take over because both the client and server know K. Now, application data can be transmitted back and forth securely via a separate symmetric encryption channel. Additional session keys can be derived from K. If we take a step back, here is an overview of what the whole process looks like:

Conclusion

To reiterate, many of the sources I used had slight variations in their interpretation of DHE in the TLS handshake process. So, I chose a couple sources that either had more detail or made sense to me. The big takeaway from this process is that DHE allows the client and the server to agree on a secret key by communicating over an insecure channel, which is pretty amazing.

 

References

Fischlin, M., Lehman, A., Wagner, D. (2010). Hash Function Combiners in TLS and SSL. ResearchGate. Retrieved from https://pdfs.semanticscholar.org/8225/1dd1310ec42e5a89967dce434874cd10f15e.pdf

Goodrich, M. T., & Tamassia, R. (2011) Introduction to Computer Security. Boston, MA: Pearson Education, Inc.