Podcast
Root Causes 430: How Does a TLS Handshake Work?
In this episode we give a high level explanation of what happens in a TLS 1.3 handshake and then discuss what will happen when PQC is included.
Podcast Transcript
Tim CallanSo Jason, let's talk about TLS 1.3.
Jason SorokoDoes everybody know what that is? I bet you use it every day.Tim CallanProbably.Jason SorokoAnd you'd never think about it.Tim CallanCompletely invisible.Jason SorokoSo this is a fun episode where we're gonna take the most in the weeds, esoteric thing. It's only understood by, really, truly understood, by a few number of people. Thank God that somebody does. And try to oversimplify it to the point where I think anybody can explain it.We tried to do this a few times. One of the most recent ones was we tried to explain lattice mathematics. And let me try and tell you what we try to do with these podcasts, which is, I oversimplify to the point where I know that the tech people who really understand it are going to throw stones at me because they're like, that's partly wrong. I want to take the pedantic out of it, because I want people to understand what's really going on, and there's a purpose to understanding it, and that's what we'll get to at the end of this, Tim.
So the TLS 1.3 handshake is what happens when you go to www.timswebsite.com and Tim’s website.com is being served by a web server and your web browser are making a handshake. And if there is an SSL certificate, a TLS certificate, that is actually being used to encrypt the communication between the web server and web browser, there initially has to be a handshake between the browser and the server, and these are two parties that do not know each other from beans. You're going over the hostile internet.
And a miracle happens, an encrypted session happens between the web server and the browser, and you don't think about it, and that's a good thing. It's good that you are browsing for your news and doing your banking and whatever you're doing on your browsing, and you're able to do this over the hostile internet. It's a real miracle.
But this TLS 1.3 handshake, TLS 1.3 added some defaults, Tim, that were really important that I think people need to know about. But let's talk about what occurs in the handshake. And the very first thing is the browser makes the initiation. The browser actually goes off and says to the web server, the address to that web server has been resolved. You go to paypal.com. Well, paypal.com actually translates into a DNS. And then there is a client hello that is sent over to the web server. And so that client hello actually comes along with some things, and that is a random number and a cipher suite menu.
So in other words, the browser says to the web server, hey, I'm capable of receiving a public key that has been generated with RSA or ECC, as an example. And of course, if this is an ongoing session, the pre-shared key will be included in the client hello. But we're talking about you've never talked to this website before. And so that client hello is a random number and a menu of your cipher suite that is available. Interesting. The reason I mentioned that cipher suite is what happens in post-quantum. Your cipher suite is gonna be a lot more exotic than it is today.
So, number two, the server now chimes in, and the server actually chooses its own random number, sends that to the client, and then also makes a cipher suite choice. It's the server that says RSA or ECC, because it's the server who's actually gonna, in this next step, send the browser the public key.
Tim CallanGot it. So it's going to pick the suite.Jason SorokoSo now you know what happens next, which is the client receives the public key and has to do some work with it. And you are an industry expert in what happens next. Which is the browser looks in the trust store and says, hey, does this chain up to trust to a certificate authority?That occurs. Now, the one thing that is also sent is if the public cert happens to be elliptic curve based, ECC, then some parameters around how to deal with ECC are also sent. Because, in other words, there are many kinds of elliptic curves. Which ones are we using in this particular public cert? So that's also sent. So the public cert is sent, and the parameters, if it's ECC, is also sent. The client then takes that public certificate, and if it chains up to a certificate that's in its trust store, then it knows, okay, I'm dealing with a trusted, valid, publicly trusted certificate, and we can start to really, truly, begin to do the next set of steps. So is it the public key that actually is then encrypting the communication? It's not, Tim.
Tim CallanCorrect.Jason SorokoSo what we're dealing with now is the client after it evaluates the certificate, actually creates a pre-master secret, which is just another random number. This is the problem. Whenever you're reading about these TLS handshakes, they get rarely into what that means and how it is used in the generation of the session key and all this stuff. And to me, it's like, that's all important, but it's not important to the person who's trying to understand how their browser works. So I'm leaving it out.And then what happens is that pre-master secret, which is generated by the client, is encrypted by the public key that came from the web server.
And then really what happens - the final step - is the key generation occurs. And this key generation is the key pair that will be involved with the actual encrypted communications. But here's the miracle, Tim. This key generation happens on both the web server and the client side, and both the client and server independently come up with a key pair that is the same. How in the world could it be the same? And it's because of these random numbers that were done in step one and two.
Tim CallanGotcha. They both now know the same set of numbers and because they know the same set of numbers, they can follow the same process to generate the same end result.Jason SorokoYou got it. And so this pre-master key, basically that is encrypted with the public key, the server now knows okay, this is all based on something you generated, something I know I generated, and we've shared it with each other, but now with this public key that I've given to you, and now you've given it back to me, I now know you're in position of them. It's not a miracle when you look at the math and the process, but it's a miracle.Tim CallanAnd this is one of the things I thought was really elegant when I first learned about key exchange, is that because when you send a secret to somebody else using the key they gave you, and then when they send the secret back to you, that means that they have proven their identity, because otherwise they would not be able to know the secret you sent them, and then you can confirm that that matches the secret you get back and the only way that's possible is if the person who received that secret is the person they're supposed to be. And I remember the light bulb going on when I first learned about this long ago, and I thought that's so elegant.Jason SorokoIt is. It is. And therefore, it's this thing that just, it just happens. Nobody thinks about it. And part of the reason why I wanted to bring it up today, Tim, is exactly what you just said. It's kind of beautiful. It’s not a miracle. It's kind of a miracle.Tim CallanIt is beautiful. It is elegant in a certain way. It's so, first of all, just so efficient, and it's so marvelous in its reuse of existing information.Jason SorokoYou got it. What are some takeaways? So what? So it's Jay and Tim.Tim CallanJay and Tim are nerds. What else?Jason SorokoJay and Tim are nerds. They think this thing is beautiful. I'm already asleep and I've tuned to some other podcast. Here's the takeaway. Forward secrecy.I don't think people realize that the public cert, which is something that the web server had to do a lot of work with a CA to get and to get into that root store ultimately, and do that chain of trust all the way up, is not what is doing the encryption of the communication. It’s the session keys that are generated independently and identically on both sides.
And the beauty of having fresh session keys every session is that you get, you get the advantage of forward secrecy. So you just made one of the really good points. This happens so fast that that's why you don't think about it.
Number two, forward secrecy is awesome, because if your communication is being recorded, there's nothing stopping a bad guy from being right in the middle of recording this encrypted session, but until quantum computers come around, it's going to be awfully difficult to decrypt this encrypted session. The beauty is, is that these session keys are what is enabling a fresh set of encryption. So if one of the private keys of that gets compromised, then only one session will be decrypted. Let's say you and I had a permanent set of keys that we always encrypted with.
Tim CallanAlways used. Like an old timey code. Then, under those circumstances, if someone got into it, they could just keep eavesdropping on our conversations indefinitely.Jason SorokoExactly. Bad. So it's like rolling the tumbler on the lock every time you make a new communication. That's tough to break. But now let's go back to what you just said though about efficiency. This all is incredibly efficient because of the small key length sizes of RSA and ECC. What happens when you go to quantum?Tim CallanEverything gets bigger. There's not a single either chosen algorithm or candidate algorithm that does not have a very material performative cost in one form or another.Jason SorokoYou got it. So I would say, Tim, for those of you who are keeping score here, forward secrecy does not mean you have defeated the harvest and decrypt problem, because the harvest and decrypt problem is a problem of quantum computers with Shor's algorithm and other algorithms being able to defeat classically encrypted communication. Therefore, even if you're rolling the tumbler per session that's not giving you forward secrecy with classic algorithms does not give you harvest and decrypt mitigation.Tim CallanCorrect.Jason SorokoAnd I’ve heard people say that it did, and I just wanted to correct them on this podcast. That's part of the reason for this podcast. Second reason is what we just said, which is, for those of you keeping score, everything we just said is in the classic sense, and everything just works, tickety boo, and is a an elegant thing because of the simplicity and the efficiency of RSA and ECC. Everything changes in quantum. There you go, Tim.Tim CallanThere you go.Jason SorokoWe actually explained TLS 1.3 on camera.Tim CallanOn camera and fit in quantum computing, and left it on a downer note. Perfect.Jason SorokoWe always do that.Tim CallanAll right. Thank you much, Jay.Jason SorokoThanks, Tim.Tim CallanThis has been Root Causes.Stay informed with expert insights
Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!
