Earlier quoted context omitted.
We’re working on it.
(for the lazy: eastdakota's profile claims to be the CEO & co-founder of CloudFlare) Thanks & very, very good luck!
How to keep your ISP’s nose out of your browser history with encrypted DNS
161–170 of 195 posts
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#162Earlier quoted context omitted.
Well if you’re using a VPN then your ISP can’t see much. Some VPNs offer DNS too.
VPN is just a remote ISP. Of course you have more options, but it's not TOR. Edit: I mean TOR only figuratively.
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#163Earlier quoted context omitted.
Getting rid of plaintext SNI won't help much. 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.
> The domain is there in the certificate itself. 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.
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#164Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#165Earlier quoted context omitted.
It is a social issue. Would you trust the government of Holland or would you rather try your chances with the Turkish government?
With the new legislation that's coming I absolutely wouldn't trust the Netherlands anymore... Something like Denmark seems like a better alternative.
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#166If 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.
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.
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#167Earlier quoted context omitted.
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.
Then switch ISPs. Mine sends NXDOMAIN just fine, and is with 0.632ms massively faster than what Google or Cloudflare offer.
Hahahha, and then he said "Then switch ISPs", like we have more than one high speed choice where we live".
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#168Earlier quoted context omitted.
I thought that dnscurve was the method to actually prevent domain snooping. Regardless, I think running your own authoritative dns which updates from root servers is the real way to go.
Your traffic still has to go to those servers, so your ISP still can track the terminal server IP, can't it? (TOR, or tunneling aside)
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#169Isn't there an option to polute the information the ISP sees to such a level that their information is useless? 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.
Re: How to keep your ISP’s nose out of your browser history with encrypted DNS
#170Earlier quoted context omitted.
> The domain is there in the certificate itself. With TLS 1.3, the certificate is in the encrypted portion of the handshake.
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.