Comment by Nyr
Comment by Nyr 2 days ago
Governments do not even need any of the providers to comply, they can access global NetFlow data. This is conveniently not discussed by any commercial VPN provider.
Comment by Nyr 2 days ago
Governments do not even need any of the providers to comply, they can access global NetFlow data. This is conveniently not discussed by any commercial VPN provider.
It ultimately depends on your threat model. But assuming a state actor has access to NetFlow data, an attack could work like this:
* State actor determines that an IP belonging to a VPN company had a session on example.com around t1-t2
* You -> VPN server at t1
* VPN server -> example.com at t1+latency
* More traces from both sides until around t2 as you browse the site
By correlating multiple samples, and accounting for latency between you and the VPN server and delay introduced by the VPN itself, they would be able to get decent confidence that it was you.
Basically when you go at the point of state threat actors. Things get real spooky. The censorship , the what not.
I feel sad that we have given governments such major accesses in the name of unification.
We need more decentralization at the political level & economical level as well (like most money goes to your city , then state , then at the country , very nominal amount)
Let city decide what it wants with major town hall discussions.
The threat actor most use to talk about this is a global passive adversary: a threat actor who can see all relevant traffic on the Internet but who can't decrypt or adjust the traffic.
This adversary would have the ability to ingest massive amounts of data and metadata[0] it acquires from tier 1 ISPs all over the country[1] and the world[2]. They'll not see raw HTTP traffic because most everything of interest is encrypted, but can store and capture (time, srcip, srcport, dstip, dstport, bytes).
From there, it's a statistical attack: user A sent 700 kilobytes to a VPN service at time t; at t+epsilon the VPN connected to bad site B and sent 700 kilobytes+epsilon packets. Capture enough packet flows that span the user, the VPN, and the bad site and you can build statistical confidence that user A is interacting with bad site B, even with the presence of a VPN.
This could go other directions too. If bad site B is a Tor hidden site whose admin gets captured by the FBI and turns over access, they'll be unmasking in reverse – I got packets from Tor relay A, which relay sent packets at time-epsilon to it, (...), to the source.
There's very little you can do to fight this kind of adversary. Adding hops and layers (VPN + VPN, Tor, Tor + VPN, etc.) can only make it harder. It's certainly an expensive attack both in terms of time consumption, storage, and it requires massive amounts of data, but if your threat model includes a global passive adversary, game over.
[0] https://en.wikipedia.org/wiki/XKeyscore
I'm bearish on introducing noise[0] to resist traffic analysis, and I'm exceptionally bearish when the only layer managing noise injection is "a for-profit entity that can be legally compelled to do things"
But every layer helps; I'd feel more than happy torrenting over Mullvad alone, and I'd definitely use it as an additional layer of defense with other tools to keep me private if my threat model needed to consider stronger risks.
Synchronous packet transfer only solves the problem if you build a truly constant rate network. Traffic monitoring works when variances exist; your flow has to be fully homogeneous to provably secure against it. That means in your model your users would need to transmit and receive exactly 96kbps at all times when on net, and your nodes would talk to each other at 1024kbps at all times when on net. Otherwise, consider A->onion1->onion2->B – an attacker could potentially see the flow from onion1->onion2 decrease to 1 PPS sec when A isn't talking, and increase when A is.
Truly constant rate anonymity networks dramatically add resistance to passive traffic analysis, but they move users from a low-latency/high-throughput network to 56k dialup speeds :) Not only does this suck so most people won't use it, but the people who do chose to use it will glow neon bright to adversaries. The use of the system will be a strong indicator that, even if you don't know what the user is doing, the user is doing _something_ interesting.
And even if there was desire, these networks are intrinsically limited in size and scale if they want to maintain constant rate. Herbivore[0] is an interesting proposal in this space - use a DC-net partitioned into smaller cliques to give in-group anonymity but mass participation. And most use chaff packets – A has nothing to send so sends encrypted random data to maintain the constant rate guarantee... I'm trying to find the paper I read that suggests a global passive adversary who goes "hands on" in the network could use a combination of watermarks generated through packet dropping/artificial queues + knowledge of which packets are chaff to build a trace, but I'm struggling. If I do I'll drop it here.
For fun, go check out https://groups.google.com/g/alt.anonymous.messages – this is probably the classic example of a (very) high-latency but very strong anonymizing mix network.
[0] https://www.cs.cornell.edu/people/egs/papers/herbivore-tr.pd...
Some of the prior works in this paper[0] address noise in anonymity networks, but in general: you either add noise at the link level which malicious nodes can identify & ignore, or you add noise by injecting fake chaff packets that are dropped somewhere inside the network which are statistically identified when you look at packet density across the network.
This might or might not extend to VPN nodes depending on your threat model - I'd personally assume every single node offered to me by a company in exchange for money is malicious if I was concerned about privacy.
Honestly, paying for a VPN is just purchasing slow internet speeds at a premium.
https://www.youtube.com/watch?v=9_b8Z2kAFyY
Just use Tor.
Thanks for pointing this out. I wasn't aware of NetFlow. I don't use IVPN, but I found this writeup informative:
https://www.ivpn.net/privacy-guides/isp-netflow-surveillance...