When we go to interact with things over the internet via HTTPS, a whole world of stuff goes on in the milliseconds before. So let's walk through this beginning to end. We won't get deep into definitions, basics behind public/private keys, or any of the mathematics behind encryptions. This is the whole thing from a 50,000 Ft view in 5 minutes. And it'll be from the RSA key exchange algorithm.

0. You go to an HTTPS website via your browser

Okay, no big deal here. Self explanatory. From this point forward we'll call the browser the "Client." That being said, the "Client" doesn't have to be a browser since you can obviously send requests beyond browsers.

1. The Client says "Hello"

Which is funny because it actually does this. Before anything else happens, the Client sends a set of things to the Server known as the Client Hello. What's in this set of things sent up to the Server we ultimately want to talk to via HTTPS?

• What type of TLS protocol the Client supports
• What cipher suites it supports
• A random string of bytes (AKA Client Random)

TLS is just the set of rules around encrypting the traffic. We ultimately want to send our HTTP traffic through the TLS layer where it's encrypted. So, in other words, the Internet Engineering Task Force came up with a set of rules that we should follow to make this stuff work. Our clients and servers using TLS follow these rules.

Cipher suites are just sets of encryption algorithms that can be used to ... well encrypt the various things we're sending to and fro. There's a number of them, and your browser / Client supports a variety. These suites are given names of things like TLS_RSA_WITH_AES_128_CBC_SHA.

The random string of bytes is for later use to create some temporary encryption keys that will be used to encrypt/decrypt traffic between the Client and Server. This consists of 4 bytes representing the time in UTC and 28 more that are random.

2. The Server says "Hello"

And again, it actually does say hello. It sends a message known as the Server Hello back to the Client. Well, eventually it does. But first it does some other things.

First, it looks at the three main things sent up in the Client Hello - the TLS protocols the Client supports, the cipher suites, and chooses the protocol and cipher suite it also supports. Which one gets picked is going to vary based on what the Server supports and what it's configured to prioritize and use.

Okay, and so now, the Server knows how all of this encrypted talking is going to happen. Now it's time for it to say "Hello" as well.

In its attempt to be friendly and reciprocate, it sends back to the Client the protocol and cipher suite that it will use. One that both it and the Client support. It also sends along the SSL Certificate and info about what authority issued it (i.e. VeriSign, DigiCert, AWS Certificate Manager).

The final thing it sends along in this warm greeting is yet another random string of bytes. This is, yet again, 4 bytes representing the Server's time in UTC and 28 more random bytes. Yes, it will also be used in our creation of some temporary encryption keys.

3. The Client Makes sure the SSL Certificate is Legitimate

Because it could be lying. And so it takes the SSL certificate sent down by the Server and checks with the authority. "Hey, is this real? Can I trust this certificate?" The authority will confirm or deny it.

5. The Client Gets the Public Key from the SSL Certificate

When you get an SSL Certificate, it has the public key with it. The Server has the private key.

Already you may be thinking, "Oh, so there we go, we're done." But nope. We want even more security. Even though, with those, we could do some basic encryption by encrypting our Client's data with the public key and then sending up to the Server, who should be the only one with the Private key that can decrypt this... we don't. We want even more security.

By the way, this pattern of Public/Private key encryption is known as Asymmetric Encryption. A fancy way of saying that we're using different keys to encrypt/decrypt stuff.

6. The Client Uses the Public Key to Make More Random Bytes

So, now that it has the SSL Certificate and the public key that came with it, it creates another round of random bytes using that key. How it generates those random bytes is based on what cipher suite the two of them agreed upon.

Since the Server is the only one with the private key, this works out and we can make sure that no one else can decrypt the Client's increased randomness.

Just so I don't have another unnecessary section - the Client sends this encrypted string of random bytes up to the Server. The Server is going to hold on to this.

This string of random bytes is known as the premaster secret. We've gone from saying hello to some illuminati language.

7. The Client and Server Make Session Keys

So, if you've been following along, we have 3 random strings of bytes in play:

• the Client random that the Client sent up in its hello
• the Server random that the Server replied with
• the premaster secret generated using the SSL Certificate's Public Key

With all 3 in hand, both the Client and Server use those 3 strings of random bytes, alongside their chosen cipher suite, to generate what's known as the Master Secret. Using this Master Secret they generate "Session Keys." Session keys are those temporary keys we talked about earlier. They're encryption keys that the two will use to actually send the traffic to and fro.

So both Client and Server go off and make these keys using the same info and same cipher suite. As you can guess the two should arrive at the same results.

8. The Client and Server Compare Session Keys

Both of them send a finished message to each other with the key they generated. All of them of them should be the same. There's actually 4 that they'll wind up making, 2 for encrypting/decrypting the communication and 2 for digitally signing the messages (AKA making sure the whole conversation is legitimate). So another layer of security here.

The keys for encrypting decrypting are called the Client Write Key and the Server Write Key.

The keys for signing any communication are called the Client Write MAC Key and the Server Write MAC Key. MAC meaning "Message Authentication Code." Basically, anytime either sends a message, after encrypted, it'll also sign it with the MAC key.

By the way, both the Client and Server have access to all 4 of these keys.

9. If the Session Keys Match, Game On

Now the Client and Server will use those new temporary, session keys to encrypt/decrypt their communication. And by temporary, I mean used once. So any other communication is going to need a new set of Session Keys. And they'll just follow what happened above to get them again.

By the way, since they're both using the same key, this is known as Symmetric Encryption. Yet another fancy way of saying, "We're both using the same keys."

Just to give a run down of those session keys, since there are 4...if a Client was sending a message to the Server via HTTPS and we've gotten all the way to this step...

1. The Client encrypts the message with the Client Write Key
2. The Client signs the message with the Client Write MAC Key
3. The Server gets the message
4. The Server checks the signature with the Client Write MAC Key
5. The Server decrypts the message with the Client Write Key

Well...what about the Server keys? Well those are used when the SERVER is sending stuff to the Client. In that case it would be:

1. The Server encrypts the message with the Server Write Key
2. The Server signs the message with the Server Write MAC Key
3. The Client gets the message
4. The Client checks the signature with the Server Write MAC Key
5. The Client decrypts the message with the Server Write Key

--

Alright, and there ya have it. Hopefully it took you about 10 minutes to read it, otherwise my title fails.