https won't keep your ISP from knowing you visited the site. And the rest of those? For a text-only blog, they seem kinda trivial.
If you use DoH, yes it does. Unless I'm mistaken. They only know the IP address of the remote server.
It's the internet. Everyone can scrape links and measure/correlate which assets were on them to correlate likely visited websites.
Especially if every web page these days is pretty unique in terms of what kind of assets (network streams) with what kind of byte size were loaded at which point in the document loading timeline.
Now include the TLS fingerprint of your web browser and well, privacy went to shit.
HTTP needs an upgrade with scattering and rerouting on the fly, otherwise these deanonymization techniques can never be fixed.
Isn't that e.g. TOR's job? Doesn't belong in HTTP.
https://blog.mozilla.org/security/2021/01/07/encrypted-clien...
https://blog.cloudflare.com/handshake-encryption-endgame-an-...
The "anonymity set" refers to the number of possible domains using a single IP address. The existence of that term implies that some IP addresses must have a number of domains associated with them, greater than 1. With these IP addresses, one cannot determine the domain name, the one that the www user sent, from a PTR query alone. Even prior to the introduction of SNI to TLS, when the only way to offer HTTPS was by using a dedicated IP address, discovering the contents of the encrypted Host header via reverse DNS was neither easy nor reliable.
If there are still people reading HN who believe that reverse DNS is reliable and makes plaintext SNI and ECH moot, and are going to comment as such in the future, I would be happy to post the results of an experiment where I take the DNS data for all the domains currently submitted to HN, i.e., a list of IP addresses found in the A records for these names, and do a PTR on each one. We can look at whether "most domains" are identifiable through PTR records.
Also remember the question is not whether ECH protects 100% from someone discovering what domain name the user sent. It does not. The question is whether ECH makes it more difficult to discover than simply sniffing plaintext SNI on the wire, which, of course, is even easier and more reliable than reverse DNS.
The 7TB is via torrent, not via HTTPS. No rDNS needed.
If the user requests the page from Internet Archive, Common Crawl or even Google Cache, how does the ISP know what the user requested. (NB. Neither IA nor Google Cache require sending SNI,^1 so the ISP may only see IP addresses).
With IA, the IP address alone does not reveal which IA site or page the user is requesting. There is more to IA than only Wayback Machine.
With Common Crawl, the user can send the Cloudfront domain name instead of a commoncrawl.org domain. Are all ISPs going to know that this is Common Crawl. Even if they expend the effort to learn, what benefit is achieved.
With Google Cache, the IP address alone does not reveal which Google site the user is accessing. Needless to say, there are many, many domains using these IP addresses.
There is nothing that requires any web user to retrieve web pages from a given host. The page may be mirrored at a number of hosts. Some of those hosts might offer HTTPS, support TLS1.3 and not require plaintext SNI/offer encrypted ClientHello.
Even assuming an ISP can determine what domain name a customer is sending in a Host header or ClientHello packet, it would still be necessary to subpoena the archive/CDN/cache to figure out precisely what pages were being requested.
1. The same party is controlling all the server certificates. IA controls the certificates for all IA domains, Amazon (issues and) controls all the certificates for Cloudfront customers and Google controls all the certificates for Google domains. Perhaps there are web users commenting on HN who believe that ingress/egress traffic for site saved/hosted/cached at an archive/CDN/cache is somehow private as against the company running the archive/CDN/cache in a meaningful way. I am not one of them.
As for the question of an ISP modifying the contents of web pages, this is an issue that could be addressed contractually in a subscriber agreement. It stands to reason that if this was a serious issue and not merely a hypothetical one raised by nerds debating the merits of TLS then it would be addressed in such agreements.
As for the "injection of advertising" issue as a argument in favour of the way TLS^2 is being administered on the web, IMO this is a bit silly since (a) it is trivial to filter such advertising (e.g., Javascript in the examples I saw) out out of the page and/or block it from running/connecting/loading and (b) the amount of "tech" company-mediated advertising that web users endure in spite of using TLS is enormous. More likely than being seen as a threat to web users, the injection of advertising by ISPs was seen as a threat to the advertising revenue of "tech" companies. The later are responsible for facilitating the injection of advertising (by their customers, not their competitors, i.e., ISPs), not preventing it.
2. By "TLS administration" I do not mean encryption as a concept nor certificates as a concept. I mean TLS administration measures designed to support "tech" companies first and web users second, if at all. A system where the questions of "threat model" and "trust" are both decided by "tech" companies not users.
If somebody MITMs it, they can serve you anything they want.
Great. More books!
No really, I don't understand this argument. A static site served by plain http is perfectly appropriate. It's like a poster hanging on the wall for all to see. Of course people can paint over it, but it doesn't really matter.
I agree that it would be an extreme measure.
If it was a quick hack, then that makes it even worse. Difficulty is a mitigating factor.