And your ISP can still see which domains you’re going to if you use them as your DNS.
Just so you know, because TLS SNI is not encrypted and not yet universally obfuscated (adoption of this is pretty slow and one of the largest CDN providers had to pause their rollout last I checked), not-even-barely-deep packet inspection can be used to track the sites you visit regardless of your DNS provider or wherever resolution is encrypted. Just do a packet dump and see.
Also, if a website isn’t fronted by one of the most popular CDN providers in existence, it can be possible to infer the sites you’re visiting based on their server IP addresses.
Although this just shifts where tracking can occur, a VPN is the only reliable way to maybe prevent your ISP from tracking the sites you visit, if this is your desire.
Yep, I’m aware. It’s how that one guy hacked his airplanes wireless, by setting up a certificate with his domain and the airlines and then using that domain + port 443 as an ssh or vpn tunnel.
So TLS rollout is slow because the websites can still be seen with packet inspection? We’re talking about TLS 1.4 right?
I’m not sure if it’s part of a TLS standard yet but I was talking about encrypted SNI (ECH, formerly called ESNI).
Today, early on in a TLS connection, the client actually tells the server, in plain text, the domain name it’s intending to communicate with. The server then presents a response that only the owner of that domain can produce, then keys are exchanged and the connection progresses, encrypted. This was required to allow a single server to serve traffic on multiple domains. Before this, a server on an IP:Port combo could only serve traffic on a single domain.
But because of this, a man in the middle can just read the ClientHello and learn the domain you’re intending to connect to. They can’t intercept any encapsulated data (e.g. at the HTTP level, in the case of web traffic) but they can learn the domains you’re accessing.
ECH promises to make the real ClientHello encrypted by proceeding it with a fake ClientHello. The response will contain enough information to fetch a key that can be used to encrypt the real ClientHello. Only the server will be able to decrypt this.
Just so you know, because TLS SNI is not encrypted and not yet universally obfuscated (adoption of this is pretty slow and one of the largest CDN providers had to pause their rollout last I checked), not-even-barely-deep packet inspection can be used to track the sites you visit regardless of your DNS provider or wherever resolution is encrypted. Just do a packet dump and see.
Also, if a website isn’t fronted by one of the most popular CDN providers in existence, it can be possible to infer the sites you’re visiting based on their server IP addresses.
Although this just shifts where tracking can occur, a VPN is the only reliable way to maybe prevent your ISP from tracking the sites you visit, if this is your desire.
Yep, I’m aware. It’s how that one guy hacked his airplanes wireless, by setting up a certificate with his domain and the airlines and then using that domain + port 443 as an ssh or vpn tunnel.
So TLS rollout is slow because the websites can still be seen with packet inspection? We’re talking about TLS 1.4 right?
I’m not sure if it’s part of a TLS standard yet but I was talking about encrypted SNI (ECH, formerly called ESNI).
Today, early on in a TLS connection, the client actually tells the server, in plain text, the domain name it’s intending to communicate with. The server then presents a response that only the owner of that domain can produce, then keys are exchanged and the connection progresses, encrypted. This was required to allow a single server to serve traffic on multiple domains. Before this, a server on an IP:Port combo could only serve traffic on a single domain.
But because of this, a man in the middle can just read the ClientHello and learn the domain you’re intending to connect to. They can’t intercept any encapsulated data (e.g. at the HTTP level, in the case of web traffic) but they can learn the domains you’re accessing.
ECH promises to make the real ClientHello encrypted by proceeding it with a fake ClientHello. The response will contain enough information to fetch a key that can be used to encrypt the real ClientHello. Only the server will be able to decrypt this.