top | item 11278784

What ISPs can see

225 points| schoen | 10 years ago |teamupturn.com

81 comments

order
[+] mirimir|10 years ago|reply
This is a decent article. However, it's a bit vague on the vulnerabilities of VPN services. The major risk is probably traffic leakage after uplink interruptions, or changing WiFi APs. Once the VPN connection has failed, default routing must be restored in order for reconnection to occur. There must be firewall rules to prevent other traffic from using the physical NIC during reconnection. That is, you want the VPN to fail closed.

Another risk, which the article may vaguely allude to, is using ISP-associated DNS servers. Even if all traffic uses the VPN tunnel, DNS requests reveal sites being visited, and it's trivial for ISPs to correlate them with traffic.

IPv6 is a huge looming risk. Many VPN services don't route or block IPv6 traffic. As full IPv6 service becomes widespread, there will be major pwnage. However, this is easy to firewall, and good custom VPN clients do so.

Edit: For suggestions about leak-testing, see https://www.ivpn.net/privacy-guides/how-to-perform-a-vpn-lea...

Edit: Changed "URLs" to "sites".

[+] nickspacek|10 years ago|reply
Not to nitpick but DNS requests only reveal hosts being visited, not URLs. Non-HTTPS requests reveal the URL to the ISP.
[+] Matt3o12_|10 years ago|reply
Don't forget WebRTC. It can leak your real IP address and might even be able to use that route.

Nevertheless, setting your Firewall to only allow VPN traffic is pretty easy. I've done that on Linux and Mac OS X. I don't think it is complicated on Windows either.

[+] pmoriarty|10 years ago|reply
One significant point that this analysis misses is that even when traffic is encrypted, it can be recorded and later decrypted by the ISP or those they give/sell/leak the recordings to if the encryption is ever compromised (which seems to happen on a pretty regular basis with SSL these days).

Never let yourself get lulled in to a false sense of security just because the information you wish to keep private has been encrypted.

[+] jmiserez|10 years ago|reply
This is not necessarily true if the cipher used provides forward secrecy, is it?

From https://en.wikipedia.org/wiki/Forward_secrecy:

>As of March 2016, 49.4% of TLS-enabled websites are configured to use cipher suites that provide forward secrecy to modern web browsers.

[+] ams6110|10 years ago|reply
Until recently it was technically or financially unfeasible for an ISP to record all traffic and keep it forever. Maybe today it isn't (or maybe it still is -- I have some experience using large, petabyte-scale, reliable data archives and they are from what I've seen still expensive and slow), but does anyone have knowledge if it actually happening? If it is, how is it being financed? Why would a competitor not undercut with better performance/cheaper pricing by not building such a logging infrastructure?
[+] mattmanser|10 years ago|reply
Serious question, that's not generally how SSL vulnerabilities work is it?
[+] droopybuns|10 years ago|reply
This is a weird article that lacks important context.

When are we going to get an article on "what google can see" from this team?

ISP snooping on network traffic really only happened after Google started getting into the ISP business.

Monetizing your traffic (beyond transport) only became a thing after Google Fiber fired a cannon ball across the broadside of carriers. Carriers responded by offering ad networks around anonymized, aggregated data about customer behavior. It drives the value of Google Adwards down. It doesn't make carriers rich.

Maybe someday we'll need to worry about big-I innovation from carriers in this domain, but I don't see it happening soon.

I'm all in on tearing it all down. But focusing only on the companies that offer services that huge populations are willing to actually pay for is extremely dishonest.

[+] mirimir|10 years ago|reply
> ISP snooping on network traffic really only happened after Google started getting into the ISP business.

ISPs have always snooped. Maybe just in limited circumstances, true. But the key point is that they can, not how prevalent it is.

[+] obfusc8|10 years ago|reply
Always assume an ISP and any intermediate party can see traffic. I like the way this post outlines in simple terms what traffic would look like to an analyst. In terms of obfuscating oneself from an ISP, I would not recommend any form of centralized traffic in the first place. As this post makes clear, even if you're behind seven proxies there are ways to see a traffic's 'shape' on the wire.

To combat this, you can use compartmented, disposable and anonymous 3G sim cards for specific purposes. (One for dating sites, one for health records, etc). Slap them in the microwave after a browsing session. (You can get these for basically free in places like Thailand or India). Block all HTTP. Use something like

    sudo ufw deny out to any port 80
