If you care about privacy, use your ISPs DNS servers.
Your ISP can see exactly which websites you're visiting regardless of how you do DNS, thanks to being able to see which IPs you're sending packets to, and thanks to SNI.
The only thing you get from adding some third party encrypted DNS service to the mix, is an additional party which can also see what websites you're visiting.
The domain is there in the certificate itself. There are, of course, some (or maybe many, I don't have statistics) certificates for multiple domains (wildcard and alt. name), but still.
However as I understand the protocol the very first step of the TLS 1.3 handshake, the nonce generation, can be MiTMed sufficiently to allow an attacker to determine the target domain. It's only in the next step that server and client do authentication.
The attacker can't trivially continue the handshake beyond that point but that might give enough info to log the attempt and terminate the connection.
Datacenters today work differently: IPs convey a fuzzy idea of where to find what you are looking for. Server name will be used to route your request internally in the DC.
I cannot imagine exposing the IPv6 IPs of single racks: it makes the whole "cloud" thing fall apart.
You don't need to. This is no different than how lack of SNI is handled with IPv4, just have multiple static IP addresses on whatever frontend you're using. With IPv6 it's easy to delegate as many IP addresses as you want. The slight problem with this is that it doesn't solve the privacy problem at all as now you just look at the IP address and check which domain it serves.
If thats true it’s because of the limitations of IPv4 more than anything else. With a single $5/month machine from Linode you have a /64 IPv6 subnet, that is 2^64 IP addresses just for that one machine.
how would encrypted SNI work? sure, you can probably do some sort of DHE, but that's vulnerable to MITM, which is why we have certificates to begin with.
What if we could have first class SSL certs for IP addresses? You connect to the IP and verify the cert it presents you with your PKI, then switch to the desired host via SNI or some other mechanism after DHE is established. I suspect you could do this without any extra hops but I haven't really thought through how that would work.
What's the next hop for a cryptographic hash? With IP addresses, you have a heirarchy: You match on a prefix to find the router to handle the next path, and that one matches on a longer prefix to find the next hop, and so on.
That allows you to have routing tables that don't include every single host on the internet. This is what allows efficient routing to happen.
Yes, whatever is serving on that interface will have to terminate TLS. Or somehow pass the session information to the proxied server, or ask the client to reconnect, or do some kind of tls tunneling from the client to the real host. I don't think any of those are unreasonable options.
It is if that’s all you’re trusting, but you get to check the validity of the cert, so someone could MITM a TLS 1.3, but it wouldn’t do them much good as all they would get is a request for a certificate, then the normal TLS certification steps must proceed. Without the certificate private key the rest of the handshake would fail.
sure, they're not going to MITM your http connection, but they will be able to MITM your certificate connection, which allows them to discover what site you visited, which is the same problem that SNI has.
They can do this, but your browser would retroactively notice that it happened and go "holy shit that was bad, you should complain to someone about it". This does not solve for all threat models, but it does avoid the "snoopy ISP".
both of them seem to use the concept of "connect via a fake domain name, then connect to the real domain". i'm not sure how this is scaleable for everyday browsing. you might be able to find the fronting server for wikipedia, but how are you going to find the fronting server for every website you're visiting? this solves the problem of censorship, but not the problem of ISP surveillance.
The point is you don't know what the public key of the target website is. You find out by asking for it, and then you verify it's authenticity by checking the signature. Before you connect all you know is the domain and the keys of CA's you trust.
Russian here. Entries in gov's blacklist of sites should include IP addresses, domain names and optionally URLs. SNI isn't that helpful for ISPs because they could block traffic by IPs rather using DPI (IIRC only one NIR is using it, but for DNS rather than TLS itself).
This situation is covered with a whitelist of IPs and domains (year ago it became official after exploitation of vulnerability in how blacklist register works, before it was on ISPs, Youtube was banned by some ISPs quite a few times), including .google.com, .youtube.com and other Alphabet's domains, *.facebook.com and some others.
There's nothing good about breaking DPI. Instead of blocking a single site you'll end up blocking entire IP address. I'd even suggest an optional extension of HTTPS which allows to put entire URL as unencrypted part of the request. Censorship systems usually block content by individual pages. Currently with HTTPS it's not possible to block individual page, so an entire website is blocked.
TLS and HTTP are different things. TLS is being used without HTTP in lots of cases.
Besides, even if such extension had existed it would've been easy to write X in TLS header and Y in the HTTP payload to circumvent the ban, like the domain fronting[1] trick currently being used by e.g. Signal.
Services like google share IPs amongs their services. If SNI was encrypted, youtube.com could not be blocked unless the entire IP space of google is blocked (which would be very hard to do since nearly everyone relies on gmail).
Kazakhstan blocked major part of gmail functionality at one point of time. You couldn't download attachments, images didn't work, may be something else. I think they tried to block blogspot. but shared IP broke gmail. It was broken for months, nobody really cared except people pointlessly ranting on forums. Those, who needed working email, migrated to other providers or used proxy. I'd like to live in the world without censorship but I don't see this happening, so I'd prefer to minimize censorship damage at least.
Not every DNS query is going to be followed by a HTTP or HTTPS connection. You also have queries for other protocols; queries which are never followed by a connection because the response was "this name doesn't exist"; "leaked" queries for internal hostnames; queries which were just to check if a name exists; and reverse (PTR) queries.
While for absolute privacy this makes sense, from a lazy ISP dev perspective, why log packets/IPs if you can get marketing data straight from your DNS servers?
Surely ISPs have taken this easy approach while encryption has been only for fringe users?
On the other hand, if I were a curious and amoral ISP dev - I'd consider the people circumventing the "easy approach" to be _much_ more interesting to snoop on...
ISPs want to sell advertising, or data to advertisers. Why bother trying to advertise to a few geeks who are probably running PiHole anyway? Especially since doing that multiplies the hardware requirements 100 fold.
Possibly because the people who you can sell that data to are prepared to pay way more per "product" than the people trying to sell you fast moving consumer goods or ICO de jour...
Wouldn't surprise me at all to find there's a market where intelligence services can purchase lists of TOR users - for example...
True, although what are they going to do with the data? If it’s primarily for selling to ad companies, a tiny slice of privacy minded people aren’t worth much.
I suppose that is true for smaller sites that don't have their own IP addresses but for larger sites you will be easily able to map it through reverse DNS.
Probably only for the very large. And even there I'm not sure if you can distinguish amazon from AWS, Microsoft from Azure and Google from Google Cloud. Facebook and Twitter should work reliably but even with a Facebook IP it could probably still be Instagram or Whatsapp.
Data mining is big money. They can glean in insane amount of personal information about you based on the sites you go, aside from the fact they already know who you are.
I'm not a 'networking' person, but am I wrong in believing a VPN would (potentially, with caveats) prevent your ISP from "being able to see which IPs you're sending packets to"? Wouldn't all packets look like they are going to and from the VPN?
As mentioned, that doesn't get around the VPN knowing where your traffic is going, and there are issues such as your VPN dropping and your system switching over as opposed to dropping the packets, compromising your privacy.
Kind of strange that Google's first result for "sshuttle" is a dead project (literally says "Wrong project!" in the title) that links you to the real one.
That is true in my case, but my ISP has in the past redirected various queries to their landing/search pages, which means that I simply don't use them anymore.
SNI-enabled browsers send the unencrypted hostname in the initial ClientHello frame. It's the first transaction in the protocol, and it's how the server decides the content of the ServerHello reply. There is no way to detect the ability to avoid SNI, or indeed any sensible and generally useful way to tell if a ServerHello varied according to the ClientHello SNI hostname without probing the server, which entails introducing roundtrips, and disclosing the hostname unencrypted at least once on the wire.
"There is no way to detect the ability to avoid SNI..."
Assuming one is using an SNI-enabled browser.
I dont use an SNI-enabled browser to make the first encrypted HTTP request.
In fact I didnt even say I was using a "browser". I said "https client".
For example, one can use an https client that has SNI disabled or which has no SNI code at all, or one can send any string as the servername in ClientHello.1 If the server responds with hostname not found, then retry using SNI and the desired hostname. IME, most TLS-enabled websites do not require SNI.
When you say "If the server responds with hostname not found", what are you talking about? Exactly which protocol are you refering to when you say "hostname not found" ?
Most web servers will just fall back to the default virtual hosts SSL certificate if no SNI header is present in the clients request... They don't reply "hostname not found", or "nope, no such host", or anything similar...
"They don't reply "hostname not found", or "nope, no such host", or anything similar..."
"hostname not found" was meant to be a general term for failure due to not sending the correct servername when it is required, not a specific protocol error. I apologise for not being more precise. What happens with the non-SNI clients I use in the rare case when absence of correct servername is fatal is that the connection fails. (Most times a correct servername, let alone any servername, is not required1 and the connection succeeds. Thats the point of the original comment: in a majority of cases, its possible to get the page content without using SNI.)
1 As in the case of example.com, for example.
However, I use a local forward proxy for TLS-enabled websites. The proxy returns HTTP 503 error when the connection fails due to SNI. Thus, I do get a consistent "server response" when this happens, albeit not from the remote server.
Since the ClientHello is sent in the clear, a MITM can simply reset the connection until the client retries with SNI. Again, there is no generally useful way to solve this
"... a MITM can simply reset the connection until the client retries with SNI."
That doesnt happen when I fetch https://example.com without sending a servername in ClientHello.
For the majority of TLS-enabled websites on the internet, that does not happen. I get the page content just fine witout sending a servername in ClientHello.
But I should send the servername in ClientHello anyway?
I'm in the same boat. My ISP's DNS servers tend to be very slow and often unresponsive. As a result I've used googles (a bad idea, in retrospect) for the last 10 years or so.
> I've used googles (a bad idea, in retrospect) for the last 10 years or so.
That is a reasonable consideration, but Google is very specific about how they use and retain data collected by Google Public DNS. Assuming they are not lying, I don't think it's a significant concern. (Admittedly, their policy is not as good as Cloudflare's "no IP logging" policy.)
TL;DR: Logs with IP addresses are deleted within 48 hours; permanent logs keep city-level location data, but no personally identifiable information. "We don't correlate or combine information from our temporary or permanent logs with any personal information that you have provided Google for other services."
There aren't many ISP DNS servers that aren't garbage in my experience. Most of them don't send NXDOMAIN. Many of them are slower than either Google or Cloudflare despite being theoretically closer.
I've spoken to some folks that worked in the VPN provider industry... many of them aren't the bastion of consumer protection they claim/are perceived to be. With the exception of Tor (and even that has been found to have problems) I'm not sure "single-point" anything will really provide you with anonymity.
I think it really comes down to your threat model though and what tradeoffs you're willing to accept for anonymity (e.g. captchas, performance, etc).
I think the sweet spot for CloudFlare's offering is if you're in a country or service provider that takes liberties in overriding DNS responses.
Buy VPS and install your own VPN. It's much harder to spy on you in this setup and basically requires complicated targeted attack. I'm not sure if common networking setups for VPS record TCP connections, if they do, then VPS provider can record some important metainformation, but it's still not a lot. On the other side with VPN it's much easier to spy on every client.
I mean, if you’re trying to defend against a coordinate government attack, you’re boned anyway. They’ll just break into your house and install a sniffer, or arrest you, or make your life hell.
That’s assuming they can’t just get into your home network through zero days, which an individual has no practical defense against.
Well seeing as all credit cards are basically subject to US law, you'd need to find a VPS that is going to accept say Bitcoin for server space. Perhaps one that is going to accept cash in the mail.
Then hope that said provider is reputable enough to be up to date on their security, and honest enough not to just cave under pressure.
Realistically the VPS solution fails simply because there is no obscuring of traffic. We all know that security through obscurity isn't real security. However if a VPN provider has 1,000 users using their IP block than any specific traffic is harder to isolate to one user. -- Presuming they are honest and not keeping logs.
Running your own VPS means that all traffic is owned by you.
there's a huge difference between anonymity when someone is looking for you and anonymity in general.
As you've mentioned, if someone wants to track you through Tor, that's still potentially possible. But that's a completely different ballgame than "My ISP wants to track every last website I visit so they can pair that with my address/billing info to sell to advertisers". I don't think my ISP is going to go through all the hoops to find my Tor exit node, just so they can sell that to advertisers. Passive onlookers can be untrustworthy too.
The shades on my windows keep people from seeing me change, but if someone really wanted to see specifically me naked, they could probably enter my house and make the shades useless.
So? What if the VPN doesn’t know who you are? What if it’s your own VPN but others don’t know that?
The entire point of choosing a good VPN is to get the visible data off of your immediate ISP, since they know who you are, and into a more nebulous net, where others do not.
If a party were to, by chance, to monitor both your entry and exit nodes couldn't they match the traffic by time & packet size, et al? Then use known techniques to match pages accessed (it's something like 85% accuracy IIRC).
That would match to individual IP, or potentially an individual if you're logged in.
This is a great way of thinking about a VPN, and how I describe it myself. If you have limited options on your choice of ISP, then a VPN allows you to expand your choices (excluding speed, latency, usage caps).
Same argument applies there then. Your VPN provider can already see what websites you're visiting, so use their DNS servers if you can. Don't add yet another third party.
Your requests will go to the root dns servers, which then go the dns servers of the domains you request. But also it will cache responses locally (so if you make another request it won't even need to make an external request).
Yes your ISP can still see it but they can see all your traffic anyway.
That won't work. All the ISP has to do is snoop port 53 and they can see your DNS whether you're using their DNS server or someone else's. You have to get the DNS traffic out of their visibility by using VPN or DNS TLS.
SNI is part of the first message a TLS client sends to the server - the Client Hello. TLS clients that support SNI (including all modern browsers) will typically always send the SNI extension, regardless of whether the server supports or makes use of SNI.
Depends a lot. My ISP's (both mobile ISP and DSL) have pretty slow DNS providers. My mobile connections were significantly quicker after I switched to using VPN with Cloudflare DNS as resolver (or even the local resolver, though that is normally a bit slower than Cloudflare/Google DNS due to caching)
Not necessarily. Back when I used Comcast I got much faster browsing speeds by using a proxy over a VPN to a linode server, even though that server was in another state.
Your ISP can see exactly which websites you're visiting regardless of how you do DNS, thanks to being able to see which IPs you're sending packets to, and thanks to SNI.
The only thing you get from adding some third party encrypted DNS service to the mix, is an additional party which can also see what websites you're visiting.