How to defeat traffic analysis when using a VPN?

[xairv 6]

This is a somewhat complicated question, so I'm not sure if this forum is the right place to ask. In any case, does anyone know how to protect one's anonymity against traffic analysis? I.e. a state actor who has access to the upstream provider of a VPN service may identify its users by observing and matching the traffic graphs in and out of the VPN server.

 

I have some ideas:

 

1. generate random traffic at a random rate (eg. 50-500kbit/s) in each direction (up/down) to be sent in parallel with the real traffic.

 

2. pad the connection so it always transmits at say 500kbit/s (the application will always transmit data at a rate less than that).

 

ToR isn't an option because it would be used for an application that needs low latency (similar to VoIP).

 

Any thoughts on whether this would be effective and how to do it from a technical perspective?

[Guest]

Well if your provider is worth anything they have encrypted traffic, even if they check graphs and the like to analyze it, it wouldn't do them much good besides seeing that you are sending data to a specific server, to actually do anything even when using VPN not everything can be encrypted, the line between whatever website you visit and the server is unencrypted and always will be, however the line between you and the server is encrypted so they can see that the server talks to different services and that you are sending data to the server but they can't identify which user sends what to where.

[xairv 6]

I mean not my provider, but AirVPN's. For example, say I upload 50MB to Wikileaks from AirVPN between 13:45:21-13:45:29. If someone is monitoring the traffic volumes to/from the AirVPN server that I'm connected to (eg. the NSA or its equivalent in other countries), they can simply filter for connections which transmitted 50MB or more during the same 8 seconds. Then it's a simple task of identifying the graph which most closely matches. That would be the end of my anonymity.

 

This is not difficult to do considering that there are on average only 60-70 users connected to each AirVPN server at a time.

 

In order to prevent such analysis, it's necessary to keep transmission volumes and rates quite low and make your traffic graph dissimilar to the one which connects to the sensitive resource on the public side of the VPN. Encryption does nothing to defeat traffic analysis.

[Guest]

I mean not my provider, but AirVPN's. For example, say I upload 50MB to Wikileaks from AirVPN between 13:45:21-13:45:29. If someone is monitoring the traffic volumes to/from the AirVPN server that I'm connected to (eg. the NSA or its equivalent in other countries), they can simply filter for connections which transmitted 50MB or more during the same 8 seconds. Then it's a simple task of identifying the graph which most closely matches. That would be the end of my anonymity.

 

This is not difficult to do considering that there are on average only 60-70 users connected to each AirVPN server at a time.

 

In order to prevent such analysis, it's necessary to keep transmission volumes and rates quite low and make your traffic graph dissimilar to the one which connects to the sensitive resource on the public side of the VPN. Encryption does nothing to defeat traffic analysis.

 

That becomes very difficult given that AirVPN uses different entry IP from the exit IP so they wouldn't know which server it goes to and the requirements that AirVPN has for datacenters should decrease chances of anything being handed over to whichever government asks for things. Anyway padding anything is only doable by AirVPN also unless you are ONLY uploading to wikileaks for example at the time then yes they can likely see what is what(and encryption does help since it increases the size of your traffic meaning it is very difficult for them to match anything to an upload) but keep in mind lets say you are uploading to wikileaks but at the same time seeding a torrent with only a few KB/s then there it becomes impossible for them to match anything even if they take the encryption into account cuz the size you upload to wikileaks doesn't match anything they find. Basically it comes down to the fact they can't traffic analyze anything it isn't very reliable with all the factors they can't possible find out about

 

EDIT: BTW, it is 6:36 in the morning so if what I'm writing is kinda gibberish like I apologize have yet to sleep, I hope my point got across.

[xairv 6]

lets say you are uploading to wikileaks but at the same time seeding a torrent with only a few KB/s then there it becomes impossible for them to match anything even if they take the encryption into account cuz the size you upload to wikileaks doesn't match anything they find. Basically it comes down to the fact they can't traffic analyze anything it isn't very reliable with all the factors they can't possible find out about

