Live data from Hacker News

How to keep your ISP’s nose out of your browser history with encrypted DNS

arstechnica.com

181–190 of 195 posts

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#181
After all these posts, I still don't get what is the problem with the ISP seeing my DNS queries. That's still private telecom information protected by law. Unless you're doing something obviously illegal, and are under investigation. They can't do anything with that data legally. Using Cloudflare or VPN most likely won't solve the problem anyway, at least if you're doing something criminal enough. Therefore claiming it making you untraceable on net, is snake oil anyway.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#182
post #166

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.

What about running your own DNS server locally? 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.

Standard DNS is clear text. It doesn't matter if you use your ISP DNS server or not. Either way, they will see the DNS traffic.

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.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#183

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.

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.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#184

Earlier quoted context omitted.

Nah. DNS caching would prevent you from seeing every usage of the site. Much better to just log every source ip : dest ip.

IPs are shared, they don't necessarily tell you what site you're accessing.

IMHO, very few things the ISPs and their advertising customers care about would be using shared IPs.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#185
post #174

Earlier quoted context omitted.

Nah. DNS caching would prevent you from seeing every usage of the site. Much better to just log every source ip : dest ip.

The only thing you'll see is a list of CDNs and cloud providers.

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.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#186

Earlier quoted context omitted.

"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 serv…

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.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#187

Earlier quoted context omitted.

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.

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.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#188
post #175

Earlier quoted context omitted.

"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 serv…

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

[deleted]

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#189
post #175

Earlier quoted context omitted.

"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 serv…

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?

This reasoning I am too stupid to understand.

Re: How to keep your ISP’s nose out of your browser history with encrypted DNS

#190
post #137
post #72

Earlier quoted context omitted.

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 if we could have first class SSL certs for IP addresses? They're not routable.

What does this mean?
Post reply on HN