4 ms·
Unfortunately enough ISPs have abused their position that treating them as hostile is where we're going. VPNs are a stopgap. The future is end-to-end encrypted
by api 8y ago
Unfortunately enough ISPs have abused their position that treating them as hostile is where we're going.
VPNs are a stopgap. The future is end-to-end encrypted protocols like QUIC that obscure even connection state information and prevent anything from being modified in transit at all, DNS over HTTPS, etc. Everything has to be encrypted and authenticated end-to-end.
- walrus01 8y agoYes, I agree. If the global internet community is developing software to deal with threat models that deal with a worst case scenario (the government of Uzbekistan ordering ISPs to randomly block things), the Chinese great firewall, and so forth, we absolutely need technology like encrypted SNI in TLS1.3 and similar. If we develop software with end-to-end crypto to deal with repressive-regime threat models, its crypto should also be inherently sufficient to deal with more normal traffic interception and modification attempts. A lot of non democratic regimes in places outside of North America take a very blunt approach, of having government agencies order all of their domestic ISPs to simply null route huge chunks of the Internet (like, entire ipv6 /16s belonging to Azure and AWS) in order to ban politically objectionable sites. Or to order all ISPs to be singlehomed to, and downstream of the government state run telecom. There is one ASN in Iran which is allowed to have international IP transit connectivity to other non-Iranian ASes, for instance. https://bgp.he.net/AS12880 https://bgp.he.net/AS12880
- jillesvangurp 8y agoYes, men in the middle cannot be trusted. Especially ISPs. Most mean well but are incompetent. Some don't mean well and are incompetent. ISPs that mean well and actually know what they are doing are relatively rare. If you have a device with wifi, most of the time you are on untrusted networks. So, it makes no sense whatsoever to default to some random isp's DNS just because the wifi you are on is suggesting that you use it.
- behringer 8y agoThey're only rare because their CEOs go to jail: https://en.wikipedia.org/wiki/Joseph_Nacchio https://en.wikipedia.org/wiki/Joseph_Nacchio https://www.bizjournals.com/denver/news/2015/04/29/joe-nacchio-speaks-out-on-prison-broken-justice.html https://www.bizjournals.com/denver/news/2015/04/29/joe-nacch...
- gnode 8y ago> Everything has to be encrypted and authenticated end-to-end. This isn't really enough. Even with QUIC / TLS your ISP can still know what endpoint you're connecting to, which may in itself be too bad. This is the problem VPNs are solving (or at least moving the trust). There's also the touted alternative of conglomerate everything onto Cloudflare and have encrypted SNI.
- walrus01 8y agoIf your ISP is doing netflow analysis and DPI on your connection (like the Chinese GFW), with malicious intent specifically aimed at you, you're pretty much screwed anyhow. If they decide to start blocking traffic to VPN endpoints and such. This can be seen if you try running a non-obfuscated openvpn link into and out of China.
- gnode 8y agoExcluding steganography, an eavesdropper will know if they're unable to understand your communications. What's important is that what they can glean isn't enough for them to be specifically motivated or able to harm you. Being seen to be using a VPN only labels you as a VPN user. In China, the authorities dislike individual VPN use, and attempt to curb it with technical measures, but for the most part, they don't go around imprisoning people only for VPN use, because there isn't much expected gain to be had from the average VPN user.
- walrus01 8y agoThe new thing with the GFW in the last 3-4 years is to identify VPN-resembling traffic from DPI, using a fully automated/scripted system, and then over a period of several hours/days, the GFW causes incredibly high packet loss for all traffic to/from the non-china endpoint, eventually culminating in a nullroute of all traffic.
- dylz 8y agoWithout malicious intent, ISPs are already doing this, both to sell aggregated traffic data and to shit all over their network. On Sprint and ATT Mobility I cannot maintain many TCP connections for long durations - websockets will be killed after a while and require reconnection, long-connected TCP games will drop after a few minutes, quite a handful of HTTPS/TLS sites do not load and immediately hardfail with a TLS protocol error or connection reset, traffic appears modified and periodically injected, DNS is hijacked, images' hash values do not match the server side on plaintext connections, NXDOMAIN DNS values are hijacked, traffic crossing any port will be tampered with as long as it looks like HTTP/1.x, etc.
- WorldMaker 8y agoUnfortunately even QUIC and DNS over HTTPS can't save us from the ISPs (and Enterprise ITs) that think TLS/SSL proxies are a good idea, and especially sadly things like QUIC and DNS over HTTPS may push more ISPs towards that line of thinking.
- jimktrains2 8y agoThat would still require a custom cert installed on the end user device, which may not be feasible in the case of some iot devices and generally a pain for most users in general, especially as more websites pin their certificates.
- WorldMaker 8y agoPain for the users has never stopped enterprises from doing it, sadly.
- jimktrains2 8y agoThat is often handled by group policy. I'm not entirely aure how pinni is handled, maybe it's disabled in ie or chrome via group policy too?
- WorldMaker 8y agoJust because it is handled automatically by "group policy" doesn't mean that users don't feel day-to-day pains from it. It just means it is more likely that don't understand where their pain is coming from. ("If I pull up google.com in Chrome or IE it works, but why can't I use Firefox?" "Because we don't support it here." [Because group policy deploying CA certificates to it is harder and it has stricter CA requirements, such as no self-signed certs.]) Enterprise IT can sweep some of that under the rug by controlling which software is allowable to be installed at all, but there's always going to be edge cases in a TLS Interception environment to cause users papercuts, at the very least. To answer your direct question: So far pinning in browsers is still just TOFU [Trust on First Use], I think? So pinning alone still works with TLS Interception so long as it is intercepted on Day One. The Chrome security team has been threatening for a couple versions now that certain pinned lists, including (but not limited to) Google's own sites, would be baked into the browser in such a way that no one should be able to disable them. I wish they have the gumption to pull that off. With Chrome being the current darling browser of a lot of the same IT groups using TLS Interception, that might actually send a clear message that TLS Interception is a bad idea. Unfortunately, it might just be received as "Here's Google's list of sites that have to be whitelisted or outright blocked from our Interception Proxies so as not to confuse our users", but that would still be a step in the right direction in so far as end-to-end internet security.