That is the point exactly. So I'm asking if anyone has strategies for creating such random traffic. Obviously I can do it on the download side easily. For example, by downloading random files with curl and setting rate limitation at random values. On the upload side it's a bit more difficult to create random traffic at random rates.

[Guest]

 

lets say you are uploading to wikileaks but at the same time seeding a torrent with only a few KB/s then there it becomes impossible for them to match anything even if they take the encryption into account cuz the size you upload to wikileaks doesn't match anything they find. Basically it comes down to the fact they can't traffic analyze anything it isn't very reliable with all the factors they can't possible find out about

That is the point exactly. So I'm asking if anyone has strategies for creating such random traffic. Obviously I can do it on the download side easily. For example, by downloading random files with curl and setting rate limitation at random values. On the upload side it's a bit more difficult to create random traffic at random rates.

 

You could run an MMO game, it is small bits of data but they force you to upload all the time to tell the servers what you are doing.

[zhang888 1066]

What is the actual use case of this? Except the pseudo anti NSA panacea.

First of all, it's technically impossible for the Air server to initiate legit traffic to the client, if the client did not ask it.

This could only be accomplished by sending the client random junk (aka DDoS) or by making a "feature" in the Air

client to send junk to the server, both of which are a simple waste of resources without any practical use case.

Even if your theory was true (no evidence of such correlation were ever used to catch an activist/whistleblower, btw)

how exactly adding 500kb of junk will solve that problem? The entry IP will still have the same amount of users

connected to it. The average amount of utilized bandwidth for each Air server is far more than 100Mbit/s. That

is a very meaningless "pad" even if you somehow do it manually, like downloading a file as you mentioned.

 

 

If you upload materials to sensitive organizations, Tor is your choice.

Wikileaks is not a good example, they use SecureDrop for a long time. FreedomOfPress do as well.

Part of this system is decentralizing the material and IPs of where the data is sent to with Tor.

[xairv 6]

The actual use case is irrelevant as it was a general question. One example would be making a voice call via a SIP-PSTN gateway service without revealing one's actual location. ToR is not an option in this case as its latency makes it unusable for VoIP purposes.

 

This could only be accomplished by sending the client random junk (aka DDoS) or by making a "feature" in the Air

client to send junk to the server, both of which are a simple waste of resources without any practical use case.

Not really. It would be possible to send and receive random data at random rates to and from a popular service, for example Instagram or Facebook, in order to mask the connection to the more sensitive resource. That would have the effect of randomising the traffic graph of the encrypted tunnel between the client and AirVPN's server. Alternatively, it could be done by making a lot of DNS requests to AirVPN's DNS server, although I would like to find a more efficient solution. In both cases it would be very difficult to correlate random anonymous connections to Facebook/Instagram or DNS lookups with a connection to the SIP-PSTN gateway.

 

how exactly adding 500kb of junk will solve that problem? The entry IP will still have the same amount of users

connected to it. The average amount of utilized bandwidth for each Air server is far more than 100Mbit/s. That

is a very meaningless "pad" even if you somehow do it manually, like downloading a file as you mentioned.

Aggregate bandwidth utilisation is irrelevant for traffic analysis purposes as each connection's source and destination IP and port is visible to the upstream provider. I.e. they can see the traffic graph of each client's OpenVPN tunnel.

 

Even if your theory was true (no evidence of such correlation were ever used to catch an activist/whistleblower, btw)

I suggest you become familiar with the available research before making such authoritative statements. Eg.:

http://arxiv.org/pdf/1410.2087.pdf

http://pages.cs.wisc.edu/~salinisk/642/website_fingerprinting_paper.pdf

https://www.mpi-sws.org/~druschel/publications/sigcomm15-herd.pdf

http://engagedscholarship.csuohio.edu/cgi/viewcontent.cgi?article=1108&context=enece_facpub

[zhang888 1066]

Not really. It would be possible to send and receive random data at random rates to and from a popular service

 

This is possible from your side, and nothing prevents you from doing that. But nothing can be done from Air Exit <-> Destination for that purpose.

Your traffic, real or padded, will go to the destination the same way.

SIP consumes less traffic than HTTP sessions, so again not sure what you want to hide there in the multi hundred mbit's of each server, but you

