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.
It would've broken so many dpi based censorship systems in countries like Iran, Turkey, and Russia.
Thanks & very, very good luck!
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.
With TLS 1.3, the certificate is in the encrypted portion of the handshake.
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.
You could have a server listen on a subnet and clients randomizing its target IP.
I cannot imagine exposing the IPv6 IPs of single racks: it makes the whole "cloud" thing fall apart.
They're not routable.
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.
That means you can't use sni to route your request to a different server.
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.
Could the browser send a symmetric key encrypted in the public key of the target website, as part of the initial challenge?
Still, encrypting SNI hides quite some information (were you searching, watching youtube, reading blogger, was it image search, maps...?)
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 trick currently being used by e.g. Signal.
Wouldn't surprise me at all to find there's a market where intelligence services can purchase lists of TOR users - for example...
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.
sshuttle 0.0.0.0/0 --dns -r $server
don't forget --dns ;)
With all due respect, 100% adoption of SNI seems like some sort of popular myth among certain web forum commenters.
Perhaps we should do a survey of all websites found on HN on a given day and publish it. I would bet that the majority do not require 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.
exec printf 'GET / HTTP/1.1\r\nHost: example.com\r\nConnection: close\r\n\r\n'|exec openssl s_client -tls1_2 -no_ssl2 -no_ssl3 -ign_eof -connect 126.96.36.199:443 -servername SNI_NOT_REQUIRED
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...
"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.
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?
This reasoning I am too stupid to understand.
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."
Hahahha, and then he said "Then switch ISPs", like we have more than one high speed choice where we live".
Due to laws designed for more broadband competition, I've got over 6 providers to choose from here in Germany.
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.
That’s assuming they can’t just get into your home network through zero days, which an individual has no practical defense against.
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.
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.
I still consider the shades useful.
Of course you have more options, but it's not TOR.
Edit: I mean TOR only figuratively.
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.
That would match to individual IP, or potentially an individual if you're logged in.
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.
Forward you DNS requests to servers using DNS with TLS encryption or with a VPN provider. That way the DNS requests can't be seen by your ISP.
Using a non-ISP DNS server isn't enough.
Your ISP knows way less about you if you avoid their DNS. And they are the only ones that know your legal name and billing address, usually.
Can't ISPs still see the eventual target IP address, and do a reverse DNS lookup of that? Even with HTTPS/TLS I thought encryption is done after a handshake isn't it, which would imply a TCP level connection is made first which would be sniffable?
Is it perfect? No. It is better than yesterday? Yes.
I call these "micro-wins." One micro-win won't make a difference, but two, three, four, and so on eventually start to have an impact. And that's all we can hope for.
Even often cited VPNs just shift the problem downstream. Instead of your ISP monitoring you, the VPN provider themselves could, or if you host it yourself then your server/virtual server's ISP could. VPNs themselves are another "micro-win" but people often claim they're a complete bulletproof solution.
I like this term :)
It's also believe its a win when computer privacy and security begin to edge into main stream lexicon. Somewhat anecdotal but I recently saw that NordVPN is advertising on CNN.
It doesn't do this by itself. It just prevents one method of data collection.
The ISP can easily connect your IP to your subscriber information, and their DNS can log every lookup made by your IP. Even if you use another DNS, since it's unencrypted, they can (and likely do) sniff that traffic and collect the same information.
> Can't ISPs still see the eventual target IP address, and do a reverse DNS lookup of that?
Sure, but this requires a slightly higher level of effort, and also assumes that you're not connecting to a CDN, which can make your requests pretty opaque.
> Even with HTTPS/TLS I thought encryption is done after a handshake isn't it, which would imply a TCP level connection is made first which would be sniffable?
Right, and even with SNI, the requested hostname is still sent in the clear. I hope this will be fixed somehow in future implementations. In the meantime, if you need to treat your ISP as absolutely hostile, then you need a VPN or some other kind of encrypted tunnel or proxy.
ISP can still see the target IP address and SNI. The IP address is sometimes meaningful (single website), but not if it's a CDN or a multi-tenant server. The SNI is being worked on (encrypted SNI, ORIGIN frame, CERTIFICATE frame). The point is none of that matters without encrypted DNS.
That’s why we all have DNSSEC enabled on our domains, right? Right?
There's an ongoing work to make revalidation easier - the client would basically ask the recursive to not only provide answer, but also a whole trust chain from a known trust anchor (so it would revalidate the answer without additional queries) https://tools.ietf.org/html/rfc7901
The slightly bigger problem is HTTPS with SNI, which leaks the host header in plain text before establishing the connection. It's an unfortunate necessity as long as hosting providers need to use virtual hosts behind a shared IP address, but it's also one more potential snooping vector to deal with.
How many sites being visited fit this model? Fewer everyday, but it seems a lot of non-mainstream content is still hosted on smaller shared hosting plans.
E.g. on a Mac with Homebrew. First:
brew install dnscrypt-proxy
Third: Put your DNS to 127.0.0.1
A new macOS GUI would be really great.
All sorts of solutions are offered enthusiastically while the elephant in the room, tens of thousand of engineers and billion dollar companies incentivized to hoover up and collate every minutiae of user data as a business model, is met with hand wringing and apologism about ad revenue.
In this case solutions have to emerge from outside the tech community by something like GDPR. Given that reality and the primacy of ad driven business models in SV its difficult to contextualize this preoccupation with ISPs. It feels like a distraction, insincere and driven by commercial concerns.
VPN is a solution but not always deployable.
Yeah, my VPN provider could be lying to me and logging a whole bunch of extra data under the table. But I know my ISP is logging that data. I have every reason to trust a paid VPN provider more than my ISP because my VPN provider is basing their business model on me trusting them, not on being a monopoly.
Not to mention that VPNs also help at least a bit with anonymizing IP addresses. The trust model I have with directly exposing my IP to a website is "I hope nobody I visit on the Internet is logging this."
If I'm wrong and my VPN is logging everything, I'll still be in a better position than I was with my ISP, because at least I won't be broadcasting my current physical location to every single website I visit.
A lot of people really do distrust their ISP enough that even with knowledge that you're shifting the responsibility to the VPN provider they still trust a random VPN more than their ISP.
Would I trust some random unknown VPN provider more than Comcast? Maybe.
I follow the same logic by setting up my own VPS in a rented $big_provider VPN. VPS companies are succulent targets that surely attract many eyes, whereas I doubt any non-state actor has the capacity of capturing and filtering the traffic of the millions of random VPNs that $big_provider has.
If in the Netherlands: probably Turkey. If anywhere else: probably the Netherlands.
Although it is hard to think about a scenario in which the only available choice is between the Netherlands and Turkey.
The idea is hedging against the closest guy with a stick.
Therefore, going from three to eight ISPs is arguably worse as your exposed to nearly 3x the risk of exposure.
Who do you think can smoother monetize your data - your local ISP or Cloudflare? Or maybe Cloudflare solemnly promised never to do it?
If an effort is to be taken, the best thing is to run your own DNS resolver that will query root servers and follow the chains directly.
I'd also say most users' ISPs are probably are global companies (or at least national) anyway.
> the best thing is to run your own DNS resolver that will query root servers and follow the chains directly
Only if the first step is also encrypted. If it is plain DNS, then your ISP can see the requests almost as easily as if going to their own servers (or transparently redirect the requests to their servers).
However some DNS providers support the new standard DNS-over-HTTPS (including Google and Cloudflare). Some also support the alternative new standard DNS-over-TLS (including Cloudflare).
While support for these encryption methods support is offered by some DNS providers, your client devices may or may not support the new encryption methods. Firefox is currently implementing DNS-over-HTTPS so at least Firefox DNS requests will be soon able to use it and Google is currently beginngin to implemen it in Android. The new encryption methods are still in Draft status so expect to see adoption increase as they near completion.
Using DNS over HTTPS which you can leverage in the latest Firefox nightly will make your DNS queries over a HTTPS website service. This will prevent your ISP or anyone else from tracking your DNS queries (besides cloudflare of course).
+1 for asking, though. Nothing wrong with trying to learn more about something you know very little about. Not sure why others are downvoting you.
Do people here agree this is a pretty good approach?
Had an extra benefit of creating a log file of queries so I can see addresses that are being queried. I found NordVPN pinging random websites and wondering why? (To see if I'm blocked apparently)
I think the term you are looking for is a recursive resolver (one that will perform a full name resolution for a client).
Just type "apt-get install unbound" already. You won't miss that 200 kB resident memory.
Your ISP can see the IP addresses and all the meta data for your traffic. With the current way DNS is setup, they can modify the responses and re-route you any where they want.
With HTTPS and encrypted DNS, it makes a lot harder for them to inject content or redirect you without browsers warnings.
E.g. contact a friendly service that gives back N different random domain names; then lookup those domain names, spread over, say, an hour; then repeat.
Good source of reasonable randomness is twitter. I've set up a scrapper for various twitter accounts and I'm downloading every page that is linked by those accounts automatically.
With this approach you can even select what you want to look like based on your browsing data by selecting proper accounts. Gold bug? Bitcoin fool? Knitting expert? No problemo. ;)
I have a raspberry-pi on my home network running Pi-Hole and my router’s DHCP server gives all devices on my network the Pi-Hole as the DNS address