The encrypted DNS proposals only cover securing the route to the recursive resolver. So the recursive resolver (your ISP, google, cloudflare) will still see all the sites you're visiting.

We also need encrypted DNS for the recursive lookup itself so you can run your own resolver somewhere.

The resolver is less of an issue because you have free choices there, ISP is harder to change. Plus you increase the number of parties that need to collude (ISP + RR provider) to spy on your traffic.

True. However these days pretty much everyone is colluding so there is that. Data bonanza.

> So the recursive resolver (your ISP, google, cloudflare)

Why not yourself? Your ISP can still see the RR working, of course.

> We also need encrypted DNS for the recursive lookup itself so you can run your own resolver somewhere.

This would indeed be optimal but would require upgrading a significant portion of authoritative name servers, sooo... might take a while.

> Why not yourself?

Well, then what attacker do you defend against if your laptop asks your router via DoT but then the router does an unencrypted recursive lookup anyway?

Who said laptop ? You can have a DNS resolver on a server somewhere you own, that way it can remain encrypted on your ISP's network.

I'm actually not sure exactly what the purpose of ESNI is but if you look at the implementation if the server you connecting to is publicly known then ESNI is not private. I might be missing something, but you can just build up a database of ESNI record_digest to server name mappings. The limitation being you can only build this up for servers you know about. Also, I guess it doesn't work for SSL servers that are terminating multiple domains because they are able to use the same key for a bunch of different domains. I guess this is the purpose of ESNI :)

That only works if the server you are visiting is behind a CDN with no resources served directly from the dedicated host.

The encrypted SNI would primarily be useful to make censorship and MITM attacks harder.

I'm don't completely get it. How does CDN is required for this?

Let's say that I have a Nginx on my server which serves a lot's of websites, and whose web sites can only be accessed through HTTPS with SNI, not HTTP.

Now with Encrypted SNI deployed, requests from my clients can still be dispatched to it's respective virtual hosts, but any sniffers in the middle of the connection should only be able to see that my clients are accessing to my server, but not which virtual host.

Is I'm missed anything? I haven't dig deep in to this currently.

That's about it.

The theory is that if you put your server behind a popular CDN, then a state-level attacker is left with little choice but to block the entire server.

Another benefit is that attacks that can observe but not modify traffic will be less able to track what sites you're visiting.

There are risks though:

* It's unclear how resistant CDNs actually are to state-level attackers.

* It's unclear how resistant CDNs are to regular attackers[1]

* Corporations/Security-savvy users will find it difficult to control what [their] workstations can reach and cannot: Allowing access to a single cloud-based service may inadvertently allow access to a malicious command/control server sharing the CDN.

[1]: https://9to5mac.com/2017/02/24/cloudflare-server-breach-clou...

That’s an accurate summary, but CDNs are important because they terminate huge numbers of sites. In your example censorship is relatively easy since network operators who want to block a site won’t have very much collateral damage by blocking your entire server just to deny access to that single site. CDNs, terminating millions of sites, make that far more challenging.

It misses the fact that even with encrypted SNI it would be very easy to fingerprint a website see my comment above.

Shared hosting can provide some “privacy” or to be more exact plausible deniability however it’s not going to be particularly good (when accounting for the actors that this would play at this level) especially when you consider that you can fingerprint the websites quite easily as the encrypted data would still of known size.

So if your website serves a page which is 412KB in size that would be quite easy to fingerprint especially across a pool of websites, beyond that it’s also quite possible to fingerprint things even further by measuring the number, size and order of secondary requests a page load incurs.

So overall there is little privacy that would be provided by this (again when taking into account the threat model and actors) unless you hide behind 1000s and 1000s of websites on the same network and even then it’s mostly not about privacy but about resilience against MITM and state censorship.

I think for the web to hold true to its ideas, there should have been a discussion of whether we want to have fully confidential connections on the internet. Sadly, this doesn't seem to have happened.

I don't think encryption hinders the true ideas of the web, it merely blocks malicious actors, of which there are many in almost all areas and connections.

The entire set of encryption can be easily opened up for inspection and manipulation if all parties agree this is good idea.

If all parties agree, yes. But that likely is not the case - e.g., an app developer would likely want to have maximum freedom in what data they send over the wire, while a user would want to minimize the amount of data transmitted (for simple cost reasons) and also control which personal and/or sensitive information is transmitted.

Encryption where the user does not control either of the endpoints stacks the odds in favor of developers and against users.

I agree however, that the situation for the web (e.g. everything that lives inside a browser) is still pretty good thanks to the ability to add custom root CAs and general user the browser's debugging and inspection tools.

However, if you try to find out what exactly a mobile app, a game console or an IoT device is doing, you soon find yourself out of luck even if you're the owner of those things.

The Remote IP is almost as sensitive as SNI right?

This proposal is generally for sites which are behind an edge network like Cloudflare. In that case your remote IP is the IP of the provider, not your actual server.

Not always, see domain fronting: https://en.m.wikipedia.org/wiki/Domain_fronting

Or services which use subdomains for individual users, e.g. #.github.io, #.tumblr.com, #.blogspot.tld and so on.

This. Currently, the difference between accessing github.com/blattimwind and blattimwind.github.io is that, in the second case, which username you're accessing is visible to all. Encrypted SNI will also protect that part of the URL.

Not necessarily, think CDNs or Shared IPs for Webspaces.

So in reality it is just as sensitive.

It can be as sensitive. But in the best case, shared IPs provide more anonymity.

As a responsible parent, you should not be relying on filtering to educate your children. Filters have more holes than Swiss cheese, often block entirely legitimate educational resources, make your children know that you don't trust them to be responsible, and learning about proxies and VPNs is trivial for them (just try googling "proxy servers unblock websites").

If you don't trust your children to use the internet responsibly, don't let them use it. Or let them use it but only under your supervision. If you let them go wild but put up filters, they will find a way around, one way or another, and at that point the princess is in another castle.

allowed domains:

en.wikipedia.org

I'm all for having discussions, but if you think the dichotomy should be "don't use the Internet at ALL" or "Talk to them about it and hope they're mature enough to avoid getting rick-rolled into rotten.com" then I heartily disagree.

allowed netname: WIKIMEDIA-EU-NET

problem solved

I agree on the most. When my kids grow older, I’ll teach them.

And the trick with local CA is awesome!

As parent you can install whatever SSL CA you'd like and make full MitM of your own devices. For everyone else it's very important to not leak any private information to ISP or any other party.