can download Linux torrents, it will give the same, if not better effect of random connections.

Although it will be still the same destination from your original source IP.

 

Aggregate bandwidth utilisation is irrelevant for traffic analysis purposes as each connection's source and destination IP and port is visible to the upstream provider. I.e. they can see the traffic graph of each client's OpenVPN tunnel.

 

This sounds like a mix of technical words without any sense, sorry.

I think you should review the concept of NAT and what an "upstream provider" is.

What an adversary may see, is 'x' connections to 5 destination ports (22/53/80/443/2018) of an entry IP,

and that's it. Then, if they know the exit IP (not a hard task but that will require targeting Air infrastructure

specifically, as simple traffic graph is not enough because IPs are different) they will see the exit IP sending

traffic to thousands of destinations at random hosts and ports every second.

So there is no "traffic graph" - there are 2 unrelated graphs so far, and you cannot proof any relation between

them, even if there is a high bandwidth user that is supposed to allegedly "pop out" from the mass - since you

cannot know that his source IP is the one that caused the traffic to exit from the exit IP. It could easily be one

of the hundred of currently connected clients that just started a streaming/torrent download.

Upstream providers has absolutely nothing related to this discussion and it's from completely different part

of the networking world. In many cases, real upstream providers of the ISPs the VPN servers are located at, will

not even see the source traffic. Because incoming traffic to a VPN server in Germany from a user in China can

take completely different route to the ISP than outgoing traffic to United States that the user generates.

 

I suggest you become familiar with the available research before making such authoritative statements. Eg.:

 

I consider myself quite familiar with available research on the topic. The more relevant thing

I thought you would mention would be the Cisco NetFlow, which all ISPs that are complying

with lawful interception are using.

None of the links you sent actually talk about public services based on OpenVPN, and only

one is talking about comparing TCP ACKs of the client and the destination.

This is impossible in case of OpenVPN - since the ACKs of the client<->VPN have completely

different timestamps and sequence numbers than the ACKs of the destination<->VPN.

And if you are using UDP, there are no ACKs at all so there is very little chance to fingerprint

an encrypted AES256 UDP stream with some TCP events at the other end, with tens of thousands

IPs and ports at the destination.

 

I asked about a case where an activist was caught using adversarial traffic analysis of a VPN service,

which did not include logging, backdoors and targeted attacks.

[xairv 6]

Zhang, I'm not interested in your opinion. There is plenty of research, including what I linked to, showing that VPNs provide little to no protection against traffic analysis and that such analysis is well within the means of any intelligence agency.

 

FYI, in the absence of traffic padding, it is trivially easy to match a user's real IP to his actual usage based on, eg.:

1. traffic volume graphs of connections to/from AirVPN entry IPs and each client's IP (one graph per client IP)

2. traffic graph of connection between SIP server and an AirVPN exit IP

 

If you have any practical advice as to how I may generate randomised traffic with plenty of entropy, that would be useful.

 

Thanks.

[zhang888 1066]

it is trivially easy to match a user's real IP to his actual usage based on, eg.:

1. traffic volume graphs of connections to/from AirVPN entry IPs and each client's IP (one graph per client IP)

2. traffic graph of connection between SIP server and an AirVPN exit IP

 

You still did not show how, and I doubt you will since this is why people using VPNs.

I asked you to quote a sentence or a case and you didn't provide any, yet it is "trivially easy". OK.

What you are doing is spreading FUD, but that won't help you and won't help the community either.

My opinions are not addressed to you, but to people that might believe such conspiracies and want

to have technical explanation without  having to make that research on their own.

 

If you want to generate random traffic, for your own placebo effect, I already said that any P2P application

that downloads/uploads to random peers will do exactly that.

 

The place where you have to worry about more is your SIP server that is not connected to any VPN.

This is where you need cover traffic - muted calls to yourself over the WAN interface, to be as much

similar to the real traffic you want to conceal. Each case and protocol has their own cover traffic practices.

[xairv 6]

 

it is trivially easy to match a user's real IP to his actual usage based on, eg.:

1. traffic volume graphs of connections to/from AirVPN entry IPs and each client's IP (one graph per client IP)

