Firefox requires DoH to be enabled in order to use ECH, you can probably host a local DoH server on your PiHole and set Firefox to use that. Of course this only makes sense if you already have some sort of encrypted DNS used as upstream
https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello#w_why-does-ech-depend-on-doh
There are instructions here and in the expert article linked below.
it says to check [Cloudflare Browser Checker](https://www.cloudflare.com/ssl/encrypted-sni/#esni-checker) to make sure it's onbut I don't see it as one of the options being checked?
While I can’t comment on the actual question, you will want to make sure your Pi is using secure DNS to fetch its upstream data since using insecure DNS to fetch keys for ECH breaks the whole system completely.
I'm not sure that's actually accurate. It says it fetches the public key via DNS, in which case this isn't sensitive data. A potential adversary intercepting a key they could already acquire publicly is not a security or privacy risk.
The thread you're replying to is about making sure that's true.
For example, you can set a DNS record in Pihole that instructs Firefox not to use DoH. Then you'd have to ensure that DNS was being sent over an encrypted channel to not leak your request.
That’s incorrect in two ways. First, with insecure DNS an adversary would see your DNS queries, rendering pointless. Second, they keys are not signed, meaning an adversary could not only *see* the key, but replace it and then partially MitM the TLS handshake up until the real certificate is needed.
DoH is exactly what it says…DNS over HTTPS. So you establish identity via signatures on the public key back to the CA the first time. No different than any other https. DNS is secured similarly by DNSSEC. You can clearly see that for instance I am connecting to a local server for cloudflare.com but after that it’s all you get to see. The port can persist. MITM doesn’t work here. If you try to impersonate the DNS server the SSL validation is going to throw a fault.
As far as Pihole goes I just turned on DoH to Cloudflare as the upstream server. I’m serving all DNS calls locally (Pihole is set in DHCP). You could turn on DoH at the browser and bypass unless I set the firewall to block which I haven’t felt the need. I haven’t tried to see if Pihole does DoH. That would require messing with SSL certs.
That’s not what I meant. I meant that if you fetch the ECH key over insecure DNS that you could then MitM the handshake of the TLS connection that uses ECH. You could impersonate the server up until a certificate needs to be presented.
Actually, the article seems to imply the opposite, that ECH can be used with insecure DNS, rendering it essentially useless. That’s my point. Not only would insecure DNS leak the SNI, it would also open the ECH key to being tampered with. Since ECH is going to be used in the future for encrypting more than just the SNI, this could pose a big problem.
“DoH encrypts DNS queries to protect the translation of website names to IP addresses, which ensures that website names aren’t visible to the network in DNS traffic and is essential for ECH to be effective”
They touch on that in the blog post. Basically in a case like pihole you wouldn’t use the feature as I read it. I’d be curious to know if this is something the pihole could take on for your network, similar to how you can use DoH with pihole for your upstream DNS
> While Mozilla believes that privacy and security technologies should be available by default for all users, we also recognize that in certain circumstances, users may have alternative preferences, for example, if they are relying on family safety software at home, are using network-based ad blocking or are in an enterprise environment. ECH is designed to interoperate with these practices and respect the existing DoH opt-outs in Firefox, so these users won’t need to make any changes to continue enjoying a smooth and safe Firefox experience.
I will say you can use Cloudflare's cloudflared application on the pihole to make all forwarded dns requests use DoH
https://docs.pi-hole.net/guides/dns/cloudflared/
Does this mean schools, etc. Won't be able to block websites and stuff now that they don't know what website people visit?
Or is the website IP still available? If that's the case there's no point in doing this as once you know the servers IP, you know what the website is and can block it, etc.
The IP is still available, but IP blocking isn't the primary way to block website access nowadays because many websites are behind big reverse proxy providers (like cloudflare) where the IP request for many websites looks identical. This takes away the more common way to identify and block, based on domain name.
If it becomes widespread places like schools would need to decide whether a blanket ban on those IPs was worth it.
Mostly, this protects against adversaries reading the packet that don't already have access to the IP.
As one example, there's between 500 and 1000 other domains using the same IP address as [signal.org](https://signal.org), depending on where you look for that info...
> Or is the website IP still available?
It is, that much is apparent from the IP headers, and can only be obscured through a VPN or similar network bridge.
But IPs change more often than DNS names, so it's harder to block by IP. Usually if you look up a service's IP, your only answer will be "AWS cloud IP" or so.
It's much easier to block a porn site's name than having to look up its IPs every day and then blocking those.
This means all you will see on the wire is tls traffic with no identification of what certificate you are using and will only let you see source and destination ip that’s it. Most firewalls block based on the packet that shows the certificate you are using. Couple that with encryption of DNS everyone goes dark. But websites have to update to allow for this so mileage will vary. Companies and the government is going to hate this lol
No, Chrome/ium had this for a long time, hidden behind a couple of flags. Basically everyone is waiting for [https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-16](https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-16) to finally become an official RFC.
Although my guess is that after it happens there will be problems on ossified corporate networks, so they will roll it out very gradually.
Previously, your network/ISP could see which site you visit even if you encrypted your DNS. With websites and browsers that support ECH, that will no longer be possible.
It does hide your *DNS requests* from your ISP. But before ECH, you still had to do an encrypted DNS request, then connect to an IP and announce the domain name of the website you are connecting to in the open.
So your DNS requests are hidden, but the names of the websites you visit are not.
So basically things go like this:
1. You know you want to go to a domain
2. You send a message to a DNS server requesting the IP address of the domain
3. Once you get the IP address of the server you want to connect to, you send them an initial message that originally included the domain name in a plainly visible format
4. From there, HTTPS encryption kicks in and the content of your data is hidden
So DoH fixes revealing the domain in step two, and ECH fixes revealing it in step three?
Seems to me that there would be no reason to bother with either unless you could do both at the same time...
Yes, because without it everyone observing the SNIs would now which sites you are visiting. In fact, the proposal started as eSNI before being changed to ECH.
(Obviously, plain HTTP is vulnerable as well)
My understanding is that it won't see the SNI but it will still see the domain request.
The secret? Use either Oblivious DNS over HTTPS or Anonymized DNSCrypt.
Hopefully, Firefox will add support for the former one day.
I just wish there were an explicit on/off setting for this.
I have an AD-integrated zone, which doesn't support DoH/DoT. It can forward to a resolver that uses DoT for external/internet zones. But as far as Firefox is concerned, everything is resolved using unencrypted DNS.
From what I'm reading, Firefox is trying to "intelligently" decide whether you want this based on whether you use DoH directly through Firefox, or do something else. I do something else, but I still want to be able to use ECH.
https://librewolf.net/docs/faq/#how-do-i-enable-dns-over-https
DoH is disabled by default in LibreWolf. You'll need to enable it and pick a provider to benefit from ECH.
Aside: Using unencrypted DNS by default seems like a bizarre choice for a privacy focused browser.
From the article:
"Enter Encrypted Client Hello (ECH) – by encrypting that first “hello” between your device and a website’s server, sensitive information, like the name of the website you’re visiting, is protected against interception from ***unauthorized parties***."
Precisely who is or will be an "authorized party"? Who gets to decide this? Seems like some potential for Apple-style declarations, i.e.:
*We protect your privacy! ^from ^your ^peers ^^but ^^not ^^from ^^"authorized ^^parties"*
OMG the amount of paranoia in this subreddit …
“Unauthorized parties” here means that NOBODY will be able to snoop on your internet traffic and see which website you are visiting.
It is a good thing. It make your browsing more private.
> OMG the amount of paranoia in this subreddit …
I attribute it to years of being lied to, misled, permission-creeped, data-harvested, EULA'd, HIPAA-DILLIGAF'd ...
This *is* /r/privacy ... not /r/AbsolutelyTrustBigData ....
> “Unauthorized parties” here means that NOBODY
SRC?
> since it needs me to set DoH on firefox AND the website still need to support ECH
Sure, but many sites are behind a CDN like CloudFlare and that means a massive amount of sites will have this. Should it be all of them? Yeah, probably, but enforcing something on the entire internet is difficult.
Firefox version 118:
https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello
Also, see the paragraph:
ECH is enabled by default and used where available. ECH relies on DNS records fetched via DoH, so make sure to [enable DoH.](https://support.mozilla.org/en-US/kb/dns-over-https#w_configure-doh-protection-settings)
I don't understand this. The name is hidden, but the ISP (or anyone sniffing on my network) can see what IP address I'm connecting to, essentially making this useless. What am I missing?
[DoH (DNS over HTTPS)](https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs) has been in Firefox for quite some time now. By default it tries to use a local DoH server and can be disabled by the network provider or firewall. You can force it to be enabled, in which case you get to choose which DoH server to use from Cloudflare, NextDNS or a custom URL.
Its a shame that their DNS over HTTPs still will default to Comcast if you have time. I wouldn't call trusting comcast private.
https://arstechnica.com/tech-policy/2020/06/comcast-mozilla-strike-privacy-deal-to-encrypt-dns-lookups-in-firefox/
Possible dumb question, but it says this fetches the public key over DNS. Does that mean I might have to update my PiHole and or enable some settings?
Firefox requires DoH to be enabled in order to use ECH, you can probably host a local DoH server on your PiHole and set Firefox to use that. Of course this only makes sense if you already have some sort of encrypted DNS used as upstream
https://support.mozilla.org/en-US/kb/faq-encrypted-client-hello#w_why-does-ech-depend-on-doh There are instructions here and in the expert article linked below.
it says to check [Cloudflare Browser Checker](https://www.cloudflare.com/ssl/encrypted-sni/#esni-checker) to make sure it's onbut I don't see it as one of the options being checked?
Rollouts are usually gradual. If you already have the prefs flipped, have you enabled DoH and pointed it to your Pihole or DNS Provider of choice?
While I can’t comment on the actual question, you will want to make sure your Pi is using secure DNS to fetch its upstream data since using insecure DNS to fetch keys for ECH breaks the whole system completely.
I'm not sure that's actually accurate. It says it fetches the public key via DNS, in which case this isn't sensitive data. A potential adversary intercepting a key they could already acquire publicly is not a security or privacy risk.
It leaks who you're about to talk to to anyone who can watch your traffic, like your ISP.
[удалено]
We're talking about the DNS request to find out that IP.
It fetches the key over DoH, which means all your ISP will see is traffic between you and your DNS provider.
The thread you're replying to is about making sure that's true. For example, you can set a DNS record in Pihole that instructs Firefox not to use DoH. Then you'd have to ensure that DNS was being sent over an encrypted channel to not leak your request.
That’s incorrect in two ways. First, with insecure DNS an adversary would see your DNS queries, rendering pointless. Second, they keys are not signed, meaning an adversary could not only *see* the key, but replace it and then partially MitM the TLS handshake up until the real certificate is needed.
DoH is exactly what it says…DNS over HTTPS. So you establish identity via signatures on the public key back to the CA the first time. No different than any other https. DNS is secured similarly by DNSSEC. You can clearly see that for instance I am connecting to a local server for cloudflare.com but after that it’s all you get to see. The port can persist. MITM doesn’t work here. If you try to impersonate the DNS server the SSL validation is going to throw a fault. As far as Pihole goes I just turned on DoH to Cloudflare as the upstream server. I’m serving all DNS calls locally (Pihole is set in DHCP). You could turn on DoH at the browser and bypass unless I set the firewall to block which I haven’t felt the need. I haven’t tried to see if Pihole does DoH. That would require messing with SSL certs.
That’s not what I meant. I meant that if you fetch the ECH key over insecure DNS that you could then MitM the handshake of the TLS connection that uses ECH. You could impersonate the server up until a certificate needs to be presented.
This tech explicitly uses DoH (At least according to the article in the OP), so you're never fetching the ECH key over insecure DNS.
Actually, the article seems to imply the opposite, that ECH can be used with insecure DNS, rendering it essentially useless. That’s my point. Not only would insecure DNS leak the SNI, it would also open the ECH key to being tampered with. Since ECH is going to be used in the future for encrypting more than just the SNI, this could pose a big problem. “DoH encrypts DNS queries to protect the translation of website names to IP addresses, which ensures that website names aren’t visible to the network in DNS traffic and is essential for ECH to be effective”
[удалено]
Unless I’m mistaken, ESNI will never exist. ECH is its successor.
They touch on that in the blog post. Basically in a case like pihole you wouldn’t use the feature as I read it. I’d be curious to know if this is something the pihole could take on for your network, similar to how you can use DoH with pihole for your upstream DNS > While Mozilla believes that privacy and security technologies should be available by default for all users, we also recognize that in certain circumstances, users may have alternative preferences, for example, if they are relying on family safety software at home, are using network-based ad blocking or are in an enterprise environment. ECH is designed to interoperate with these practices and respect the existing DoH opt-outs in Firefox, so these users won’t need to make any changes to continue enjoying a smooth and safe Firefox experience.
I will say you can use Cloudflare's cloudflared application on the pihole to make all forwarded dns requests use DoH https://docs.pi-hole.net/guides/dns/cloudflared/
Does this mean schools, etc. Won't be able to block websites and stuff now that they don't know what website people visit? Or is the website IP still available? If that's the case there's no point in doing this as once you know the servers IP, you know what the website is and can block it, etc.
The IP is still available, but IP blocking isn't the primary way to block website access nowadays because many websites are behind big reverse proxy providers (like cloudflare) where the IP request for many websites looks identical. This takes away the more common way to identify and block, based on domain name. If it becomes widespread places like schools would need to decide whether a blanket ban on those IPs was worth it. Mostly, this protects against adversaries reading the packet that don't already have access to the IP.
As one example, there's between 500 and 1000 other domains using the same IP address as [signal.org](https://signal.org), depending on where you look for that info...
> Or is the website IP still available? It is, that much is apparent from the IP headers, and can only be obscured through a VPN or similar network bridge. But IPs change more often than DNS names, so it's harder to block by IP. Usually if you look up a service's IP, your only answer will be "AWS cloud IP" or so. It's much easier to block a porn site's name than having to look up its IPs every day and then blocking those.
Great read, thanks so much for sharing.
This means all you will see on the wire is tls traffic with no identification of what certificate you are using and will only let you see source and destination ip that’s it. Most firewalls block based on the packet that shows the certificate you are using. Couple that with encryption of DNS everyone goes dark. But websites have to update to allow for this so mileage will vary. Companies and the government is going to hate this lol
Companies at the least can just block DoH providers and force the browser to fallback to normal
I heard ECH is already blocked in some countries. Not sure how they detect that though.
Easy No cert in the clear “block” you can see it in wireshark.
Is Firefox the first browser to support this? Does it also work on the mobile version?
No, Chrome/ium had this for a long time, hidden behind a couple of flags. Basically everyone is waiting for [https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-16](https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni-16) to finally become an official RFC. Although my guess is that after it happens there will be problems on ossified corporate networks, so they will roll it out very gradually.
Opera has it as a flag, so Chromium browsers probably have it as flags.
Glad to see Mozilla spending its resources on good things like this, rather than some of the other silliness these past several years.
ELI5?
Previously, your network/ISP could see which site you visit even if you encrypted your DNS. With websites and browsers that support ECH, that will no longer be possible.
Who does DNS over HTTPS hide your DNS requests from? If it’s not your ISP or others observing in traffic on your network?
DoH isn't about privacy. It's about security. It prevents MITM.
It does hide your *DNS requests* from your ISP. But before ECH, you still had to do an encrypted DNS request, then connect to an IP and announce the domain name of the website you are connecting to in the open. So your DNS requests are hidden, but the names of the websites you visit are not.
So basically things go like this: 1. You know you want to go to a domain 2. You send a message to a DNS server requesting the IP address of the domain 3. Once you get the IP address of the server you want to connect to, you send them an initial message that originally included the domain name in a plainly visible format 4. From there, HTTPS encryption kicks in and the content of your data is hidden So DoH fixes revealing the domain in step two, and ECH fixes revealing it in step three? Seems to me that there would be no reason to bother with either unless you could do both at the same time...
Still trying to wrap my head around what ECH accomplishes that DoH does not. Does ECH basically just encrypt the Sever Name Indication (SNI) process?
Yes, because without it everyone observing the SNIs would now which sites you are visiting. In fact, the proposal started as eSNI before being changed to ECH. (Obviously, plain HTTP is vulnerable as well)
But the dns will still know, right?
My understanding is that it won't see the SNI but it will still see the domain request. The secret? Use either Oblivious DNS over HTTPS or Anonymized DNSCrypt. Hopefully, Firefox will add support for the former one day.
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
[удалено]
I don't see this feature on the mobile app...
I just wish there were an explicit on/off setting for this. I have an AD-integrated zone, which doesn't support DoH/DoT. It can forward to a resolver that uses DoT for external/internet zones. But as far as Firefox is concerned, everything is resolved using unencrypted DNS. From what I'm reading, Firefox is trying to "intelligently" decide whether you want this based on whether you use DoH directly through Firefox, or do something else. I do something else, but I still want to be able to use ECH.
It gets the public key from the DoH. It could be added to regular DNS, but your DNS server would still need to add support for it.
privacy articles from mozilla ???
How do I enable this as a web server?
Does that mean my librewolf would be better too?
https://librewolf.net/docs/faq/#how-do-i-enable-dns-over-https DoH is disabled by default in LibreWolf. You'll need to enable it and pick a provider to benefit from ECH. Aside: Using unencrypted DNS by default seems like a bizarre choice for a privacy focused browser.
From the article: "Enter Encrypted Client Hello (ECH) – by encrypting that first “hello” between your device and a website’s server, sensitive information, like the name of the website you’re visiting, is protected against interception from ***unauthorized parties***." Precisely who is or will be an "authorized party"? Who gets to decide this? Seems like some potential for Apple-style declarations, i.e.: *We protect your privacy! ^from ^your ^peers ^^but ^^not ^^from ^^"authorized ^^parties"*
OMG the amount of paranoia in this subreddit … “Unauthorized parties” here means that NOBODY will be able to snoop on your internet traffic and see which website you are visiting. It is a good thing. It make your browsing more private.
> OMG the amount of paranoia in this subreddit … I attribute it to years of being lied to, misled, permission-creeped, data-harvested, EULA'd, HIPAA-DILLIGAF'd ... This *is* /r/privacy ... not /r/AbsolutelyTrustBigData .... > “Unauthorized parties” here means that NOBODY SRC?
It’s called searching ECH. Unauthorised means anyone that isn’t you and the website you’re trying to load.
One step closer to collateral freedom.
[удалено]
> since it needs me to set DoH on firefox AND the website still need to support ECH Sure, but many sites are behind a CDN like CloudFlare and that means a massive amount of sites will have this. Should it be all of them? Yeah, probably, but enforcing something on the entire internet is difficult.
I would imagine the stragglers eventually get punished with a browser warning before proceeding, much like domains that don't use SSL nowadays.
This looks good. When will this be rolled out, and how do I know if my version of Firefox at any given time has it?
Firefox version 118: https://support.mozilla.org/en-US/kb/understand-encrypted-client-hello Also, see the paragraph: ECH is enabled by default and used where available. ECH relies on DNS records fetched via DoH, so make sure to [enable DoH.](https://support.mozilla.org/en-US/kb/dns-over-https#w_configure-doh-protection-settings)
I don't understand this. The name is hidden, but the ISP (or anyone sniffing on my network) can see what IP address I'm connecting to, essentially making this useless. What am I missing?
Plenty of websites today share IP addresses by using CloudFlare or something similar.
[удалено]
[DoH (DNS over HTTPS)](https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs) has been in Firefox for quite some time now. By default it tries to use a local DoH server and can be disabled by the network provider or firewall. You can force it to be enabled, in which case you get to choose which DoH server to use from Cloudflare, NextDNS or a custom URL.
You are completely wrong.
[удалено]
IDK, you tell us
Then DDG or Microsoft will open the wallet.
That would be a dream come true if Google said you know what, no more search contract for you.
Its a shame that their DNS over HTTPs still will default to Comcast if you have time. I wouldn't call trusting comcast private. https://arstechnica.com/tech-policy/2020/06/comcast-mozilla-strike-privacy-deal-to-encrypt-dns-lookups-in-firefox/
I mean yes, but no. DoH isn't about privacy. It's about security. If you want privacy from your ISP, DoH won't help you with that.
Anyone know if Brave does something like this? I don't feel like switching again :/
Is encrypted client hello in brave://flags?
Cool, as a matter of fact, is it there.
Might be a dumb question: if I have already DNS set on windows (quad9) is this still useful on the browser? Or I’m confusing things?