1 00:00:17,000 --> 00:00:29,000 Elizabeth (Plabayo): 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? 2 00:00:29,000 --> 00:00:48,000 Glen (Plabayo): 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. 3 00:00:48,000 --> 00:01:00,000 Elizabeth (Plabayo): 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 4 00:01:00,000 --> 00:01:00,001 Glen (Plabayo): 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 5 00:01:00,000 --> 00:01:10,000 Elizabeth (Plabayo): 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. 6 00:01:10,000 --> 00:01:10,001 Glen (Plabayo): 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, 7 00:01:10,000 --> 00:01:23,000 Elizabeth (Plabayo): 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 8 00:01:23,000 --> 00:01:23,001 Glen (Plabayo): 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. 9 00:01:23,000 --> 00:01:51,000 Elizabeth (Plabayo): 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. 10 00:01:51,000 --> 00:02:06,000 Glen (Plabayo): 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. 11 00:02:06,000 --> 00:02:18,000 Elizabeth (Plabayo): 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 12 00:02:18,000 --> 00:02:18,001 Glen (Plabayo): 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? 13 00:02:18,000 --> 00:02:31,000 Elizabeth (Plabayo): 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? 14 00:02:31,000 --> 00:02:31,001 Glen (Plabayo): 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. 15 00:02:31,000 --> 00:02:46,000 Elizabeth (Plabayo): 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. 16 00:02:46,000 --> 00:02:46,001 Glen (Plabayo): 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 17 00:02:46,000 --> 00:03:01,000 Elizabeth (Plabayo): 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 18 00:03:01,000 --> 00:03:02,000 Glen (Plabayo): configurations that wouldn't work. 19 00:03:02,000 --> 00:03:04,000 Elizabeth (Plabayo): configurations, that wouldn't work. 20 00:03:04,000 --> 00:03:04,001 Glen (Plabayo): 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... 21 00:03:04,000 --> 00:03:28,000 Elizabeth (Plabayo): 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 22 00:03:28,000 --> 00:03:29,000 Glen (Plabayo): Did we have a connection before and can we speed up the process by sharing already the 23 00:03:29,000 --> 00:03:34,000 Elizabeth (Plabayo): 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. 24 00:03:34,000 --> 00:03:50,000 Glen (Plabayo): 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. ⁓ 25 00:03:50,000 --> 00:04:12,000 Elizabeth (Plabayo): 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, 26 00:04:12,000 --> 00:04:12,001 Glen (Plabayo): 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. 27 00:04:12,000 --> 00:04:39,000 Elizabeth (Plabayo): 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. 28 00:04:39,000 --> 00:04:42,000 Glen (Plabayo): It will then send back the server 29 00:04:42,000 --> 00:04:42,001 Elizabeth (Plabayo): 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. 30 00:04:42,000 --> 00:05:02,000 Glen (Plabayo): 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, 31 00:05:02,000 --> 00:05:05,000 Elizabeth (Plabayo): The client will receive this and at that point 32 00:05:05,000 --> 00:05:05,001 Glen (Plabayo): 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. 33 00:05:05,000 --> 00:05:26,000 Elizabeth (Plabayo): 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 34 00:05:26,000 --> 00:05:32,000 Glen (Plabayo): Nowadays, a lot of web traffic is using certificates signed by Let's Encrypt, which made... 35 00:05:32,000 --> 00:05:32,001 Elizabeth (Plabayo): 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... 36 00:05:32,000 --> 00:05:50,000 Glen (Plabayo): 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. 37 00:05:50,000 --> 00:06:00,000 Elizabeth (Plabayo): 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 38 00:06:00,000 --> 00:06:19,000 Glen (Plabayo): 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 39 00:06:19,000 --> 00:06:19,001 Elizabeth (Plabayo): between the client and the server. 40 00:06:19,000 --> 00:06:21,000 Glen (Plabayo): the client and the server. 41 00:06:21,000 --> 00:06:21,001 Elizabeth (Plabayo): 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, 42 00:06:21,000 --> 00:06:34,000 Glen (Plabayo): 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, 43 00:06:34,000 --> 00:06:35,000 Elizabeth (Plabayo): everything else is encrypted and if you would like inspect this web traffic using a tool like 44 00:06:35,000 --> 00:06:42,000 Glen (Plabayo): 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. 45 00:06:42,000 --> 00:06:54,000 Elizabeth (Plabayo): 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. 46 00:06:54,000 --> 00:06:54,001 Elizabeth (Plabayo): So if I understand well, middle boxes can see the server name indication. 47 00:06:54,000 --> 00:07:01,000 Glen (Plabayo): So if I understand well, middle boxes can see the server name indication. And does this affect how networks behave? 48 00:07:01,000 --> 00:07:07,000 Elizabeth (Plabayo): And does this affect how networks behave? So, 49 00:07:07,000 --> 00:07:07,001 Glen (Plabayo): 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 50 00:07:07,000 --> 00:07:26,000 Elizabeth (Plabayo): 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... 51 00:07:26,000 --> 00:07:26,001 Glen (Plabayo): 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 52 00:07:26,000 --> 00:07:37,000 Elizabeth (Plabayo): 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 53 00:07:37,000 --> 00:07:37,001 Glen (Plabayo): check sometimes what TCP port they have to use and then they might filter out or drop traffic that they don't want to. 54 00:07:37,000 --> 00:07:43,000 Elizabeth (Plabayo): check sometimes what TCP port they have to use and then they might filter out or drop traffic that they don't want to. 55 00:07:43,000 --> 00:07:43,001 Glen (Plabayo): 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. 56 00:07:43,000 --> 00:07:57,000 Elizabeth (Plabayo): 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. 57 00:07:57,000 --> 00:08:07,000 Glen (Plabayo): 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. 58 00:08:07,000 --> 00:08:20,000 Elizabeth (Plabayo): 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. 59 00:08:20,000 --> 00:08:20,001 Glen (Plabayo): mostly not so much is it a network issue, it's mostly a matter of privacy. If that makes sense to you, Elizabeth. 60 00:08:20,000 --> 00:08:27,000 Elizabeth (Plabayo): mostly not so much is it a network issue, it's mostly a matter of If that makes sense to you 61 00:08:27,000 --> 00:08:27,001 Glen (Plabayo): This seems like a privacy gap. And have people been trying to solve this a while? 62 00:08:26,000 --> 00:08:33,000 Elizabeth (Plabayo): Yeah, this seems like a privacy gap. Have people been trying to solve a while? 63 00:08:33,000 --> 00:08:35,000 Glen (Plabayo): 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... 64 00:08:35,000 --> 00:08:46,000 Elizabeth (Plabayo): 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 65 00:08:46,000 --> 00:08:46,001 Glen (Plabayo): Companies like Cloudflare and the IETF, 66 00:08:46,000 --> 00:08:49,000 Elizabeth (Plabayo): 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 67 00:08:49,000 --> 00:09:14,000 Glen (Plabayo): 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 68 00:09:14,000 --> 00:09:14,001 Elizabeth (Plabayo): they could use to encrypt the server name indication. 69 00:09:14,000 --> 00:09:18,000 Glen (Plabayo): would use to encrypt the server name indication. 70 00:09:18,000 --> 00:09:18,001 Elizabeth (Plabayo): 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. 71 00:09:18,000 --> 00:09:35,000 Glen (Plabayo): 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. 72 00:09:35,000 --> 00:09:49,000 Elizabeth (Plabayo): 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. 73 00:09:49,000 --> 00:09:49,001 Glen (Plabayo): So how does ECH actually fix 74 00:09:49,000 --> 00:09:53,000 Elizabeth (Plabayo): So how does ECH actually fix this 75 00:09:53,000 --> 00:09:53,001 Glen (Plabayo): 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. 76 00:09:53,000 --> 00:10:16,000 Elizabeth (Plabayo): 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. 77 00:10:16,000 --> 00:10:20,000 Glen (Plabayo): 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 78 00:10:20,000 --> 00:10:43,000 Elizabeth (Plabayo): 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. 79 00:10:43,000 --> 00:10:46,000 Glen (Plabayo): is also done encrypted. 80 00:10:46,000 --> 00:10:46,001 Elizabeth (Plabayo): 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. ⁓ 81 00:10:46,000 --> 00:11:08,000 Glen (Plabayo): 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. 82 00:11:08,000 --> 00:11:15,000 Elizabeth (Plabayo): And so they are getting this public key from the HTTPS records and using that public key they can encrypt 83 00:11:15,000 --> 00:11:15,001 Glen (Plabayo): 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. 84 00:11:15,000 --> 00:11:40,000 Elizabeth (Plabayo): 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. 85 00:11:40,000 --> 00:11:40,001 Glen (Plabayo): 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. 86 00:11:40,000 --> 00:11:59,000 Elizabeth (Plabayo): 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. 87 00:11:59,000 --> 00:12:02,000 Glen (Plabayo): 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. 88 00:12:02,000 --> 00:12:22,000 Elizabeth (Plabayo): 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. 89 00:12:22,000 --> 00:12:23,000 Glen (Plabayo): so let's give an example just to make it clear. As I said, most web servers are not terminating their own TLS traffic. 90 00:12:23,000 --> 00:12:30,000 Elizabeth (Plabayo): 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. 91 00:12:30,000 --> 00:12:43,000 Glen (Plabayo): 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. 92 00:12:43,000 --> 00:12:56,000 Elizabeth (Plabayo): 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 93 00:12:56,000 --> 00:12:56,001 Glen (Plabayo): operated by some company in that cloud. So let's say example.com. 94 00:12:56,000 --> 00:12:59,000 Elizabeth (Plabayo): 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 95 00:12:59,000 --> 00:13:09,000 Glen (Plabayo): 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. 96 00:13:09,000 --> 00:13:16,000 Elizabeth (Plabayo): tls.cloudcompany.com instead of anybody 97 00:13:16,000 --> 00:13:16,001 Glen (Plabayo): that sees the traffic will only be able to see at that point this is traffic destined for that cloud. 98 00:13:16,000 --> 00:13:22,000 Elizabeth (Plabayo): that sees the traffic will only be able to see at that point, this is traffic destined for that cloud. 99 00:13:22,000 --> 00:13:23,000 Glen (Plabayo): 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 100 00:13:23,000 --> 00:13:44,000 Elizabeth (Plabayo): 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. 101 00:13:44,000 --> 00:13:44,001 Glen (Plabayo): because you are not leaking anything in your client hello that you also couldn't deduce from lower layers on the network. 102 00:13:44,000 --> 00:13:53,000 Elizabeth (Plabayo): because you are not leaking anything in your client hello that you also couldn't deduce from lower layers on the network. 103 00:13:53,000 --> 00:13:53,001 Glen (Plabayo): 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? 104 00:13:53,000 --> 00:14:09,000 Elizabeth (Plabayo): 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? 105 00:14:09,000 --> 00:14:09,001 Glen (Plabayo): Well, for many TLS is a black box, especially for users, but even for most... 106 00:14:09,000 --> 00:14:14,000 Elizabeth (Plabayo): Well, for many, it is a black box, especially for users, but even for most... 107 00:14:14,000 --> 00:14:14,001 Glen (Plabayo): 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, 108 00:14:14,000 --> 00:14:37,000 Elizabeth (Plabayo): 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... 109 00:14:37,000 --> 00:14:43,000 Glen (Plabayo): 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. 110 00:14:43,000 --> 00:15:02,000 Elizabeth (Plabayo): 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. 111 00:15:02,000 --> 00:15:13,000 Glen (Plabayo): 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, 112 00:15:13,000 --> 00:15:22,000 Elizabeth (Plabayo): 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, 113 00:15:22,000 --> 00:15:33,000 Glen (Plabayo): 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. 114 00:15:33,000 --> 00:15:59,000 Elizabeth (Plabayo): 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. 115 00:15:59,000 --> 00:16:00,000 Glen (Plabayo): and given that they also can easily support it and most already do by this point, 116 00:16:00,000 --> 00:16:05,000 Elizabeth (Plabayo): And given that they also can easily support it and most already do by this point. 117 00:16:05,000 --> 00:16:05,001 Glen (Plabayo): 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 118 00:16:05,000 --> 00:16:27,000 Elizabeth (Plabayo): 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... 119 00:16:27,000 --> 00:16:27,001 Glen (Plabayo): 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. 120 00:16:27,000 --> 00:16:45,000 Elizabeth (Plabayo): 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. 121 00:16:45,000 --> 00:16:45,001 Glen (Plabayo): 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 122 00:16:45,000 --> 00:16:58,000 Elizabeth (Plabayo): 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 123 00:16:58,000 --> 00:17:11,000 Glen (Plabayo): 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 124 00:17:11,000 --> 00:17:23,000 Elizabeth (Plabayo): 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. 125 00:17:23,000 --> 00:17:40,000 Glen (Plabayo): 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. 126 00:17:40,000 --> 00:18:00,000 Elizabeth (Plabayo): 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. 127 00:18:00,000 --> 00:18:00,001 Glen (Plabayo): What are the consequences of using existing infrastructures? For example, systems that rely on inspecting traffic, what happens to them? Yeah, excellent question. 128 00:18:00,000 --> 00:18:16,000 Elizabeth (Plabayo): what are the consequences of using ECH existing infrastructures? For example, systems that rely on inspecting traffic, what happens to them? 129 00:18:16,000 --> 00:18:18,000 Glen (Plabayo): 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... 130 00:18:18,000 --> 00:18:37,000 Elizabeth (Plabayo): 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, 131 00:18:37,000 --> 00:18:51,000 Glen (Plabayo): 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. 132 00:18:51,000 --> 00:19:01,000 Elizabeth (Plabayo): 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. 133 00:19:01,000 --> 00:19:12,000 Glen (Plabayo): 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... 134 00:19:12,000 --> 00:19:38,000 Elizabeth (Plabayo): 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 135 00:19:38,000 --> 00:19:38,001 Glen (Plabayo): 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 136 00:19:38,000 --> 00:20:00,000 Elizabeth (Plabayo): 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 137 00:20:00,000 --> 00:20:00,001 Glen (Plabayo): 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 138 00:20:00,000 --> 00:20:21,000 Elizabeth (Plabayo): 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 139 00:20:21,000 --> 00:20:21,001 Glen (Plabayo): they do not encrypt the traffic or they decrypt all traffic, which... 140 00:20:21,000 --> 00:20:26,000 Elizabeth (Plabayo): they do not encrypt the traffic or they decrypt all traffic which 141 00:20:26,000 --> 00:20:26,001 Glen (Plabayo): 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. 142 00:20:26,000 --> 00:20:49,000 Elizabeth (Plabayo): 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. 143 00:20:49,000 --> 00:20:50,000 Glen (Plabayo): 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 144 00:20:50,000 --> 00:21:00,000 Elizabeth (Plabayo): 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 145 00:21:00,000 --> 00:21:00,001 Glen (Plabayo): 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. 146 00:21:00,000 --> 00:21:25,000 Elizabeth (Plabayo): 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. 147 00:21:25,000 --> 00:21:25,001 Glen (Plabayo): 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 148 00:21:25,000 --> 00:21:37,000 Elizabeth (Plabayo): Just like layer 4 proxy can terminate the web traffic, it can also terminate the DNS traffic or inspect it. And it could choose... 149 00:21:37,000 --> 00:21:38,000 Glen (Plabayo): 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 150 00:21:38,000 --> 00:21:52,000 Elizabeth (Plabayo): 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 151 00:21:52,000 --> 00:21:52,001 Glen (Plabayo): DNS resolver servers. That would mean that the 152 00:21:52,000 --> 00:21:56,000 Elizabeth (Plabayo): DNS resolver That would mean that the... 153 00:21:56,000 --> 00:21:56,001 Glen (Plabayo): 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 154 00:21:56,000 --> 00:22:16,000 Elizabeth (Plabayo): 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 155 00:22:16,000 --> 00:22:16,001 Glen (Plabayo): 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 156 00:22:16,000 --> 00:22:34,000 Elizabeth (Plabayo): 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 157 00:22:34,000 --> 00:22:42,000 Glen (Plabayo): 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. 158 00:22:42,000 --> 00:22:42,001 Elizabeth (Plabayo): 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. 159 00:22:42,000 --> 00:23:03,000 Glen (Plabayo): 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, 160 00:23:03,000 --> 00:23:04,000 Elizabeth (Plabayo): traffic will no longer work. It will need to add this new to also intercept the DNS 161 00:23:04,000 --> 00:23:12,000 Glen (Plabayo): will no longer work. It will need to add this new capability to also intercept the DNS traffic. 162 00:23:12,000 --> 00:23:15,000 Elizabeth (Plabayo): 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. 163 00:23:15,000 --> 00:23:30,000 Glen (Plabayo): 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 164 00:23:30,000 --> 00:23:30,001 Elizabeth (Plabayo): 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 165 00:23:30,000 --> 00:23:50,000 Glen (Plabayo): 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 166 00:23:50,000 --> 00:23:57,000 Elizabeth (Plabayo): 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 167 00:23:57,000 --> 00:24:00,000 Glen (Plabayo): 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. 168 00:24:00,000 --> 00:24:20,000 Elizabeth (Plabayo): 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. 169 00:24:20,000 --> 00:24:20,001 Glen (Plabayo): 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. 170 00:24:20,000 --> 00:24:39,000 Elizabeth (Plabayo): 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? 171 00:24:39,000 --> 00:24:39,001 Glen (Plabayo): 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. 172 00:24:39,000 --> 00:24:48,000 Elizabeth (Plabayo): 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. 173 00:24:48,000 --> 00:24:59,000 Glen (Plabayo): 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... 174 00:24:59,000 --> 00:25:12,000 Elizabeth (Plabayo): 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 175 00:25:12,000 --> 00:25:12,001 Glen (Plabayo): 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. 176 00:25:12,000 --> 00:25:22,000 Elizabeth (Plabayo): 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. 177 00:25:22,000 --> 00:25:22,001 Glen (Plabayo): 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... 178 00:25:22,000 --> 00:25:46,000 Elizabeth (Plabayo): 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 179 00:25:46,000 --> 00:26:11,000 Glen (Plabayo): 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. 180 00:26:11,000 --> 00:26:14,000 Elizabeth (Plabayo): not leaked by them, at least on purpose. 181 00:26:14,000 --> 00:26:14,001 Glen (Plabayo): 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. 182 00:26:14,000 --> 00:26:32,000 Elizabeth (Plabayo): 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. 183 00:26:32,000 --> 00:26:38,000 Glen (Plabayo): Thank you for giving us a reality check. Okay, 184 00:26:38,000 --> 00:26:39,000 Elizabeth (Plabayo): 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. 185 00:26:39,000 --> 00:26:58,000 Glen (Plabayo): 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. 186 00:26:58,000 --> 00:27:03,000 Elizabeth (Plabayo): 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.