2. traffic graph of connection between SIP server and an AirVPN exit IP

 

You still did not show how, and I doubt you will since this is why people using VPNs.

I asked you to quote a sentence or a case and you didn't provide any, yet it is "trivially easy". OK.

 

The following paper, which I linked to earlier, explains how traffic pattern matching works: http://arxiv.org/pdf/1410.2087.pdf

In that case it highlights the possibility of timing analysis. I.e. it shows that padding alone is not enough and that a constant stream of randomised data is necessary to defeat such analysis.

[zhang888 1066]

The paper explains completely another threat model and another analysis pattern, I asked you to explain how it applies here.

 

constant stream of randomised data is necessary to defeat such analysis

 

Constant stream of incoming/outgoing encrypted (random) data already occurs on each server.

Does that mean that you finally acknowledge the fact that this research cannot apply on multi-user public OpenVPN,

server where more than one user is using the server at every present time? Especially where most users use UDP? Hopefully.

[xairv 6]

Constant stream of incoming/outgoing encrypted (random) data already occurs on each server.

Does that mean that you finally acknowledge the fact that this research cannot apply on multi-user public OpenVPN,

server where more than one user is using the server at every present time? Especially where most users use UDP? Hopefully.

No, it does not mean that at all.

 

As I pointed out earlier, upstream providers (hence authorities) can easily isolate traffic volume graphs of connections to/from AirVPN entry IPs and each client's IP (one graph per client IP)

which can be matched to the traffic graph of connections to a unique resource. I.e. one which only one of the users of a node or location accesses.

The paper shows that timing attacks have a >90% accuracy in identifying such traffic from a sample of 100. That is not so different from the average number of users on an AirVPN node.

[zhang888 1066]

As I pointed out earlier, upstream providers (hence authorities) can easily isolate traffic volume graphs of connections to/from AirVPN entry IPs and each client's IP (one graph per client IP)

 

So far, correct, the datacenter inevitably knows all the connected IPs to the servers. How does that hold up with the bigger conspiracy:

 

which can be matched to the traffic graph of connections to a unique resource. I.e. one which only one of the users of a node or location accesses.

 

matched to what? you will have 100 client IPs connecting to 10000 destination IPs with various states. You cannot know which

one of the 100 clients is accountable for any of those connections, with the only exception of outgoing DDoS attack. Then you

may see a large traffic peak that the server cannot handle and huge outgoing traffic spike from the server.

 

The paper shows that timing attacks have a >90% accuracy in identifying such traffic from a sample of 100. That is not so different from the average number of users on an AirVPN node.

 

Why are you cherry-picking random numbers to hold a theory you did not understand in the paper?

First of all, the 90% accuracy was on known websites:

"The first dataset consists of home pages of each of the top Irish health, financial and legal web sites as ranked by www.alexa.com under its Regional/Europe/Ireland category in November 2014."

 

That means that the adversary already knows the exact size of those pages and the size of them is reproducible from various clients. That is not a valid assumption in case of any user-generated

traffic like VOIP/Messengers, since there is no predictable traffic pattern to have for the baseline.

 

Next:

"We prune the pages that fail to load and then for each of the top 100 sites."

 

100 sites does not equal 100 users behind OpenVPN. If you don't understand this difference, you either did not understand the paper of trying to hold a theory that simply does not apply here.

[xairv 6]

Zhang, I'm not interested in anything you have to say. You've missed the point entirely. This is not about matching a user to a resource; it's about the reverse situation. The traffic graph on the SIP side is known - it's a commercial provider. 100 client IPs produce 100 traffic graphs; it is then only a matter of filtering them, which is exceedingly trivial. It won't work 100% of the time, but 90% is enough. Even 20% of the time is enough, in fact.

 

Is there some way I can add you to an ignore list so I don't have to see your, frankly pointless, posts?

 

If anyone else has suggestions as to how to generate high-entropy random traffic in both directions, I'd be interested in hearing them. Bittorrent is not a good option, IMO, because there will be gaps in the upstream side and it doesn't provide a lot of entropy in transmission rate.

[pr1v 36]

