Firefox sends domain names unencrypted in TLS handshake

D

Dragony

Hey.

I really don't know where to start searching for help, so I just start here.

I am using FreeBSD 13.2 with Firefox 102.15.1esr and I want not to be spied on, so I use DNS over TLS as well. This should mean that the only thing an mitm attacker should see is encrypted traffic. So why the heck can I real plain text domain names in every request??? This is the outgoing traffic when I visit google on a freshly opened firefox:
Code: 
[22.11.2023 12:31:38] IP4:TCP ip=10.0.10.3:26925 -> 172.217.168.67:443 host_dst=zrh04s15-in-f3.1e100.net ip_len=60
..kx...^E..T..E..<..@.@.ќ
.
..٨Ci-.._...........&#.............
rwe.....

[22.11.2023 12:31:38] IP4:TCP ip=10.0.10.3:26925 -> 172.217.168.67:443 host_dst=zrh04s15-in-f3.1e100.net ip_len=52
..kx...^E..T..E..4..@.@.Ѥ
.
..٨Ci-.._...27.....
.3.....
rwẻ.ǎ

[22.11.2023 12:31:38] 583 bytes from A8:5E:45:A6:E1:54 to AC:1F:6B:78:15:02 mactype=0x0800 contains:
IP4:TCP ip=10.0.10.3:26925 -> 172.217.168.67:443 host_dst=zrh04s15-in-f3.1e100.net ip_len=569
..kx...^E..T..E..9..@.@.ϟ
.
..٨Ci-.._...27.....
.5.....
rwe͉.ǎ............Ӛ...nC..ؼ.Z    Kץ.Ӆ.Qj.I...... sF..@$.պ..R.lu..<..w9...4.z+..M.".......+./̨̩.,.0.
.       ........./.5.............fonts.gstatic.com..........
.............................h2.http/1.1..........".
...........3.k.i... ...8..<.9y..EDu.y.g.......+(n`*O...A..U=.ۇ..`......0...
z.../.~.*`..ij..~._.:7/T.=*J.O.y*z.N..A=|..A.+........
..............................@..............................................................................................................
......................................

[22.11.2023 12:31:38] IP4:TCP ip=10.0.10.3:26925 -> 172.217.168.67:443 host_dst=zrh04s15-in-f3.1e100.net ip_len=52
..kx...^E..T..E..4..@.@.Ѥ
.
..٨Ci-.._...27.......?.....
rwe...Ǣ

[22.11.2023 12:31:38] IP4:TCP ip=10.0.10.3:26925 -> 172.217.168.67:443 host_dst=zrh04s15-in-f3.1e100.net ip_len=52
..kx...^E..T..E..4..@.@.Ѥ
.
..٨Ci-.._...27......;.....
rwe...Ǣ
All the dots are unprintable binary bytes, but the thing is, that you can clearly read fonts.gstatic.com there. And this is valid for every domain I visit. If this is working as intended, then I wonder why I am using dns over tls after all?
 

Server Name Indication - Wikipedia

en.wikipedia.org en.wikipedia.org

Dragony said:
If this is working as intended, then I wonder why I am using dns over tls after all?
Click to expand...
I wonder as well 😉

Seriously, the IP address you're connecting to already reveals the better part of the information (unless there would be thousands of domains served on exactly that address...). If you really need to hide that, you might want something like TOR instead.
 
That's very interesting, thank you for bringing this up.

Naively I thought everything was encrypted like the name suggest it but I was wrong.
Apparently the first part of the url is unencrypted while the rest is encrypted, I didn't know that.
So if HTTPS/TLS can't hide it obviously DNS over TLS/HTTPS won't do it either.

The following links explain it way better that me:
stackoverflow.com

Are HTTPS URLs encrypted?

Are all URLs encrypted when using TLS/SSL (HTTPS) encryption? I would like to know because I want all URL data to be hidden when using TLS/SSL (HTTPS). If TLS/SSL gives you total URL encryption th...
stackoverflow.com stackoverflow.com

So the remaining question is what DoT/DoH is good at ? and do we really need it ?
At first I had the idea that it was good for hiding your internet requests from your ISP, but now ... I am under the impression that it's more a question of who do you trust more, the ISP or the one hosting the Dot/DoH server ?
 
For me it seems that using DoT/DoH makes your privacy level actually worse. Without using it, only your ISP can read the domains you are visiting. But by using it, the DoT/DoH host can read them AS WELL.... WTF...... Is my conclusion really true????
 
I think we need to look at the bigger picture. You say you don't want to be spied on. By that you seem to mean that you (meaning a host named laptop.dragony.com) want to be able to interact with a web server at www.secret.example.com. The threat model is that someone is listening in on your internet connection, for example they have a tap on your DSL line. You want that (a) the exact content of the interaction can't be decoded, and (b) the fact that you interacted with the server at all can't be deduced from observing the traffic.

Requirement (a) is considered fulfilled by using the https protocol: Nominally, all traffic to and from the server is encrypted (by using TLS or SSL). There are some nasty details that lead some security researchers to say that https is much less secure than people think, and it has to do with the public secret that's used to establish the encrypted connection being user far too frequently, but that's a fine detail mostly interesting to cryptography researchers.

Requirement (b) is highly troubling. Because anyone who looks at the wire inside your house can see that IP address 10.1.2.3 is speaking to 9.8.7.6. A quick look at reverse DNS can find that 10.1.2.3 is the IP address of your laptop.dragony.com (I'm using a martian internal IP address here in the example, a public one makes little difference), and that 9.8.7.6 resolves back to www.secret.example.com. (By the way, the examples here are fictitious; I don't know whether secret.example.com exists, and 9.8.7.6 would in reality be an IBM internal IP address). So trying to remain anonymous isn't going to work well at all: Any spy can see that "someone" is talking to secret.example.com. How accurately they can decode who that "someone" is depends on where they look: If they have the network tap inside your house, they will know that the party is inside your house, and will know the mac address of the device (for example from watching arp traffic), so they will know whether it is a Dell or Mac or Asus laptop. Unless you have a large family with a lot of Dell laptops, this pretty much narrows it down to a single person. If the spy has tapped the DSL or cable modem wire between your house and the phone/cable company, they also know that the traffic is coming from your house; but at that point, due to the lac of mac address and the fact that your router is NAT'ing the 10.1.2.3, they won't know whether it was you, your spouse, child or parent. If the spy is somewhere in the middle of the continent, they will just see the nearest NAT host; they might just know that "someone in Anywhere, North Dakota, USA is talking to secret-example.com".

Now you think you can hide using encrypted DNS. That simply doesn't work against a spy who is tapping the communications infrastructure, if they do traffic analysis (that's the technical term for observing who is speaking to whom). So what is encrypted DNS actually good for? Not very much. It means if someone has ONLY tapped the line between you and the DNS server (not the line between you and the whole world), they can't see that you are trying to communicate with secret.example.com. And more importantly, if someone has put a MitM (man in the middle) between you and the DNS server, they can't reroute your traffic to a fake secret.example.com server. Which is nice, because most people never check the https host's credentials (the certificate), yet another place where a lot of our secure network infrastructure is mostly security theater. But in reality, against the realistic threat model (someone is observing all traffic to/from your house), encrypted DNS does little. Actually, there is some use for encrypted DNS, and it is in cases where a multi-site CDN is used by the secret web server; for example they could share CDN hosts with a common site (such as www.amazon.com), in which case the traffic to secret.example.com ends up resolving to an IP address such as xyz.aws.com, which is used by many web properties, and you get security by dilution.

And finally, an observation: The packets you list above are all between you and a google host: both zrh...1e100.net and gstatic.com are part of google. I'm not even sure the packets you print are the encrypted DNS over TLS traffic; they might just be the https traffic of the web page you actually accessed.
 
ralphbsz said:
I'm not even sure the packets you print are the encrypted DNS over TLS traffic; they might just be the https traffic of the web page you actually accessed.
Click to expand...
Which is exactly what OP initially "complained" about... what we see here is most likely https with a TLS handshake using (unencrypted) SNI, pretty much standard.

Now, if the hostname wasn't revealed there (and couldn't be correlated either because DNS requests are encrypted), an eavesdropper could use reverse DNS on the remote IP address, but in case this remote machine hosts many different domains, the eavesdropper couldn't tell which one was actually requested. In practice, I'd consider that no privacy advantage at all.

Again, if you really need to hide with whom you communicate (not only the content of the communication), you'd have to start by using TOR. And it won't end here, at least for the web, there are tons of other stuff to consider that would allow to e.g. "fingerprint" your browser and then correlated with any tiny leak, theoretically would reveal your whole communication partner history.
 
The initial ClientHello in HTTPS sends the hostname of the site you want in plain text as part of the Server Name Indication field. The webserver uses this to send the correct TLS certificate back to the client. This is before any encryption parameters are exchanged. As you've noticed this is a privacy leak. There is a new thing called Encrypted Client Hello which aims to close this hole. See https://blog.cloudflare.com/encrypted-client-hello/ for information. It's still experimental though and not enabled in browsers by default yet. And it requires the website operator to add keys to DNS etc. too so it won't work with every website.
 
For firefox, it is enabled only if you use dns over https. But firefox does now allow .local domain, so you can't really use it with just unbound running on localhost.
 
You must log in or register to reply here.
Back
Top