151–160 of 195 posts
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.
Earlier quoted context omitted.
VPN is not really a solution because you have no reason to trust your VPN provider more than your ISP.
It is a social consideration. Would you trust the government and jurisdiction of Holland or would you rather use DNS services offered by Turkey?
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.
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.
You most likely also get faster DNS lookups by using your ISP's DNS servers.
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.
I'm still pissed off we didn't get encrypted SNI in TLS 1.3 It would've broken so many dpi based censorship systems in countries like Iran, Turkey, and Russia.
You could have a server listen on a subnet and clients randomizing its target IP.
Earlier quoted context omitted.
Its better than no solution, and you aren't limited to using one VPN. A dozen VPN providers each with 8% of your browsing history is still bad, but far preferable to an ISP with 100%.
Is it? I would guess that people already split their traffic between a home workstation connected through a local ISP, a mobile phone connected through a national carrier ISP, and a work computer that is connected with a (third) enterprise ISP. The concerns that linger in the comments here, are about the dangers of exposing even a slice of your metadata can be disastrous. Therefore, going from three to eight ISPs is…
Earlier quoted context omitted.
For sites like google, blocking IPs would meet resistance.
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.
Still, encrypting SNI hides quite some information (were you searching, watching youtube, reading blogger, was it image search, maps...?)
Earlier quoted context omitted.
I'm still pissed off we didn't get encrypted SNI in TLS 1.3 It would've broken so many dpi based censorship systems in countries like Iran, Turkey, and Russia.
SNI is just an ugly hack because IPv6 is not deployed widely. 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.
Earlier quoted context omitted.
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 intro…
"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…
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...
Earlier quoted context omitted.
That's not what the article is proposing. Still, your home ISP may not be able to, but the ISP of the machine you're SSHing into can.
It is a social issue. Would you trust the government of Holland or would you rather try your chances with the Turkish government?
Earlier quoted context omitted.
SNI is just an ugly hack because IPv6 is not deployed widely. You could have a server listen on a subnet and clients randomizing its target IP.
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.