hpr-knowledge-base/hpr_transcripts/hpr2540.txt

Episode: 2540
Title: HPR2540: 28 - TLS 1.3
Source: https://hub.hackerpublicradio.org/ccdn.php?filename=/eps/hpr2540/hpr2540.mp3
Transcribed: 2025-10-19 05:09:13

---

This is HPR Episode 2540, titled 28, DLS 1.3, and is part of the series, privacy and security.
It is hosted by a huker, and is about 19 minutes long, and carries a clean flag.
The summer is DLS 1.3 is the newest protocol standard for secure communications on the web.
This episode of HPR is brought to you by archive.org.
Support universal access to all knowledge by heading over to archive.org forward slash donate.
Hello, this is a huker, welcoming you to Hacker Public Radio and another exciting episode.
I want to stay with our security and privacy series for at least one more episode here.
Something just happened that you may think I'm going to be talking about some of the vulnerabilities that have been revealed.
That's not actually what happened that I think is worth taking a look at is that there is a new standard on the internet for secure communications called the transport layer security protocol version 1.3.
Well, that's the full name. Generally speaking, we'd call it TLS 1.3.
So, what is this about? Well, back in the old days, and you may recall that we talked about some of this stuff in earlier episodes.
We had something called SSL, Secure Socket Slayer, which was developed by Netscape in 1995, which is sort of the Jurassic age in internet timing.
So, it's a very old protocol. This was a way to establish encrypted communication with a website using a certificate.
Now, one distinction that we want to make is that SSL and TLS are protocols, and you can use certificates with either of them.
The certificate part is not what's changing exactly, but in the ongoing arms race that is cryptography, the older SSL had started to show vulnerabilities.
Some of the things we've talked about, things like the Poodle Protocol Downgrade Attack, which was one of the reasons SSL was deprecated.
SSL 2.0 was deprecated in 2011. SSL 3.0 was deprecated in 2015.
And replacement for SSL is TLS, Transport Layer Security. You know, you want to call TLS the same as SSL 4.0. You could do that, but you know, we call it TLS now.
And the point is that when you're in a security arms race, you need to keep improving your defense.
So, TLS 1.3, just as I record this, just within the last few days has been adopted.
It required four years of meetings and 28 drafts. But in the end, the final draft was passed by the Internet Engineering Task Force with nearly unanimous support.
I believe there was one member who sort of voted present, but there were no negative votes. Now, as you might infer from the 28 drafts, there were issues to work through before this could be adopted.
Since this protocol governs the handshake process, between your browser and the remote server, all browsers and web servers had to be modified to employ the new process.
And this is not something that always goes smoothly. A good example of that is what we call the middle box problem. Now, what is that? Well, a middle box is any piece of hardware that inserts itself between the browser and the remote server.
Well, a good example of this is a firewall, which of necessity sits in the middle and inspects all traffic to protect the network from malicious traffic.
At the very least, such hardware will need to receive updates to employ the new protocol, which will cost money and effort.
In contrast, upgrading browsers was fairly simple, and it pretty much is completely done at this point.
Now, this whole process did cause a bit of bother, and you may have heard about this. There was a school system that had 50,000 Chromebooks, and found that many of them could no longer connect to the network after an upgrade Chrome conflicted with the network security software from Semantic Bluecoat.
This led Google to temporarily posits rollout, even though they say Semantic was really the one at fault here. But the biggest battle pitted the internet engineering task force against the financial services roundtable.
The roundtable suggested that a weakening of the standard would be really convenient since it would save them from the bother and expense of modifying their systems. They wanted an option to just decrypt any traffic.
This did not sit well with the internet engineering task force.
So, for instance, here's a quote, the banking industry is pushing the TLS working group to create a decryption option as part of the specification, and of course the tech sector is saying that's not going to happen.
Janet Jones, a Microsoft senior security program manager, told Cyberscope.
Can you imagine us supporting something that gave an API with a decrypt button? We can't do that.
Now, unfortunately for the banks, they were not paying attention earlier in the process and made their objection as the IETF was wrapping up their work.
I love this particular reply, someone from the financial group had written in saying, oh, could you make these changes?
A fellow named Kenny Patterson responded, hi, Andrew. My view concerning your request? No, rationale. We're trying to build a more secure internet.
Metal level comment. You're a bit late to the party. We are metaphorically speaking at the stage of emptying the ash trays and hunting for the not quite empty beer cans.
More exactly, we are at draft 15, and RSA key transport disappeared from the spec about a dozen drafts ago.
I know the banking industry is usually a bit slow off the mark, but this takes the biscuit. Cheers Kenny.
So what we're talking about here obviously is the old way of doing the handshake that decided is not going to work going forward.
And so using RSA key transport is out.
Now, the tech industry regarded this proposal from the big banks as essentially building in a back door.
And pointed out there are ways to accomplish what the banks want to do without weakening the TLS 1.3 standard.
For instance, anyone with traffic going through their network can use middle boxes to do man in the middle decryption.
This works by having the middle box create two encrypted tunnels, one to the browser, the other to the remote website, and then they can decrypt and inspect traffic all they want.
So in the end, the IETF voted not to adopt with the banks wanted and TLS 1.3 won't have this particular back door.
So we looked at some of those problems. Why are we doing this? What is it going to accomplish? Well, several things.
One is comes under the heading of latency. Now, latency is the amount of time it takes to handle the whole process of the handshake and agreeing on the encryption keys and all of this before you can actually start communicating.
So TLS 1.3 improves the efficiency and speed of connections by streamlining the handshake. Now, in TLS 1.2 there is a handshake process that is fairly complex.
In fact, we went over it in a previous episode when we were talking about forward secrecy. We took a look at that whole process.
But just to recap, so the web browser, the client sends a message to the server, offers a list of encryption protocols it can support.
The server then replies with a protocol it intends to use and sends an encryption key.
The client then uses that key to send back a random string, and then they create two keys, a master key and a weaker session key.
The client then says which protocol it will use for the weaker session key. Because this key is weaker, it is faster and less resource intensive.
The server acknowledges the session key and protocol, and finally they can start exchanging information. So a little bit complex kind of process here.
TLS 1.3 is much simpler. The client says hello and says which protocols it intends to use.
The server says cool, here's my key. The client says awesome, here's the session key. So as you can see, the handshake is markedly simpler to accomplish.
Now, you might say, wait a minute, why do we not have to negotiate to get the best possible encryption protocol? Well, that's another thing about TLS 1.3.
A lot of the older encryption protocols are not part of TLS 1.3. They just got rid of a whole bunch of them.
So, you know, if you get rid of the protocols that have a lot of known vulnerabilities, right away you're going to be more secure.
It also improves the resistance to downgrade attacks, which is the, referred to earlier, the poodle is a good example of that.
A downgrade attack happens when one of the parties in the handshake claims to not have any good protocols available and asks to use a weaker, more vulnerable protocol.
We saw this initially with SSL 3.0 and the move to TLS away from SSL reduced that.
But the bad guys are always looking for opportunities. So periodically, you do need to upgrade your defenses.
And a TLS 1.2, they did start finding some ways to force a protocol downgrade. So TLS 1.3 detects and flags any attempts to downgrade in addition to, of course, eliminating support for many of those weaker protocols.
Another major change is the move away from RSA for the handshake. And remember, above, we talked about getting rid of RSA key transport.
And instead, moving to ephemeral diffie helmet. Now, there's a few reasons that, but the key is that servers RSA key tends to be fixed for at least a significant period of time.
Which means that any compromise of that key could lead to decryption of previously stored communications.
Remember, we talked about that when we discussed forward secrecy.
So in the new protocol, the RSA key is only used for authentication.
The actual encryption keys are generated a new each session using diffie helmet, which gives us the forward secrecy that we talked about.
So ephemeral diffie helmet means you're using the diffie helmet method to create a shared key.
And ephemeral means a key is only used for one session. And you have to start with a new key every time you have a new session. And that's how you get the forward secrecy.
Now, that said, improve security is not perfect security. The nature of the cryptographic arms race is such that every improvement in defense is met by an improvement in offense.
As we saw, it is still possible to have a man in the middle attack if you are not careful about managing your authentication.
The RSA key is supposed to be doing that. But, you know, if there is a man in the middle and that can be hostile or it can be legitimate, depending on the case.
Now, I'm just familiar with how things are in my country, the United States.
But my understanding is that the courts in this country have ruled that if you're on a corporate network, the company has every legitimate right to defend its network by putting a box in the middle.
And that's where the firewall comes in.
And so that firewall will basically do a man in the middle attack. And if you're not paying attention, you might not know that that's going on.
Now, you would know if you were very careful in your browser to actually inspect the certificates you get every time you attempt to connect.
What you often find in corporate networks is that, you know, when they build the machine and put the operating system image on it, they put in the certificate and add it to the trusted certificate list at the time the machine is created that says, you know, my machine will always trust my employer's certificate.
And so, you know, you might not even realize that that's what's going on.
But if you check your certificates each time, you would see that because there's no way for them to spoof who the certificate is.
Now, another potential issue.
There's something called zero dash RTT resumption.
Now, this is really an example of the trade off or the conflict, if you like, between security and ease of use.
So what this does, it essentially allows the client and the server to remember a connection and resume it.
You might look at that and say, well, wait a minute.
What's all this about ephemeral Diffie helmet and a new key for each session? Yeah.
Well, this does add a vulnerability, you know, defined session is a session between times you've rebooted your computer or is it just each time you've happened to connect to a particular site.
So this is a little bit controversial having that in there. We're going to watch that.
Now, how far has deployment happened? This standard was just approved and adopted by IETF.
So it's not on 100% of sites. And one of the things we're going to be looking at with servers, for instance, that zero dash RTT resumption process that requires changes that are, in many cases, not compatible with older servers.
The move to ephemeral Diffie helmet also poses problems, particularly for data centers.
You know, if they have network monitoring tools such as intrusion detectives detection systems that passively monitor TLS connections, they cannot at present work with ephemeral cipher suites.
This was one of the issues behind the objections made by the big banks.
So we're going to have to see how this plays out.
The other thing is this is not the last word.
Arms race. I keep saying this because you have to have the right mindset about these things.
There's no such thing as 100% perfect bulletproof security, set it, forget it, and everything will be wonderful.
We don't live in that kind of world. We don't have that.
What we have is a system where we discover attacks all the time, and periodically, as a result of those attacks, we change our methods to guard against them.
And then new attacks happen.
So what you really need to do is stay on top of this, and I always recommend people find there are a few places you can stay on top of things.
If you're into podcasts, and if you're listening to hacker public radio, I kind of think you probably are into podcasts.
Steve Gibson's security now is a pretty good place.
Sophos security has a podcast, and there are others.
There are blogs, you know, I am subscribed to Bruce Schneier's blog, Matthew Green's blog, things like that.
So these are things that you can take a look at.
And just stay on top of things. But this is the skinny as far as I understand it right now about the new TLS 1.3.
And so with that, this is Ahuka for hacker public radio, signing off, and reminding you as always to support free software.
Bye bye.
You've been listening to hacker public radio at hackerpublicradio.org.
We are a community podcast network that releases shows every weekday, Monday through Friday.
Today's show, like all our shows, was contributed by an HBR listener like yourself.
If you ever thought of recording a podcast, then click on our contributing to find out how easy it really is.
Hacker Public Radio was founded by the digital dog pound and the Infonomicon Computer Club, and is part of the binary revolution at binrev.com.
If you have comments on today's show, please email the host directly, leave a comment on the website or record a follow-up episode yourself.
Unless otherwise status, today's show is released on the creative comments, attribution, share a life, free.or license.
You