Always assume your connection is tapped. Always assume there's somebody MITM'ing your traffic. (To prove this, download executables several times over time and diff the hashes. It's clear that MITM happens all the time).

Always use a hardware version of TOR. That way if a box is compromised, the naked IP can't be disclosed. The same goes for VPNs, See WebRTC vulns.

Use public Wifi as much as possible (behind a VPN of course). Use your friends phone for casual surfing. Minimize the reliance on one monolithic connection. Use 4G, or even WiMax if they have it in your area.

Share your connection with your neighbor and split the bill if you are so inclined...

[+] crispyambulance|10 years ago|reply
"always" [assuming the worst case scenario] is more than a little onerous for the vast, vast majority of internet users. Isn't there a reasonable middle ground?

Also I don't follow how does one "prove" a MITM attack by downloading the same executable serveral times and getting different hashes?

[+] pippy|10 years ago|reply
Google could easily take the initiative on the DNS query front and implement DNSCrypt by default on Chrome. It would booster client privacy and also block ISP from selling usage data. So it would be a win-win for Google.
[+] achernya|10 years ago|reply
That is not sufficient -- TLS Server Name Indication (SNI) is still cleartext in the handshake.
[+] therealmarv|10 years ago|reply
true, but as I said in another comment here: It will not hide the websites you are visiting. This is also a problem in the article... a secure DNS will not make you invisible it is only slightly harder to track the websites you are visiting. All IPs you are visiting can still be transformed through a reverse DNS and you will get all website addresses.

And Chrome cannot be use dnscrypt by default. It uses UDP ports which are sometimes closed on other networks. So there are technical limitations. Even using another DNS than the network one is often not allowed (you will experience that if you travel often).

Also some people will not like using a Google DNS by default ;)

[+] eikenberry|10 years ago|reply
How would this help if they are using the ISP's DNS servers as most people do by default?
[+] arca_vorago|10 years ago|reply
What we really neednis DNSCurve. CRypt is full of problems from what I hear. All hail djb.
[+] PhantomGremlin|10 years ago|reply
So it would be a win-win for Google

Yes, but would it be win-win for us?

Google's already demonstrated that "don't be evil" is now just a sad memory. I'm not ready to believe them to "do the right thing". Their entire existence is predicated on increasing and refining their data collection and analysis, and acting on such.

Google's seedy behavior already directly impacts me every day. I, for one, don't welcome this new corporate overlord.

[+] sysret|10 years ago|reply
The fastest DNS lookups are ones that do not need to traverse the network.

A zone file of public DNS information can be served by a daemon bound to the loopback on the user's device, obviating the need for many (but not all) lookups sent over the network.

These local lookups are also more private than ones sent out over the private LAN or public internet.

Same goes for any type of data. It's not limited to DNS information.

If a user downloads publicly available data dumps from Wikipedia, and then serves them from a local database and httpd, the response time will be faster and the requested URL's more private than accessing the same content over the public internet. Not to mention the small benefits of reliability and reduced dependence on the network.

I know a user who does this and has automated the process of setting it up.

To use the examples in the article, the idea is that a user can periodically download bulk data, e.g., information on medical conditions, in an open format, load it into her database of choice and query to her heart's content, without any ISP or website knowing what she has queried.

Same with daily newpaper content, and even a catalog of toys. "Browsing" through the data remains private.

The alternative is to have this data served from third party computers and have the user send each and every request for each small item of information over an untrustworthy, public network (the Internet).

Despite ample, inexpensive local storage space for users to store data of any kind themselves, let us break up the data into little bits and make users request each and every bit individually. (Not only that, let's make them register for the the ability to make numerous queries.) Then we can record all user requests for every item of data.

Metadata. Sell. Profit.

[+] Matt3o12_|10 years ago|reply
It should also be mentioned that VPNs, even if correctly used (e.g. no dns/IPv6/webrtc leaks), this simply shifts to trust to another provider. Now, your ISP is not able to see your traffic but your VPN provider is potentially able to (even if you self host it on aws or digital ocean because they still have full access to the box), and their ISP. If you trust them more, use them, but I you don't, I see little reason to utilize a VPN unless you want to unblock geo-blocked services.

The only advantage is that your VPN provider (or their ISP) might have little reason to spy on your traffic instead of your regular VPN.

[+] q1t|10 years ago|reply
So how do you protect form such things? I mean is there a way to analyze all you outcoming traffic (from a specific machine for example) and route every connection(like dns and similar stuff) though desired endpoint?
[+] bluedino|10 years ago|reply
You can use a VPN or ssh tunnel and send DNS queries through that tunnel or proxy - however, that just adds another layer for anyone who wants the information to go through.
[+] amelius|10 years ago|reply
> So how do you protect form such things?

Tor?

[+] cJ0th|10 years ago|reply
One (albeit small) thing you can do is to do much as possible offline. For instance you could download Wikipedia and use it offline only.

The same goes for maps. For example, Open Street Map data can be used offline.

[+] newman314|10 years ago|reply
I guess this is a good time as any to ask what people on HN use for a VPN provider.

I'll create a Ask HN post if there is interest...

[+] ionised|10 years ago|reply
Try this article;

https://torrentfreak.com/vpn-anonymous-review-160220/

I personally use Mullvad. They let you pay in cash by post which is always nice.

Speed is decent enough to stream/download but it won't get near maxxing out my 200Mbps connection. I've yet to find a VPN provider that offers amazing bandwidth along with anonymous payment.

[+] snug|10 years ago|reply
SNI header being sent from the client can probably show even better patterns from the user.
[+] userbinator|10 years ago|reply
I've always wondered why that's sent in the clear --- the usual justification is that the hostname needs to be known before the right certificate can be used, but that can be gotten around by using a certificate named with the IP address of the server, establishing encryption, and then sending the hostname to get that certificate.