deleted by creator
deleted by creator
deleted by creator
As someone knowledgeable on the subject, this was my journey:
Mozilla: “While HTTPS encryts web page contents, many middlemen can still see the URL of the sites you visit.”
Me: “Yes, we know this is a problem. It has been for a long time. But if you’re adding some kind of complex new solution, it’s going to cause issues for…”
Mozilla: “We added public key encryption to DNS.”
Me: “Oh shit, that’s really smart, and it’ll just work.”
The brilliance of this move is public key encryption is old and widely supported and DNS is old and universally supported. I think we will see broad support roll out quickly on this one (at least compared to glacial scale of changes across the Internet.)
This should also be done for CA keys. If ACME can make DNS ownership the source of trust, just let me stuff my own root CA cert in a DNS record and skip the middle man.
ECH is designed to interoperate with these practices and respect the existing DoH opt-outs in Firefox
This makes no sense. Just because I don’t want to bypass my local DNS server it shouldn’t leave my TLS Hello packets unencrypted.
I had missed this originally, very disappointing choice by Mozilla.
Ok, but how many servers support it?
All sites that are proxied through Cloudflare, even free tier. So it’s safe to say half of internet are supported ECH already.
That’s a low bar. I can’t even access most of those sites due to misconfiguration of the antibot settings.
I’m mostly asking for the websites that I run, which are not behind CF.
All of Cloudflare supports it
If a packet is traversing an ISP’s network the ISP should have to know where it is coming from and where it is going, right? So even if you “encrypt the first hello” packet, the ISP would still know where it was routed, right?
I’ll freely admit I have only a very basic (and likely outdated) understanding of IP networking, but I don’t see how this protects my browsing habits from my ISP. Even if they can’t understand my “hello” to lemmy.ml, they still know I’m talking to lemmy.ml’s IP address about something.
What am I missing?
Your ISP is mostly going to be seeing AWS, Azure, GCP, Cloudflare, etc IP addresses.
They would know you’re talking to that IP, not necessarily lemmy.ml. It is very common for multiple sites to be hosted on the same ip. The reason SNI exists is so the browser can tell the server which site it was looking for in an encrypted session. If it is 1:1 then it would be true.
If I understand correctly, someone other than your ISP could see the name of the website, since it isn’t encrypted. I think it would bounce through several servers that could possibly read the data.
Cloudflare fronts much of the internet, so all your ISP would see is that you connect to cloudflare, not which site you actually connect to.
In fact this was a big reason cloudflare and Amazon were angry with the signal foundation, for using domain front running, using the same trick in fascist countries to still be able to talk to signal servers
Yeah I think it has the same limitations that pretty much anything not through a vpn has because you still have to tell your isp where to send the data. Your isp will still see some things, even if it’s encrypted (metadata, DPI, habits, and things beyond my knowledge). This sounds like a step in the right direction for the majority of people though, even if it’s minor.
I kind of see it like differentiating between them seeing lemmy.ml via this vs lemmy.ml/thing-i-want-private/peronal.html without it, but I could be wrong about that.
HTTPS already prevents them from knowing exactly what content you’re looking at. Hiding SNI prevents them from knowing exactly what site you are connecting to via HTTPS.
They can still figure that out if you’re using unencrypted DNS or if there is a 1:1 IP to rDNS mapping though.
Does this rely on DOH? Seems like if I’m running my own recursive DNS that this won’t apply to me.
deleted by creator
It does not. ECH will work without DOH, but anybody listening can just see what site you’re querying from DNS instead of listening to SNI. Combining them is the most private.
Edit: This is wrong, in the sense that Mozilla has chosen to link the ECH setting with your DNS setting, even though they are separate. If you are using a local resolver, even if it is in turn using DoH or DNSCrypt upstream, Firefox won’t use ECH and will instead leak SNI information to your ISP. This is disappointing behavior that from another company would seem designed to coax you into a certain direction.
Not necessarily. You could use something like DNSCrypt locally as a resolver which is more private than DoH and this weird combination of the opt-out will hurt you in this case.
Yes I had missed the part of the article where they described their opt-out behavior.
There is no technical reason for them to do it that way and it is a poor way of automatically determining an opt-out for the sake of not pissing off enterprise users (who rely on SNI for filtering). It is needlessly hostile to tie this privacy future to a different one instead of just using a separate toggle and corporate policy setting. ECH isn’t DNS and shouldn’t be tied to the DNS server setting.
For a local annoying example, NextDNS automatically blocks DoH via the canary domain use-application-dns.net. If I set my router up to use NextDNS over DoH, Firefox automatically disables DoH and ECH internally. I want it to use my router’s DNS, because everything is centrally logged, automatically organized by hostname, and it does local caching. I’d still rather my ISP can’t view SNI information. If I want ECH I have to manually enable DoH on every machine, and do more hoops if I want central logging to work correctly.
Regarding no technical reason, you can return these public keys from any normal DNS:
$ dig +short crypto.cloudflare.com TYPE65 1 . alpn="http/1.1,h2" ipv4hint=162.159.137.85,162.159.138.85 ech=AEX+DQBBvgAgACCLKBP960E1dfY35YFbosHcVzvpz1E4fsqxzwGhtPpZagAEAAEAAQASY2xvdWRmbGFyZS1lY2guY29tAAA= ipv6hint=2606:4700:7::a29f:8955,2606:4700:7::a29f:8a55How so? I’m using unbound locally for recursive DNS, but I’ll checkout what DNSCrypt adds since it seems like local encrypted DNS to the recursive servers.
Wouldn’t ECH still work with this setup and this setup be more secure since you’re not handing off your DNS requests to some other company?
It would work, except Firefox is configured to not use ECH if it is not using DoH. I updated my original reply after testing it out. Hopefully they update this behavior in the future, it is very user-hostile right now.
Basically DNSCrypt is designed to hide your IP from the DNS server and your DNS query from your ISP. Basically it relays your DNS query via one server which knows your IP but only sees and encrypted version of your query and response and one server which knows your query but not your IP. Obviously you want both servers to be run by two different organizations.
Rare Mozilla Win.
Imagine if they did stuff like this every time.
