On this page On this page
Episode 33 – Protocol Shorts: TLS Encrypted Client Hello.
This episode explores TLS Encrypted Client Hello (ECH) and how it improves privacy on the internet by hiding sensitive metadata that was previously exposed during the TLS handshake. While traditional TLS encrypts the actual data exchanged between client and server, key details like the Server Name Indication (SNI), which reveals the website you are visiting, remained visible to intermediaries such as ISPs or network middleboxes.
Glen explains how ECH addresses this gap by encrypting most of the Client Hello message using keys obtained via secure DNS, preventing third parties from easily identifying user activity. The discussion also covers real-world implications, including the impact on network infrastructure that relies on traffic inspection and the role of cloud providers in TLS termination.
Rama
If you like this podcast you might also like our modular network framework in Rust: https://ramaproxy.org
00:00 Intro00:27 Understanding the TLS Handshake Process06:54 Understanding Middle Boxes and Network Behavior08:33 The Privacy Gap in Network Traffic14:08 Current Usage and Future of ECH18:00 Consequences of ECH for Existing Infrastructures24:19 Future of ECH: Privacy vs. Trust26:32 OutroNetstack.FM
More information: https://netstack.fm/#episode-33
Join our Discord: https://discord.gg/29EetaSYCD
Reach out to us: hello@netstack.fm
Music for this episode was composed by Dj Mailbox. Listen to his music at https://on.soundcloud.com/4MRyPSNj8FZoVGpytj .
Elizabeth (Plabayo)
0:17 | 🔗
Welcome to netstack.fm, episode 33, recorded on the 31st March, 2026. Our protocol shorts. Today, we are talking with Glen about TLS encrypted client Hello, which I understand it's about hiding which websites you are visiting, not just the data itself. Can you, Glen, walk us through into why that matters? we are talking with Glen about DLS encrypted client hello Which I understand it's about hiding which websites you are visiting not just the data itself Can you Glen walk us through into why that matters? Yeah, sure, Elizabeth. So TLS is all about encrypting the traffic and most people know it with the padlock in their browser. it adds encryption to your web traffic. Elizabeth (Plabayo)
0:48 | 🔗
Yeah, sure, Elizabeth. So TLS is all about encrypting the traffic and most people know it with the backlog in their browser. It adds encryption to your web traffic and allowing you to visit a website without anybody snooping on what you're doing. This is especially information when you are dealing with sensitive information such as payment flows Elizabeth (Plabayo)
1:00 | 🔗
and allows you to visit the website without anybody snooping on what you're doing. This is especially information when you're dealing with testing information such as payment flows. or personal information or anything else. Or it also ensures that you can trust the data you are receiving back is actually coming from the server you're expecting to. So far, Elizabeth (Plabayo)
1:10 | 🔗
personal information or anything else or it also ensures that you can trust the data you are receiving back is actually coming from the server you're expecting to. So far When we were talking about TLS or when we were dealing with TLS, we were only dealing with encrypting the web traffic itself or the application data, such as the HTML or the CSS pages or JavaScript or whatever you are sending back and forth between client and server. What we were not yet encrypting, and for the most part still are not, are the parameters that we are negotiating in the handshake phase of the protocol. Elizabeth (Plabayo)
1:23 | 🔗
When we were talking about TLS or when we were dealing with TLS, we were only dealing with encrypting the web traffic itself for the application data, such as the HTML or the CSS pages or JavaScript or whatever you are sending back and forth between client and server. What we were not yet encrypting, and for the most part still are not, are the parameters that we are negotiating in the handshake phase of the protocol. part of this information includes sensitive information such as the server name indication which is basically the domain of the website that you visiting as well as the application layer protocol such as HTTP2 or HTTP1 that you are using to visit the website. of this information includes sensitive information such as the server name indication which is basically the domain of the website that you are visiting as well as the application layer protocol such as HTTP 2 or HTTP 1 that you are using to visit the website. This information was so far in the clear and could be used by any party that can see your traffic, including all the middleboxes and routers your traffic is going through. Elizabeth (Plabayo)
2:06 | 🔗
This information was so far in the clear and could be used by any party that can see your traffic, including all the middleboxes and routers your traffic is going Before we go deeper, can you give us a quick refresher on how a TLS handshake actually works? And what point does in that process? Elizabeth (Plabayo)
2:18 | 🔗
Before we go deeper, can you give us a quick refresher on how a TLS handshake actually at what point does start in that process? Yeah, of course, sounds like a good idea. Now, an entire discussion or a complete explanation on how TLS works is a bit out of scope for this podcast episode because it would take too long. But I will try to highlight the relevant parts. Elizabeth (Plabayo)
2:31 | 🔗
Yeah, of course. Sounds like a idea. Now, an entire discussion or a complete explanation on how TLS works is a bit out of scope for this podcast episode because it would take too long. But I will try to highlight the relevant parts. So like any protocol, we first need to negotiate. This is because protocols can have different versions, but also most protocols allow configurations and these configurations need to be negotiated because if the client and server are using Inco Elizabeth (Plabayo)
2:46 | 🔗
So like any protocol, we first need to negotiate. This is because protocols can have different versions, but also most protocols allow configurations and these configurations need to be negotiated because if the client and server are using incompatible configurations that wouldn't work. Elizabeth (Plabayo)
3:02 | 🔗
configurations, that wouldn't work. So as with most client server protocols, it is the client that will initiate the handshake, just like it was also the client initiating the connection. It will send over to the server what is called the client hello. This includes all the parameters that are configured by the client for this TLS connection. It includes things like its version, things like which encryption algorithms it speaks, things like... Elizabeth (Plabayo)
3:04 | 🔗
So as with most client server protocols, it is the client that will initiate the handshake, just like it was also the client initiating the connection. It will send over to the server what is called the client hello. This includes all the parameters that are configured by the client for this TLS connection. It includes things like its version, things like which encryption algorithms it speaks, things like Did we have a connection before and can we speed up the process by sharing already the Elizabeth (Plabayo)
3:29 | 🔗
did we have a connection before and can we speed up the process by sharing or editing the secret that we negotiated before but especially it also includes things like which application layer protocols do I speak such as HTTP 2 and also the server name indication which is basically the domain of the server it wants to reach. secret that we negotiated before? But especially it also includes things like which application layer protocols do I speak, such as HTTP2, and also the server name indication, which is basically the domain of the server it wants to reach. This information is important because quite often you have a gateway which is doing the TLS encryption and decryption and it is only like some kind of backend server behind the gateway which is then dealing with the actual HTTP protocol itself. Meaning the gateway will serve web traffic for many different web servers. ⁓ Elizabeth (Plabayo)
3:50 | 🔗
This information is important because quite often you have a gateway which is doing the TLS encryption and decryption and it is only like some kind of backend server behind the gateway which is then dealing with the actual HTTP protocol itself. Meaning the gateway will serve web traffic for many different web servers. Okay, So the server name indication is very important for that. So we are at the point that the client sends all the information to the server. The server will see this and see if the client hello config is compatible with how it operates. If it is, including if it knows the destination that is targeted using the server name indication. And if it knows that that web server can handle that protocol version, such as HTTP2. Elizabeth (Plabayo)
4:12 | 🔗
so the server name indication is very important for that. So we are at the point that the client sends all the information to the server. The server will see this and see if the client hello config is compatible with how it operates. If it is, including if it knows the destination that is targeted using the server name indication and if it knows that that web server can handle that protocol version, such as HTTP2, it will then send back the server hello. It will then send back the server Elizabeth (Plabayo)
4:42 | 🔗
basically just the information agreed upon on the client hello and the server, like which parameters do they agree on. It will send it back to the client together with its certificate which is the public key of the TLS server and then it will enter this with the server hello done. which is basically just the information agreed upon on the client hello and the server, like which parameters do they agree on. It will send this back to the client together with its certificate, which is the public key of the TLS server. And then it will end this with a server hello done. The client will receive this and at this point, Elizabeth (Plabayo)
5:02 | 🔗
The client will receive this and at that point It will use that public key of the server, the certificate, to check, do I trust that? It can go up to the chain and whatever thing that signs that key or whatever thing that sign as a certificate, it needs to trust it, which is usually in a trust chain on its browser or its operating system. Elizabeth (Plabayo)
5:05 | 🔗
it will use that public key of the server, the certificate, to check, do I trust that? It can go up to the chain and whatever thing that signs that key or whatever thing that sign a certificate, it needs to trust it, which is usually in a trust chain, its browser, on its operating system. Nowadays a lot of web traffic is using certificates signed by Let's Encrypt, which made Nowadays, a lot of web traffic is using certificates signed by Let's Encrypt, which made... Elizabeth (Plabayo)
5:32 | 🔗
certificate signing free. Before that, companies had to pay money every year, just like companies pay money for domains. But thanks to initiatives like Let's Encrypt, now we can all get free TLS certificates. But anyway, it doesn't really matter for this conversation. What matters is... certificate signing free. Before that, companies had to pay money every year, just like companies pay money for domains. But thanks to initiatives like Let's Encrypt, now we can all get free TLS certificates. But anyway, it doesn't really matter for this conversation. What matters is the client is validating the certificate and trusts it, it will use that to negotiate with the server. Elizabeth (Plabayo)
5:50 | 🔗
the client is validating the certificate and trusts it, it will use that to negotiate with the server on the private key used for the actual encryption of the web traffic because public and private key encryption is very expensive. And so we want to get to a point where we just use regular encryption, meaning the encryption and decryption is done using the same key. And so this is negotiated using public information on the private key used for the actual encryption of the web traffic because public and private key encryption is very expensive and so we want to get to a point where we just use regular encryption meaning the encryption and decryption is done using the same key and so this is negotiated using public information between Elizabeth (Plabayo)
6:19 | 🔗
between the client and the server. the client and the server. Elizabeth (Plabayo)
6:21 | 🔗
And so once this final negotiation is finished, we have established between the client and the server, not only the configuration used, but also shared secret that will used to encrypt the actual traffic. And at that point, And so once this final negotiation is finished, we have established between the client and the server, not only the configuration used, but also the shared secret that we'll use to encrypt the actual traffic. And at that point, Elizabeth (Plabayo)
6:34 | 🔗
everything else is encrypted and if you would like inspect this web traffic using a tool like everything else is encrypted. And if you would like inspect this web traffic using a tool like Wireshark. you will just see segments labeled as application data, but the content you will no longer be able to understand because you don't own the private key or either the server or the client. Elizabeth (Plabayo)
6:42 | 🔗
you will just see labeled as application data but the content you will no longer be able to understand because you don't own the private key or either the server or the client. Elizabeth (Plabayo)
6:54 | 🔗
So if I understand well, middle boxes can see the server name indication. So if I understand well, middle boxes can see the server name indication. And does this affect how networks behave? Elizabeth (Plabayo)
7:01 | 🔗
And does this affect how networks behave? So, In a perfect world, wouldn't matter at all because in a perfect world, these middle boxes, let's say the middle boxes operated by telecom providers or whoever is helping us to operate the internet would not really check at all what is being trafficked over TCP. All they would need to know Elizabeth (Plabayo)
7:07 | 🔗
in a perfect world it wouldn't matter at all. Because in a perfect world these middle boxes, let's say the middle boxes operated by telecom providers or whoever is helping us to operate the internet, would not really check at all what is being trafficked over TCP. All they would need to know... is what is the destination IP and they would do the routing and it will end up in this destination. However, we know that they do check on things they sometimes shouldn't check. For example, they Elizabeth (Plabayo)
7:26 | 🔗
is what is the destination IP and they will do the routing and it will end up in this destination. However, we know that they do check on things they sometimes shouldn't check. For example, they check sometimes what TCP port they have to use and then they might filter out or drop traffic that they don't want to. Elizabeth (Plabayo)
7:37 | 🔗
check sometimes what TCP port they have to use and then they might filter out or drop traffic that they don't want to. Or they might accept TCP but they don't accept UDP. Similarly, and I don't know why, it could be all kinds of reasons, they might wish to drop your traffic in case they see it's traffic destined for a website they don't support. Elizabeth (Plabayo)
7:43 | 🔗
or they might accept TCP but they don't accept UDP. Similarly, and I don't know why, it could be all kinds of reasons, they might wish to drop your traffic in case they see it's traffic destined for a website they don't support. For example, maybe a government decides that a certain chat platform is not allowed and so they might drop all traffic destined for server. For example, maybe a government decides that a certain chat platform is not allowed and so they might drop all traffic destined for that server. Or maybe they want to see, let's say they are a telecom provider, maybe they want to see what kind of websites are my clients using because then they could try to bundle this in all kinds of products. Elizabeth (Plabayo)
8:07 | 🔗
Or maybe they want to see, let's say they are a telecom provider, maybe they want to what kind of websites are my clients using because then they could try to bundle this in all kinds of products. mostly not so much is it a network issue, it's mostly a matter of privacy. If that makes sense to you, Elizabeth. Elizabeth (Plabayo)
8:20 | 🔗
mostly not so much is it a network issue, it's mostly a matter of If that makes sense to you This seems like a privacy gap. And have people been trying to solve this a while? Elizabeth (Plabayo)
8:26 | 🔗
Yeah, this seems like a privacy gap. Have people been trying to solve a while? For a while, yes, definitely several years and I imagine that behind closed doors people have been thinking about it for much longer. What I know is that since around 2018... Elizabeth (Plabayo)
8:35 | 🔗
Yes, definitely several years and I imagine that behind closed doors people have been thinking about it for much What I know is that since around 2018 Companies like Cloudflare and the IETF, Elizabeth (Plabayo)
8:46 | 🔗
companies like Cloudflare and started to experiment with something that is called encrypting the server name indication, meaning they introduced a new extension that could be added to the client hello, where they send the server name indication, but in an encrypted format. And the way it would work is that they could check the text DNS records of that same website where the public key was advertised that to experiment with something that is called encrypting the server name indication, meaning they introduced a new extension that could be added to the client hello, where they send the server name indication but in an encrypted format. And the way it would work is that they could check the text DNS records of that same website, where the public key was advertised that Elizabeth (Plabayo)
9:14 | 🔗
they could use to encrypt the server name indication. would use to encrypt the server name indication. Elizabeth (Plabayo)
9:18 | 🔗
So they would use public key found in the text DNS records, encrypt the server name indication and give it together with the client hello as a new extension for server name indication with an encrypted format. And this kind of worked. So they would use that public key found in the text DNS records, encrypt the server name indication and give it together with the client hello as a new extension for a server name indication with an encrypted format. And this kind of worked. but they had some issues and on top of that, it was only covering the server name indication. But that's more or less the first public research and attempt by companies such as Cloudflare. Elizabeth (Plabayo)
9:35 | 🔗
but they had some issues and on top of that it was only covering the server name indication. But that's more or less the first public research and attempt tried by companies such as Cloudflare. So how does ECH actually fix Elizabeth (Plabayo)
9:49 | 🔗
So how does ECH actually fix this privacy gap? Well, similar to the first attempt where they were encrypting the server name indication, the goal is to encrypt most of the client's hello. That would leave your actual client hello rather small. You would still include some information that doesn't really matter, but most of the other parameters you want to put in a similar kind of records. Elizabeth (Plabayo)
9:53 | 🔗
privacy gap? Well, similar to the first attempt where they were encrypting the server name indication, the goal is to encrypt most of the client hello. That would leave your actual client hello rather small. You would still include some information that doesn't really matter. but most of the other parameters you want to put in a similar kind of records and have it also encrypted and send that to the server. and have it also encrypted and send that to the server. And similarly to the initial attempt where they were getting a public key from the domain in the DNS records, they will now use what is called an HTTPS DNS records instead of the text records. The cool thing about an HTTPS record is that this is using DNS over TLS, usually DNS over HTTPS, meaning that your actual check Elizabeth (Plabayo)
10:20 | 🔗
And similarly to the initial attempt where they were getting a public key from the domain in the DNS records, they will now use what is called an HTTPS DNS records instead of the text records. The cool thing about an HTTPS records is that this is using DNS over TLS, usually DNS over HTTPS, meaning that your actual check is also done encrypted. Elizabeth (Plabayo)
10:46 | 🔗
anybody can see that the client is doing a DNS lookup, but they wouldn't be able to see what is the DNS lookup being done, because also the traffic between the client and the DNS server will also be encrypted. That is what DNS over HTTPS is doing, which I believe is sometimes abbreviated as DOH. ⁓ anybody can see that the client is doing a DNS lookup but they wouldn't be able to see what is the DNS lookup being done because also the traffic between the client and the DNS server will also be encrypted. That is what DNS over HTTPS is doing which I believe is sometimes abbreviated as DOH. ⁓ And so they are getting this public key from the HTTPS records and using that public key, they can encrypt. Elizabeth (Plabayo)
11:08 | 🔗
And so they are getting this public key from the HTTPS records and using that public key they can encrypt most of the client hello content and save it as an extension called the encrypted client hello extension. And that is then being sent as part of the regular client hello to the TLS server. The cool thing about this is, is that the server is the only one, the TLS server is the only one who can see the actual content of most of the client hello content. Elizabeth (Plabayo)
11:15 | 🔗
most of the client hello content and save it as an extension called the encrypted client hello extension. And that is then being sent as part of the regular client hello to the TLS server. The cool thing about this is, is that the server is the only one, the TLS server is the only one who can see the actual content of most of the client hello content. And then that would mean in an ideal world that the public information available in the non-encrypted part of the client hello is no longer containing any sensitive information, such as the actual destination server name indication. Elizabeth (Plabayo)
11:40 | 🔗
And then that would mean in an ideal world that the public information available in the non-encrypted part of the client's hello is no longer containing any sensitive information, such as the actual destination server name indication. indication... disappears completely ECH. completely You could imagine a world where that's true, but most likely no. I don't see a future right now where that's happening. Because something that is terminating at the LS traffic will still want to know if it's destined for it or not. So most likely it still wants some kind of serving of indication. Elizabeth (Plabayo)
12:02 | 🔗
You couldn't imagine a Most likely no. I don't see a future right now where that's happening. Because something that is terminating at the LS traffic will still want to know... if it's destined for it or So most likely it still wants some kind of server communication. so let's give an example just to make it clear. As I said, most web servers are not terminating their own TLS traffic. Elizabeth (Plabayo)
12:23 | 🔗
So let's give an example just to make it As I said, most web servers are not terminating their own TLS traffic. Now that we are in the cloud era, maybe even past the cloud era, I'm not sure in history, most companies operate within the cloud and those clouds are big companies such as Cloudflare, Google, Microsoft, et cetera. Now that we are in the cloud era, maybe even past the cloud era, I'm not sure in history, most companies operate within the cloud and those clouds are big companies such as Cloudflare, Google, Microsoft, etc. What is quite often the case nowadays is that those companies are the ones actually terminating your TLS traffic and sending the decrypted HTTP traffic to the actual destination backend service. Elizabeth (Plabayo)
12:43 | 🔗
What is quite often the case nowadays is that those companies are the ones actually terminating your DLS traffic and sending the decrypted HTTP traffic to the actual destination backend service operated by some company in that cloud. So let's say example.com. Elizabeth (Plabayo)
12:56 | 🔗
operated by some company in that cloud. So let's say example.com. That would mean that the actual plain text server name indication will be instead of the real destination address will be something like that would mean that the actual plain text server name indication will be instead of the real destination address, will be something like tls.cloudcompany.com instead of example.com. anybody. Elizabeth (Plabayo)
13:09 | 🔗
tls.cloudcompany.com instead of anybody that sees the traffic will only be able to see at that point this is traffic destined for that cloud. Elizabeth (Plabayo)
13:16 | 🔗
that sees the traffic will only be able to see at that point, this is traffic destined for that cloud. That's however not information they would also not be able to decipher or deduce from the IP address because if you would do a lookup on the IP address which is anyway plainly visible you would also find that it's an IP address owned by that same cloud operator. So at that point you removed the privacy gap Elizabeth (Plabayo)
13:23 | 🔗
That's however not information they would also not be able to decipher or deduce from the IP address. Because if you would do a lookup on the IP address, which is anyway plainly visible, you would also find that it's an IP address owned by that same cloud operator. So at that point you removed the privacy gap. because you are not leaking anything in your client hello that you also couldn't deduce from lower layers on the network. Elizabeth (Plabayo)
13:44 | 🔗
because you are not leaking anything in your client hello that you also couldn't deduce from lower layers on the network. Is ECH already something people are using today or is it still experimental? For example, if I'm just browsing the is there any chance that I'm already using ECH without realizing it? Elizabeth (Plabayo)
13:53 | 🔗
Is ECH already something people are using today or is it still experimental? For example, if I'm just browsing the is there any chance that I'm already using without realizing it? Well, for many TLS is a black box, especially for users, but even for most... Elizabeth (Plabayo)
14:09 | 🔗
Well, for many, it is a black box, especially for users, but even for most... developers, TLS is a bit of a black book. So they might use it and they might not realize it, that's true. So if we look at the timeline a bit, we talked first about the encryption server name indication. And that was an idea that was started by the Cloudflare and ITF and maybe some other companies. And that was in 2018. Now, Elizabeth (Plabayo)
14:14 | 🔗
developers, TLS is a bit of a black book. So they might use it and they might not realize it, that's true. So if we look at the timeline a bit, we talked first about the encryption server name indication. And that was an idea that was started by the Cloudflare and ITF and maybe some other companies. And that was in 2018. Now that didn't go anywhere, but we learned a lot from it or rather they learned a lot from it. And then around... That didn't go anywhere, but we learned a lot from it, or rather they learned a lot from it. And then around 2020, they started playing with this idea of what we now call Encrypted Client Hello. And so the Encrypted Client Hello started around 2020, where Cloudflare was supporting it on the server side, because Cloudflare is one of those clouds which is terminating the TLS traffic for many web servers. Elizabeth (Plabayo)
14:43 | 🔗
2020 they started playing with this idea of what we now call encrypted client LO. And so the encrypted client LO started around 2020 where Cloudflare was supporting it on the server side because Cloudflare is one of those clouds which is terminating the TLS traffic for many web servers. And a bit later I believe it was Firefox, which is a web client browser, was also shipping its version where they support that. And a bit later, I believe it was Firefox, which is a web client, a browser, was also shipping its version where they support that. Because in order for this to work, both the client and the server need to be able to support it. Now, given that most web traffic is initiated from a browser, Elizabeth (Plabayo)
15:13 | 🔗
to work but the client and the server need to able to support Now, given that most web traffic is initiated from a browser and also knowing the fact that there only so many browsers, the majority of browsers being either like Firefox or some kind of Chromium derived fork with Google Chrome being the most popular one, And also knowing the fact that there only so many browsers, the majority of browsers being either like Firefox or some kind of Chromium derived fork with Google Chrome being the most popular one. you know that most clients already support ECH. So you were asking if I visit the website, will I be able to use it? Yes, most likely. But also the server needs to be able to support it. But also given the fact that most web servers are not doing their own TLS, but rather are delegating that work to the cloud that they are using, or some kind of middleman such as Cloudflare. Elizabeth (Plabayo)
15:33 | 🔗
you know that most clients already support ECH. So you were asking if I visit the website, will I be able to use it? Yes, most likely. But also the server needs to be able to support But also given the fact that most web servers are not doing their own TLS, but rather are delegating that work. to the cloud that they are using or some kind of middleman such as Cloudflare. and given that they also can easily support it and most already do by this point, Elizabeth (Plabayo)
16:00 | 🔗
And given that they also can easily support it and most already do by this point. then the answer is yes. Most likely you're already using at least for some of your web traffic ECH and enjoying the privacy benefits that go with it. You simply don't realize. But this is not only something that users might not realize, it's also something that developers might not realize because either the developer is not Elizabeth (Plabayo)
16:05 | 🔗
then the answer is yes. Most likely you're already using at least for some of your web traffic ECH and enjoying the privacy benefits that go with it. You simply don't realize. But this is not only something that users might not realize, it's also something that developers might not realize. Because either the developer is not... doing TLS themselves because they are delegating it to the cloud where their web server is hosted. Or even if they do TLS, it's not that they are hand-trolling their own TLS implementations. They will be using a TLS library which is doing the TLS for it. Elizabeth (Plabayo)
16:27 | 🔗
doing TLS themselves because they are delegating it to the cloud where their web server is hosted. Or even if they do TLS, it's not that they are hand-trolling their own TLS implementations. They will be using the TLS library, which is doing the TLS for it. When they are writing the web server which is serving HTTPS traffic, so HTTP over TLS, they are using a library for TLS and there are only a couple of them. Examples include OpenSSL, Rust Elizabeth (Plabayo)
16:45 | 🔗
When they are writing the web server, which is serving HTTPS traffic, so HTTP over TLS, they are using a library for TLS. And there are only a couple of them. Examples include OpenSSL, Rust TLS, and they are only like a handful commonly used TLS libraries and one by one if not all of them already start or already support ECH TLS, they are only like a handful commonly used TLS libraries. And one by one, if not all of them already, start or already support ECH. Meaning if that developer that is still doing TLS themselves in their web server is updating its TLS library, it will now also support ECH. And Elizabeth (Plabayo)
17:11 | 🔗
meaning if that developer that is still doing TLS themselves in their web server is updating its TLS library it will now also support ECH. And so recently there was even like a blog post by a curl contributor where they advertised, we are now shipping a first version of curl with ECH enabled. And that's not so much because they had to do a lot of work for it. so for example recently there was even like a blog post by a curl contributor where they advertised we are now shipping a first version of curl with ECH enabled. And that's not so much because they had to do a lot of work for it. is more that they had to update their TLS dependencies, their libraries that they use for TLS to start benefiting from ECH, but all a bit behind the library they're using. They're not doing it themselves. Elizabeth (Plabayo)
17:40 | 🔗
is more that they have to update their TLS dependencies, their libraries that they use for TLS, to start benefiting from ECH. But all a bit behind the library they're using. They're not doing it themselves. Very, very interesting. What are the consequences of using existing infrastructures? For example, systems that rely on inspecting traffic, what happens to them? Yeah, excellent question. Elizabeth (Plabayo)
18:00 | 🔗
what are the consequences of using ECH existing infrastructures? For example, systems that rely on inspecting traffic, what happens to them? So now we are a bit talking about an edge case because for most of the traffic flows, they shouldn't matter at all because this is really something that the client and server agree upon and parties in the middle should in theory, according to the letter of the protocols, not really inspect or let alone... Elizabeth (Plabayo)
18:18 | 🔗
more than X case because for most of the... traffic flows, they shouldn't matter at all because this is really something that the client and server agree upon and parties in the middle should in theory, according to the letter of the protocols, not really inspect or let alone intercept this kind of traffic for any purpose. However, there are religious reasons why you want to do this. For example, if you're in an enterprise or any other kind of environment where security is of the highest importance, intercept this kind of traffic for any purpose. However, there are religious reasons why you want to do this. For example, if you're in an enterprise or any other kind of environment where security is of the highest importance, it can be important and acceptable that the company wants to terminate and inspect this traffic. Elizabeth (Plabayo)
18:51 | 🔗
it can be important and acceptable that the company wants to terminate and inspect this traffic. This is for example because they want to protect the data that is going out of the company or ensuring that no bad malware is coming inside the organization. This is for example because they wanna protect the data that is going out of the company or ensuring that no bad malware is coming inside the organization. To reduce the workload on these kind of layer 4 proxies, and we talked about this in a previous protocol short episode, we will also link it in the show notes. They rely on things such as what protocol is being used, TCP, UDP, but then also on the TLS layer, they will inspect the client hello to check on the server name indication and... Elizabeth (Plabayo)
19:12 | 🔗
To reduce workload on these kind of layer 4 proxies, we talked about this in a previous protocol short episode, we will also link it in the show notes, they rely on things such as what protocol is being used, TCP, UDP, but then also on the TLS layer, they will inspect the client hello to check on the server name indication and Most traffic they will not care about, but some domains they might want to inspect further because these are suspicious domains or these are domains for which there is a high security matter. In case the server name indication which is readily available to anybody reading the traffic no longer Elizabeth (Plabayo)
19:38 | 🔗
Most traffic they will not care about, but some domains they might want to inspect further because these are suspicious domains or these are domains for which there is a high security matter. In case the server name indication which is readily available to anybody reading the traffic no longer contains the real server name indication, it means that those proxies can no longer rely on this field to know whether or not they want to inspect and decrypt the TLS traffic. Meaning they have only two choices. Either Elizabeth (Plabayo)
20:00 | 🔗
contains the real server name indication, it means that those proxies can no longer rely on this field to know whether or not they want to inspect and decrypt the TLS traffic. Meaning they have only two choices. Either they do not encrypt the traffic or they decrypt all traffic, which... Elizabeth (Plabayo)
20:21 | 🔗
they do not encrypt the traffic or they decrypt all traffic which increases the workload they have to do and also increases the exposure of possible mistakes they might make because man-in-the-middle traffic means you're also changing the traffic a bit even if not on purpose and so you might make a mistake as a proxy implementer and so that's why also not only to reduce your workload you also want to prevent the amount of mistakes you can make. Elizabeth (Plabayo)
20:26 | 🔗
increases the workload they have to do and also increases the exposure of possible mistakes they might make because man-in-the-middle traffic means you're also changing the traffic a bit even on purpose and so you might make a mistake as a proxy implementer and so that's why also not only to reduce your workload you also want to prevent the amount of mistakes you can make. Now in a way, like the bits. There's more than two choices. It's not that they have to choose between decrypting anything or decrypting everything. They could also try instead Elizabeth (Plabayo)
20:50 | 🔗
in a way I the bits, there's more than two choices. It's not that they have to choose between decrypting anything or decrypting everything. They could also try They could also choose also man in the middle of DNS traffic. Because as we explained in the previous question, the way this works is that encrypted client hello is encrypted using the public key found in the HTTPS records. means that that client needs to talk to a DNS server, the DNS server configured in its system or in its router. Elizabeth (Plabayo)
21:00 | 🔗
They could also choose to also man in the middle of DNS traffic because as we explained in the previous the way this works is that encrypted client hello is encrypted using the public key found in the HTTPS records. That means that that client needs to talk to a DNS server, the DNS server configured in its system or in its router. Just like the layer 4 proxy can terminate the web traffic, it can also terminate the DNS traffic or inspect it. And it could choose Elizabeth (Plabayo)
21:25 | 🔗
Just like layer 4 proxy can terminate the web traffic, it can also terminate the DNS traffic or inspect it. And it could choose... to give it for that record, for that lookup, its own public key, the public key that is linked to the private key that the proxy owns. Instead of relaying that DNS query to the actual Elizabeth (Plabayo)
21:38 | 🔗
to give it for that record, for that lookup, its own public key, the public key that is linked to the private key that the proxy owns, instead of relaying that DNS query to the DNS resolver servers. That would mean that the Elizabeth (Plabayo)
21:52 | 🔗
DNS resolver That would mean that the... public key received by the TLS client supporting encryptClientHello would now use this public key of the proxy to encrypt the encrypted client Hello. And that would allow the proxy to once again decrypt the client Hello. This would work only Elizabeth (Plabayo)
21:56 | 🔗
public key received by the TLS client supporting encrypt client hello would now use this public key of the proxy to encrypt the encrypted client hello and that would allow the proxy to once again decrypt the client hello. This would work only If one, the proxy does that, so also is intercepting the DNS traffic. And two, similar like how the client would need to trust the certificate used or issued by the proxy for the web traffic, it will also need to trust the public for Elizabeth (Plabayo)
22:16 | 🔗
if one, the proxy does that, so also is intercepting the DNS traffic, and two, similar like how the client would need to trust the certificate used or issued by the proxy for the web traffic, it would also need to trust the public key for that encrypted client hello. But of course because it's given via DNS record, the client will trust it. So this would be one way that encrypted client hello. But of course, because it's given via DNS record, the client will trust it. So this would be one way. Elizabeth (Plabayo)
22:42 | 🔗
for the layer four proxy in this kind of security infrastructure to still use relatively cheap lookup on whether or not we want to manage the middle of this traffic. But it is extra work for the infrastructure. And so existing infrastructure as is, which is only focused on inspecting web. for the layer four proxy in this kind of security infrastructure to still use a relatively cheap lookup on whether or not we want to man in the middle of this traffic. But it is extra work for the infrastructure. so existing infrastructure as is, which is only focused on inspecting web traffic, Elizabeth (Plabayo)
23:03 | 🔗
traffic will no longer work. It will need to add this new to also intercept the DNS will no longer work. It will need to add this new capability to also intercept the DNS traffic. Elizabeth (Plabayo)
23:12 | 🔗
traffic. I understand. And does this mean tools like Rama need up the stack to stay effective? So Rama is the free and open source framework that we develop and maintain at Labio. And does this mean tools like Rama need to up the stack to stay effective? So Rama is the free and open source framework that we develop and maintain at Plabaio. And Elizabeth (Plabayo)
23:30 | 🔗
And so it is a modular framework for building network service in Rust. And it handles the different protocols involved in network services going from TCP, UDP, DNS, HTTP, TLS, Some companies, security companies also use RAMA to so it is a modular framework for building network service in Rust. And it handles the different protocols involved in network services, going from TCP, UDP, DNS, HTTP, TLS, et cetera. companies, such as security companies, also use Rama to... inspect traffic and man-in-the-middle traffic that is of And so those companies that are maybe for now only man-in-the-middling Elizabeth (Plabayo)
23:50 | 🔗
inspect traffic and man-in-the-middle traffic that is of And so those companies that are maybe for now only man-in-the-middle the web traffic or the application layer TCP traffic would also start to inspect and intercept the DNS traffic. That's correct because if they do not do that yet, then they would indeed not be able to rely on the plain text server name indication. Elizabeth (Plabayo)
24:00 | 🔗
layer TCP traffic would also start to inspect intercept the DNS traffic. That's correct because if they do not do that yet then they would indeed not be able to rely on the plaintext server name indication. it well. where do you see this is going in the next few years? Is a clear win for privacy or are we trading off something important on the network side? What do you think? a bit of a difficult question to answer. Elizabeth (Plabayo)
24:20 | 🔗
Where do you see this is going in the next few years? Is this a clear win for privacy or are we trading off something important on the network side? What do you think? Intuitively you would think this is a clear win for privacy and I do believe it is. However, in the end you do still put your trust somewhere. Elizabeth (Plabayo)
24:39 | 🔗
Intuitively you would think this is a clear win for privacy and I do believe it is. However, in the end you do still put your trust So we talked a bit about middle boxes and we talked about, so far this information was available in the clear text client hello. So we talked a bit about middleboxes and we talked about, so far this information was available in the clear text client hello, which means middlebox from your telecom providers could read it or your government or whoever else might be interested in your traffic and they could see what web traffic you are visiting. But we also explained that most... Elizabeth (Plabayo)
24:59 | 🔗
which means middle books from your telecom provider could read it or your government or whoever else might be interested in traffic and they could see what web traffic you are visiting. But we also explained that most Web servers are not terminating their own TLS traffic and instead relying on their cloud. Meaning they are using a cloud such as Microsoft or Cloudflare. Elizabeth (Plabayo)
25:12 | 🔗
web servers are not terminating their own TLS traffic and instead relying on their cloud. Meaning they are using a cloud such as Microsoft or Cloudflare. Well, that kind of means you have to put your trust in those companies instead of putting your trust in your telecom provider. And I'm not entirely convinced that those companies are less likely to leak at some point your data, be it by accident or selling it on purpose. But you reduce the blast radius because in the end before... Elizabeth (Plabayo)
25:22 | 🔗
Well, that kind of means you have to put your trust in those companies instead of putting your trust in your telecom provider. And I'm not entirely convinced that those companies are less likely to leak at some point your data, be it by accident or selling it on purpose. but you reduce the blast radius because in the end before anybody seeing your traffic could see that data. anybody who could see your network traffic before was able to see those domains, those application protocols. Now it is only a handful of actors which do have some kind of image to upheld. Like people do pay them and do have trust in them that their data anybody seeing your traffic could see that data. So anybody who could see your network traffic before was able to see those domains, those application protocols. Now it is only a handful of actors which do have some kind of image to upheld. Like people do pay them and do have trust in them that their data is not leaked by them, at least not on purpose. Elizabeth (Plabayo)
26:11 | 🔗
not leaked by them, at least on purpose. So I think overall it's a privacy win, but as long as not every web server is doing its own TLS, it does mean that you still at the very least put your trust in those very few amount of cloud companies that are available in the world right now. Elizabeth (Plabayo)
26:14 | 🔗
So I think overall it's a privacy win, but as long as not every web server is doing its own TLS, it does mean that you still at the very least put your trust in those very few amount of cloud companies that are available in the world right thank you for giving us a reality check. Thank you for giving us a reality check. Okay, Elizabeth (Plabayo)
26:38 | 🔗
Okay. Thank you very much, Glen. I appreciate you give us the time to give a clarification on this subject, TLS ECH. And thank you to all our and have a good week. Bye. Bye, Brian. ⁓ I didn't record. thank you very much, and I appreciate you give us a time to give a clarification on this subject TLS ECH. And thank you to our audience and have a good Bye. Bye bye. Elizabeth (Plabayo)
26:58 | 🔗
Netstack.fm is brought to you by Plabayo building secure, open, and resilient infrastructure with Rust protocols, and purpose. This show is also made possible by Rama, the open source networking framework. Plabayo offers service contracts and welcome sponsorships to keep building and supporting its ecosystem. The theme music of this podcast was composed by DJ Mailbox. If you enjoyed this episode, don't forget to subscribe on your favorite podcast platform and leave a five-star review. It really helps others discover the show. Thanks for tuning We'll see you next time for the next handshake.