Open a VPN account anonymously and pay it with bitcoins. Then connect to a public wifi and use the vpn there.

If you find a solution with tor, then use vpn+tor+whatyouwant

[Staff 9972]

Zhang, I'm not interested in anything you have to say. You've missed the point entirely. This is not about matching a user to a resource; it's about the reverse situation. The traffic graph on the SIP side is known - it's a commercial provider. 100 client IPs produce 100 traffic graphs; it is then only a matter of filtering them, which is exceedingly trivial. It won't work 100% of the time, but 90% is enough. Even 20% of the time is enough, in fact.

 

First of all, this was a quite popular mistake that took place in the academic world between approx. 2010 and 2014. Luckily in 2014 the fallacy of tons of such studies and presumed fabulous attacks based on web fingeprinting, netflow etc. have been revealed as a gigantic castle in the sky caused by outstanding flaws in the papers you cited and wrong assumptions. Just like any sector operator already knew by experience. Luckily most of those papers remained in pre-print and never passed any peer-review for publication in any scientific magazine and such.

 

The problem is always the same in the academic world: "publish or perish". Another problem is that in the IT, sometimes a pre-print paper is taken seriously before a proper peer-review.

 

See also here to get aware of the bias and flaws of tons of such researches:

https://blog.torproject.org/blog/traffic-correlation-using-netflows

 

And an independent confirmation of the fundamental fallacy of such studies:

http://www1.icsi.berkeley.edu/~sadia/papers/ccs-webfp-final.pdf

 

In your specific case, you are even below the minimal attack requirements of the papers you cite, because you assume to monitor only "one side", i.e. an insufficient segment of the network. Not that this is very important, because even if you raise your requirements, the attack is doomed to fail anyway. See the first article  linked above.

 

 

 

Is there some way I can add you to an ignore list so I don't have to see your, frankly pointless, posts?

 

It is not possible to hide messages in an IPB forum from a user point of view, this option is not available, we're sorry. However, we inform you that ad hominem attacks are not allowed on our forums and will cause limitations to the infringing account.

 

 

If anyone else has suggestions as to how to generate high-entropy random traffic in both directions, I'd be interested in hearing them. Bittorrent is not a good option, IMO, because there will be gaps in the upstream side and it doesn't provide a lot of entropy in transmission rate.

 

Traffic encryption is one of the highest entropy traffic available (one method to block Tor and VPN services is early detection of high entropy traffic and subsequent packets dropping). Of course a VPN, or Tor, increases entropy of your traffic only from your node to the final VPN or Tor exit node, so end-to-end encryption should be mandatory as well.

 

You might also consider padding to prevent potential identification of traffic type INSIDE the tunnel, in spite of the traffic entropy. Although currently such techniques are not yet very successful, they were applied already 15 years ago, then dropped, and now re-considered - so they are continuously refined. Maybe it's too early anyway to take action against them but consider your threat model.

 

Remember anyway that traffic entropy is not strictly related with the discussed issue, and could not help at all. Partition of trust may become necessary. Again, you need to define your threat model.

 

Kind regards

[xairv 6]

THanks. That is a useful response. However, the papers linked to  are criticising the use of traffic pattern matching in non-targeted attacks with pre-computed fingerprints of relatively short transmissions (single web page, for example). The ToR network has relatively high, variable latency and millions of users across thousands of exit and mix nodes, making targeted attacks in that fashion quite difficult.

 

But the situation I'm questioning is, as an example, pattern matching an active VoIP call while connected to a VPN. Eg.: client -- VPN provider -- SIP gateway. Assuming a government agency wanted to reveal the client's actual IP address, they would first seek connection data from the SIP provider. They may then notice that the client has made connections from a certain VPN provider. At that point, they would probably subpoena the VPN's host for the following netflow data:

1: netflows from the relevant set of VPN servers to the SIP gateway in question

2: netflows from clients to VPN ports of the relevant set of VPN servers

 

