I'm sure you know this, but some readers might not. DNS is totally insecure. Even if you change your DNS server from the default to 1.1.1.1 or whatever, your ISP can and does still read and/or intercept these requests. This sort of interference is absolutely trivial to implement, even at scale. Don't think it isn't happening to you.
But I keep wondering: Can't the ISP trivially correlate the accessed IP addresses with their corresponding sites even without DNS query data?
You traded one master for another.
No. By definition, last mile ISP sees 100% of net-bound traffic. "Various CDNs" itself already represents a dilution of that view, and are not universal themselves. It's an inherent improvement even outside of other factors. But there are other factors, including a decrease in the level of natural monopoly. Last-mile ISPs often have zero effective competition, and even with one or two there are often high change over costs, longer term contracts involved, etc. The closer you get to the net's core however, the more bandwidth there is and the more players there are and in turn vastly more competition potential. That's not a guarantee sure, but it absolutely makes a difference. There's also a limiting factor principle at work: even if you do trust a given ISP, how does that help you avoid CDNs anyway?
It's the same reason that spinning up your own instance of an algo VPN on some VPS and funneling all your home and mobile traffic through that may have practical benefits. Sure in principle the VPS (or data center if you go on your own metal) provider could try spying as well. But competition there is fierce, the average technical level of users is higher, major business interests are involved in reputation, and swapping to another provider is utterly trivial. The incentives and business models for the likes of Amazon/DigitalOcean/Google/Microsoft/OVH/Scaleway/Vultr/[...] in their compute offerings are completely different from the likes of AT&T/Charter/Comcast/T-mobile/Verizon. So it is in fact reasonable to expect a difference in the level of shenanigans too, and hey, if not you can easily move, which also in turn makes it much easier as a practical matter to retaliate (sue), which virtuously further decreases the likelihood of shenanigans.
Advocating for ESNI on the other hand means argueing for more centralization towards entities which are far more removed from you where you have little recourse. So as far as incentives go they may be more beholden to some law enforcement agency than you the non-customer.
There are difference, but it does not appear to be an obvious improvement to me.
Different jurisdiction means less likely to be answerable to your local government should they be oppressive.
The fact you don't have a contractual relationship with a CDN is a good thing because it becomes trivial simply to stop using them, should the need arise. Don't like Cloudflare? block them. Your choice of websites will be reduced greatly but you still have an operational internet connection.
"What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf
So essentially ESNI/DoH are only useful for websites on global CDN providers? Why would Mozilla be interested in enhancing those companies profits?
Not if VPNs/firewalls are properly implmented. Plugging DNS leaks is security 101.
OTOH as the article says, 'Joining Mozilla's program means that Comcast agreed that it won't "retain, sell, or transfer to any third party (except as may be required by law) any personal information, IP addresses, or other user identifiers, or user query patterns from the DNS queries sent from the Firefox browser'.
I assume Mozilla will audit and keep Comcast honest here, or at least try. I just am left wondering what loophole Comcast has found.
It's not just Comcast. Every ISP that uses Akamai's software to power their ISP has this ability and possibly uses it, just not in obvious ways. And given that almost every ISP in the US, let alone the world, uses this software, well.. that's just how it is.
Though, it's http only. You can always switch to https and they can not do anything. There is no key injection or anything going on thankfully. Also, encrypted DNS should make it moot as well.
I found this out the hard way, because I browse nearly all HTTPS sites, and uBlock blocks the injected malware script on the few plaintext sites and never really noticed.
Your IP changes into a shared Comcast-run squid proxy one, all TCP ports are no longer available other than 80/443 filtered through squid, all UDP is no longer available.
When a request is sent for a http web page it is ran through the layer 4 proxy. In there is a user profile where http injection can occur. It works by injecting JavaScript into the end of the web page.
If the dns request is encrypted all of the handshaking goes through tls bypassing the proxy's view of this data for everything except disconnected http body data. However, it could be that as years have gone by it's been updated to take in http data without any sort of head and then it would work again. It's probably as simple as running some regex looking for </html>.
So, me in my half awake state this morning didn't really think it through. In previous versions of the software this wouldn't be supported, but in hindsight it's not a terribly difficult problem to fix, so Comcast probably does support HTTP injection even when using encrypted DNS by now. My apologies.
With technology there are many ways to achieve the goal of notifying a customer without foul play.
For non 1.1.1.1 dns users I can just set up varnish and they'll be served via GEO ip lookup so the domain gets pointed to the nearest ip address. This is much cheaper. I'm not going to buy an ipv4 block just for cloudflare dns users.
Their privacy claim is a lie because your webserver is going to be exposed to the end user i.p. address anyways after resolving from the nameserver.
This is a stupid decision by Mozilla. Too bad Firefox users when visiting websites making their own CDN's without anycast/country level redirects will see much slower sites.
Cloudflare has over 200 PoPs; in your own name servers, you can use the Cloudflare Resolver's IP (which will be a "close to the user" IP, not 1.1.1.1) to do geotargeting and serve from your closest IP address/server.
What if my server is closer than cloudflare? Why is cloudflare artificially limiting?
> Cloudflare is harmful to independent CDN's.
Cloudflare is a competitor to CDNs. You don't need to use a CDN with Cloudflare, they proxy your content fully and do caching along the way as needed.
> Their privacy claim is a lie because your webserver is going to be exposed to the end user i.p. address anyways after resolving from the nameserver.
It's not a lie. Cloudflare is the nameserver, and the CDN. So after resolution the end user still has just a Cloudflare IP.
> In 2011 Google wrote an IETF draft to send Client IP information using the EDNS0 extension and this is usually called ‘edns-client-subnet’. As a DNS client, it means that a truncated version of your IP address will be added into the DNS request. The DNS server will use this truncated IP address to make a more informed decision in how it responds so that you can be connected to the most optimal server. This standard is promoted by the Faster Internet initiative and already adopted by some leading vendors.
Because it is designed to keep privacy, the sender has the freedom to limit the client IP information. Instead of sending a full IP address, the DNS server is able to send partial information such as /24 only. For instance, if your IP address is 66.214.81.22, the DNS server will only expose the first three octets, so 66–214–81. Armed with the real IP address of the querying device, the DNS server can now come up with a much more accurate response. With this more intelligent routing, customers have a better Internet experience with lower latency and faster speeds. Best of all, this integration is being done using an open standard that is available for any company to integrate into their own platform.
source: https://engineering.salesforce.com/why-is-edns-important-for...
Cloudflare 1.1.1.1 for consumers kills EDNS "edns-client-subnet" and instead offers the ip of the nearest cloudflare server to the user even if the website is not using cloudflare. This means your website can not ever serve content faster then cloudflare even if you could potentially be faster.
This is the reason why many internet archives do not allow access to cloudflare client dns (1.1.1.1) users as a form of protest.
BTW, Cloudflare allows you to get informed about the end user's ip via a "x-forwarded-for" header.
It is also exceedingly unlikely that you have greater density of anycast PoPs than Cloudflare's 200+. In your case, you have zero...
If I compare cloudflare DNS vs Google DNS, I can see a difference of ~50ms between the Akamai POPs offered.
So now AFAIK the number of sites that block DNS resolvers which do not forward edns-client-subnet is zero. As it should be.
They also attempt to correlate .onion traffic.
You think that is bad ? If you get a connection from India's 'premier' public telco BSNL, you'll be treated to ad-injections for random malware straight into your HTTP page.
"Your govt. welcomes your appreciation for its 'top-notch' services."