21 ms·
This is amazing work, can't wait for this to be finished and deployed on the internet. Together with encrypted DNS (DoT and DoH) we finally get fully confidenti
by tscs37 8y ago
This is amazing work, can't wait for this to be finished and deployed on the internet. Together with encrypted DNS (DoT and DoH) we finally get fully confidential connections to a server without leaking anything other than Remote IP.
- dogma1138 8y agoThat 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.
- rqs 8y agoI'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.
- deleted 8y ago[deleted]
- reaperhulk 8y agoThat’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.
- dogma1138 8y agoIt misses the fact that even with encrypted SNI it would be very easy to fingerprint a website see my comment above.
- geocar 8y agoThat'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-cloudbleed-uber-fitbit-okcupid/ https://9to5mac.com/2017/02/24/cloudflare-server-breach-clou...
- dogma1138 8y agoShared 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.
- XparentX 8y agoAs a responsible parent, this will not be supported on my home network.
- SXX 8y agoAs 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.
- marksomnian 8y agoAs 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.
- XparentX 8y agoI agree on the most. When my kids grow older, I’ll teach them. And the trick with local CA is awesome!
- unethical_ban 8y agoallowed 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.
- dzhiurgis 8y agoallowed netname: WIKIMEDIA-EU-NET problem solved
- evfanknitram 8y agoThe Remote IP is almost as sensitive as SNI right?
- tscs37 8y agoNot necessarily, think CDNs or Shared IPs for Webspaces.
- hansjorg 8y agoNot always, see domain fronting: https://en.m.wikipedia.org/wiki/Domain_fronting https://en.m.wikipedia.org/wiki/Domain_fronting
- blattimwind 8y agoOr services which use subdomains for individual users, e.g. #.github.io, #.tumblr.com, #.blogspot.tld and so on.
- cesarb 8y agoThis. 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.
- bosdev 8y agoThis 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.
- Ienuur4i 8y agoThe 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.
- blattimwind 8y ago> 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.
- Ienuur4i 8y ago> 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?
- ajnin 8y agoWho 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.
- tscs37 8y agoThe 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.
- devoply 8y agoTrue. However these days pretty much everyone is colluding so there is that. Data bonanza.
- xg15 8y agoI 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.
- tscs37 8y agoI 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.
- xg15 8y agoIf 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.
- pol_throw_away 8y agoI'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 :)