DNS Privacy Considerations(rfc-editor.org)
rfc-editor.org
DNS Privacy Considerations
https://www.rfc-editor.org/rfc/rfc9076.html
32 comments
IMO the current effort isn't about improving privacy or reducing censorship or a battle to stop tracking. It's a battle for who gets to track you. Winning market share in the DoH space is the same as winning the ability to control one of the only hops where users can be tracked.
I think it's worse than having a ton of crappy ISPs doing DNS. Yeah, they probably sold my data to shady businesses, but DoH has the potential to be a much better mass surveillance and censorship system. Is it easier to get a US court order for Cloudflare and Google to block the pirate bay via DNS or to get 1k court orders from 1k jurisdictions around the world?
And the "benefit" we're going to get as users is un-blockable ads because that's the ultimate goal of DoH. Instead of my Roku trying to use 8.8.8.8 it'll use some DoH server at a CDN that's hard/impossible to block.
They're literally building the next generation surveillance / censorship system and selling it to us as "for your protection".
I think it's worse than having a ton of crappy ISPs doing DNS. Yeah, they probably sold my data to shady businesses, but DoH has the potential to be a much better mass surveillance and censorship system. Is it easier to get a US court order for Cloudflare and Google to block the pirate bay via DNS or to get 1k court orders from 1k jurisdictions around the world?
And the "benefit" we're going to get as users is un-blockable ads because that's the ultimate goal of DoH. Instead of my Roku trying to use 8.8.8.8 it'll use some DoH server at a CDN that's hard/impossible to block.
They're literally building the next generation surveillance / censorship system and selling it to us as "for your protection".
> And the "benefit" we're going to get as users is un-blockable ads because that's the ultimate goal of DoH. Instead of my Roku trying to use 8.8.8.8 it'll use some DoH server at a CDN that's hard/impossible to block.
Can you not set the DNS server just as you do today? Or are you rewriting the IP for 8.8.8.8 to a private server and worried that HTTPS will prevent this?
Can you not set the DNS server just as you do today? Or are you rewriting the IP for 8.8.8.8 to a private server and worried that HTTPS will prevent this?
I think 8.8.8.8 is hard coded somewhere in those devices. I can’t remember exactly how it worked, but it’ll ignore the dhcp assigned dns sometimes.
With DoH it’ll be impossible to block and I think there’s a good chance they’ll flat out ignore local dns at that point.
With DoH it’ll be impossible to block and I think there’s a good chance they’ll flat out ignore local dns at that point.
That's why you block port 53 in both UDP and TCP so nothing can bypass it. I also block most known DoH servers outright.
I also block most known DoH servers outright.
When someone hosts a DoH server on a cdn/AWS/Azure/Google shared IP address, you can't block it by IP; and if the client uses ESNI, you can't block it by HTTP header inspection either.
When someone hosts a DoH server on a cdn/AWS/Azure/Google shared IP address, you can't block it by IP; and if the client uses ESNI, you can't block it by HTTP header inspection either.
How will the client know what address to send DoH to? You wouldn't just hardcode an IP unless you want that predictable address manually blocked in the firewall.
>That's why you block port 53 in both UDP and TCP so nothing can bypass it.
Already done...something is still sneaking through...or cloudflares test is unreliable (or my iptables rules are wrong lol)
Already done...something is still sneaking through...or cloudflares test is unreliable (or my iptables rules are wrong lol)
The most severe, currently completely unresolved, DNS based privacy thread is not even mentioned in the RFC:
https://www.ndss-symposium.org/wp-content/uploads/2019/02/nd...
https://www.ndss-symposium.org/wp-content/uploads/2019/02/nd...
Out of curiosity, I once used wireshark to examine packets from my own system which was configured to use DNS over HTTPS (using dnscrypt-proxy). I discovered that the hostname of the server is in plaintext in a header of a packet separate of the DNS query packets. I think this is due to verification of HTTPS certs, but not sure. By what I've discovered, AFAIK that to completely obscure the server's hostname from the currently used ISP, a VPN (or proxy) is probably necessary.
As well as SNI which is mentioned in an existing thread, it's possible you were seeing OCSP the Online Certificate Status Protocol. This is particularly likely if the packet was going to a completely different server.
OCSP is a plaintext (the answers are actually signed but they aren't encrypted) protocol to assure your client that the certificate it's looking at hasn't been revoked.
The correct fix for privacy is that OCSP Stapling should be used. Instead of clients fetching OCSP answers and thereby revealing who they're talking to, the server should pre-emptively fetch OCSP answers about its own certificates, and "staple" the latest good answer to its certificate, saying "Look, here's proof my certificate is still good". This stapled answer is then provided to the client, over the encrypted TLS connection, since OCSP is signed the client can trust this stapled answer and needn't fetch it themselves.
DoH servers should definitely have OCSP stapling. I'm sure the big famous ones do.
OCSP is a plaintext (the answers are actually signed but they aren't encrypted) protocol to assure your client that the certificate it's looking at hasn't been revoked.
The correct fix for privacy is that OCSP Stapling should be used. Instead of clients fetching OCSP answers and thereby revealing who they're talking to, the server should pre-emptively fetch OCSP answers about its own certificates, and "staple" the latest good answer to its certificate, saying "Look, here's proof my certificate is still good". This stapled answer is then provided to the client, over the encrypted TLS connection, since OCSP is signed the client can trust this stapled answer and needn't fetch it themselves.
DoH servers should definitely have OCSP stapling. I'm sure the big famous ones do.
Alternatively we could get shorter lifetime certificates. I hope for a day where ocsp becomes unnecessary because certs are only valid for a day or two.
This is a TLS mechanism called SNI and yes, it's there to make sure one server can deliver multiple different hosts over TLS.
There's a mechanism called Encrypted ClientHello (ECH), formerly known as ESNI, that tries to address this. Ultimately using either DoH or ECH only provides limited protection, the idea is to use both.
There's a mechanism called Encrypted ClientHello (ECH), formerly known as ESNI, that tries to address this. Ultimately using either DoH or ECH only provides limited protection, the idea is to use both.
Oh I see, thanks for the reply. I did a quick search and came upon https://blog.cloudflare.com/encrypted-client-hello/ which does shed light on ECH. Though I am not sure if only Cloudflare-backed servers provide ECH, or if it is even available. Seems relatively new.
EDIT: Ah, the blog post does indicate that ECH is a work in progress.
EDIT: Ah, the blog post does indicate that ECH is a work in progress.
It is likely that ECH will be a GREASEd "big bang" deployment for various practical reasons.
What that means is, one day you'll get a new browser update and from then all your TLS connections will seem to use ECH, however, since most servers don't speak ECH most of your connections will have an unencrypted Hello as usual and then the ECH payload they carry is actually random noise.
Then, gradually over time, sites do have ECH and the connections to those sites use a cover name in the outer Hello with the real name protected by ECH instead of noise in the ECH data.
I would anticipate this beginning probably in the next 12-18 months once ECH is nailed down completely and ready to be published.
What that means is, one day you'll get a new browser update and from then all your TLS connections will seem to use ECH, however, since most servers don't speak ECH most of your connections will have an unencrypted Hello as usual and then the ECH payload they carry is actually random noise.
Then, gradually over time, sites do have ECH and the connections to those sites use a cover name in the outer Hello with the real name protected by ECH instead of noise in the ECH data.
I would anticipate this beginning probably in the next 12-18 months once ECH is nailed down completely and ready to be published.
Note that ECH must be supported on both ends. So it’s required on the browser (or OS or application) too.
while it is easy to see the desired hostname for an SSL connection that makes use of SNI it is also very easy to simply connect to the address someone is communicating with and see what certificate is presented to you. it probably even works by just intercepting it... that keeps being practical as long as non SNI enabled connection or let alone ECH enabled ones are expected to work as well...
Unless it deliberately doesn't need a name (e.g. DoH servers like 1.1.1.1 or 8.8.8.8) TLS servers have no reason to respond to connections that don't specify a name with anything other than confused dismay. "Um, who are you calling?".
It's a misfeature of some common web server software that you get a "default" web site as if this was still 1998 and your web browser might not know about HTTP 1.1 yet. The specification doesn't suggest doing this as far as I know and it has caused numerous security problems.
Likewise ALPN. The client has to say which ALPNs they'd accept for this connection if any, and the server just picks one. The server is under no obligation to hint that it knows any particular ALPN or to let you connect without specifying.
It's a misfeature of some common web server software that you get a "default" web site as if this was still 1998 and your web browser might not know about HTTP 1.1 yet. The specification doesn't suggest doing this as far as I know and it has caused numerous security problems.
Likewise ALPN. The client has to say which ALPNs they'd accept for this connection if any, and the server just picks one. The server is under no obligation to hint that it knows any particular ALPN or to let you connect without specifying.
what i do is somewhat like you suggest. if haproxy cant determine which hostname it should serve it responds with a "503 Service Unavailable". However, if i expect someone to be able to actually receive that i still need to present a certificate to the client. i use wildcard certificates for this reason. the server wont tell you what names would actually work... you could just terminate connections or signal some kind of handshake error immediately instead though... most sites and services aren't likely to do that as its not very helpful in figuring out why it went wrong or explicitly will try to make it work for clients not supporting this. that's why i noted it being practical as long as incompatible clients are expected to work...
TLS has a specific error "alert" unrecognised_name (112) that servers should send if the client doesn't provide a name they recognise (or indeed doesn't provide a name at all and they expected one).
If a web browser connects without specifying a name and it hoped to reach some.nonsense.example your wildcard certificate doesn't help it and it won't display your 503 Service Unavailable error, you aren't some.nonsense.example, it cannot proceed, so you shouldn't bother trying to "help".
If a web browser connects without specifying a name and it hoped to reach some.nonsense.example your wildcard certificate doesn't help it and it won't display your 503 Service Unavailable error, you aren't some.nonsense.example, it cannot proceed, so you shouldn't bother trying to "help".
that's interesting i will investigate how to make use of that, thanks :)
EDIT: its really pretty easy to do apparently[0] although only unconditionally as it seems...
[0] https://cbonte.github.io/haproxy-dconv/2.4/configuration.htm...
EDIT: its really pretty easy to do apparently[0] although only unconditionally as it seems...
[0] https://cbonte.github.io/haproxy-dconv/2.4/configuration.htm...
This one doesn’t mention other channels of leaks such as SNI (Server Name Indication) used with TLS. Between this and related RFCs (like RFC 8932: Recommendations for DNS Privacy Service Operators), it looks like better privacy on DNS is still several years away.
Tor or a trusted VPN could help to an extent, but I personally don’t see either of these as viable for all online access all the time.
Running one’s own resolver on the cloud isn’t something most people can do (even though it doesn’t, and cannot, cover all the points mentioned here).
Tor or a trusted VPN could help to an extent, but I personally don’t see either of these as viable for all online access all the time.
Running one’s own resolver on the cloud isn’t something most people can do (even though it doesn’t, and cannot, cover all the points mentioned here).
> Privacy-focused users should be aware of the potential for additional client identifiers in DoH compared to DoT and may want to only use DoH client implementations that provide clear guidance on what identifiers they add.
Yep. I was always wondering whats the deal with http cookies in DoH.
Yep. I was always wondering whats the deal with http cookies in DoH.
DNS is a rare instance where some sort of blockchain strategy might make sense. The centralisation of the root DNS servers is a risk to the internet. It is a matter of time before they become highly political.
I tried to buy some of those. IMO, it's all DOA because the crypto currency end of it makes it too hard to deal with. I wanted a Handshake domain and a .eth domain. I even set up an account at an exchange to buy crypto which involved giving a TON of personal information / ID to satisfy KYC/AML regulations (in Canada).
I gave up eventually. I realized I couldn't figure out exactly how the ENS domain registration worked, how much it actually costed because of volatility and gas prices, and I didn't know if it would be 1 (ETH purchase), 2 (+ ENS purchase), or 3 (+ ETH sale) taxable events triggered by the transaction(s).
After giving up on the ENS stuff I signed up for a namebase.io account and realized I'd have to give them all the same KYC/AML info I gave the other exchange. Since they're not even regulated by my country's regulator (FINTRAC), there's zero chance I'm giving them all that info. Plus, all the tax stuff related to the .eth domains would apply, so I just gave up.
I wanted domains, not crypto assets :-(
I gave up eventually. I realized I couldn't figure out exactly how the ENS domain registration worked, how much it actually costed because of volatility and gas prices, and I didn't know if it would be 1 (ETH purchase), 2 (+ ENS purchase), or 3 (+ ETH sale) taxable events triggered by the transaction(s).
After giving up on the ENS stuff I signed up for a namebase.io account and realized I'd have to give them all the same KYC/AML info I gave the other exchange. Since they're not even regulated by my country's regulator (FINTRAC), there's zero chance I'm giving them all that info. Plus, all the tax stuff related to the .eth domains would apply, so I just gave up.
I wanted domains, not crypto assets :-(
That's not a new idea, see https://en.wikipedia.org/wiki/Alternative_DNS_root for a list of alternatives, and https://datatracker.ietf.org/doc/html/rfc2826 for arguments against them.
Handshake (https://handshake.org) is a good option here which tries to be somewhat compatible with the old system.
Yeah I found this project several years ago and concluded it was the most holistic solution. Problem is it doesn't have as easy onboarding as projects which only seek to replace singular TLDs with non-ICANN-centralised DNS such as Namecoin and the Ethereum Name Service.
When you think you've got a grip on it there are leaks. pihole and cloudflared tunnel set up? Nope FF just bypasses it. Something still leaking? oh that's ipv6. Still no good? Oh DNS can bypass your port 53 firewall rule cause udp fallback. etc etc.
Oh and good luck testing it. Different results in FF/Chrome/Edge...and sometimes even variability between tests per browser. Hows that even possible with 53 FW blocked? No idea