This is a targeted attack at a specific time against a transmission while it's taking place (not simply a fingerprint, but an actual transmission in progress). Network distortion would be relatively low as the point of data collection would be not more than a couple of hops from the server and very close in latency terms. The transmission itself is quite long - typically 10 minutes or more for a phone call - which gives plenty of data for traffic analysis. In addition, each location has quite a small user base. In the case of AirVPN, at present only 3200 in the Netherlands, 1000 in Sweden, 500 in Germany, etc. Entry and exit nodes are in a small set of known IP addresses, and are within the same datacenter. This is not comparable to ToR with its millions of concurrent users and nodes spread over multiple continents.

 

 

I agree that encrypted data does provide a lot of entropy, but I'm looking for rate entropy in this case, not data entropy. Obviously I could simply leave a torrent running at a high rate in both directions around the time of the transmission. That would easily mask VoIP data transmission through the same VPN tunnel. HOwever, I would prefer not to do that because I think it's selfish to generate that kind of unnecessary traffic when there are other possibilities which use far less of the VPN provider's resources. Generating transmissions with high rate entropy is not difficult in downstream direction, but in the upstream direction it is more difficult. So that is the question.

 

Thanks again for the informative response.

[Staff 9972]

But the situation I'm questioning is, as an example, pattern matching an active VoIP call while connected to a VPN. Eg.: client -- VPN provider -- SIP gateway. Assuming a government agency wanted to reveal the client's actual IP address, they would first seek connection data from the SIP provider. They may then notice that the client has made connections from a certain VPN provider. At that point, they would probably subpoena the VPN's host for the following netflow data:

1: netflows from the relevant set of VPN servers to the SIP gateway in question

2: netflows from clients to VPN ports of the relevant set of VPN servers

 

Yes, this has nothing to do with the previous papers you linked. None of the cited techniques becomes necessary. Which is, unfortunately, excellent for the attacker, since those techniques don't work effectively.

 

Once the VoIP conversation origin is known, the attacker has so many options. It could for example attach black boxes on the VPN server, so that the VPN company can't realize that the server is wiretapped and the boxes can be controlled directly by the attacker, at the same time preventing any possible judicial reliability problem that could arise from data reported only by the datacenter equipment. Then, the attacker hopes that the target will re-connect again to the same VPN server and connect again to the same destinations via VoIP or any other ascertained protocol/application etc.

 

This is a situation where the attacker controls all the needed network segments AND knows one of the origin nodes and the destination node already. It can do nothing to identify the target with the available data at that moment, but if the target re-walks the same path, chances that it will be identified are significant if partition of trust is not performed.

 

We have discussed how to defeat such an attacker years ago with what we trivially called "partition of trust".

 

Kind regards

[kebi 2]

Hello guys, so i know its an old topic, but my question is the same context, so i thought i could resurrect some discussion on this.

My goal is not "obfuscation" per se, but i would like to understand in laymans terms a question thats a bit more complicated for me to understand.

So, i beg your indulgence to follow along.

I recently visited 

 

https://whoer.net/
 

and on the site, it told me that my TCP/IP was 1380.

I know that the max packet size for ethernet is 1500.

Practically, we send packets sized as the lowest MTU (Maximum Transmission Unit) on the path, which is typically 1500 bytes(for Ethernet) of data including TCP(20 bytes) and IP headers(20 bytes) (*when they don't have options)
The frame header is added too so it's get up to 1518 bytes (with 801.Q it's 1522).

 

Now suppose i have connected to OpenVPN, and i am downloading a file from a filesharing site, and at the same time i am downloading torrents in the background, and i am streaming a youtube video.

So 2 distinct streams of downloads via browser, and 1 stream via utorrent is happening simultaneously. 

 

I know that the ISP cant read inside the packet because its encapsulated in encryption. I also think, and correct me if im wrong, but the port numbers in the app and utorrent also arent visible to the ISP, only the DC of the VPN (because they have to decrypt the client traffic and add new headers and send it to the destination server.)

 

So, i know that the max MTU packet size of my Openvpn connection will be 1380.

So in a single packet, will it contain data MIXED from all 3 streams? Or will the packets be 3 distinct ones, but all are encrypted anyway so nobody gets to peek inside? Sorry if its a dumb question, but i am just curious as to how this all works, but im not really smart enough to get the whole NAT thing.