7 ms·

A VPN will not protect you from fingerprinting of your traffic patterns. VPNs just add a fixed overhead to all packets and maybe a bit of fragmentation. A well-

by ge0rg 8y ago

A VPN will not protect you from fingerprinting of your traffic patterns. VPNs just add a fixed overhead to all packets and maybe a bit of fragmentation. A well-positioned attacker with a large database of traffic fingerprints is probably easily able to re-calculate the traffic fingerprints for the common VPN protocols.

kardos 8y ago
For a clean setup where you're interacting with one website that makes sense. Perhaps less so with many streams. Could VPN protocols be modified to obfuscate traffic patterns (without adding intolerable latency or extra bandwidth costs)? Eg, rapidly change the MSS or add some padding?
- namibj 8y ago
  If there is significant data that just has to be transferred within a given, larger timespan, e.g., if you need that update within the day or upload the picture(s) you took over the course of your lunchbreak, or similar situations, you could transfer that data when you want to send masking traffic. This way you don't have to generate dummy data to serve as masking traffic.
  - kardos 8y ago
    Ah, that's clever. It's hard to come up with a bunch of bulk data that needs to be transferred 'sometime in the next day or two'. Phone updates might be one but they are sporadic, and backups could be another. Also you'd need a supply of near-term bulk transfers in both directions. Interesting idea for sure.
    - myself248 8y ago
      I hope someone notices this idea and implements this. Having two virtual network interfaces, one for high-priority traffic that you want to mask, and one for low-priority traffic that only gets sent as masking data, might be a good way to keep it low in the layer stack.
      - namibj 8y ago
        You need to be careful as to the interactivity of the protocols. Non-interactive transfers are _much_ easier to mask if you can use such delays due to the lack of things to correlate without massive noise.
e12e 8y ago
This might be true, but also AFAIK a new attack on otherwise secure VPNs: being able to predict visited sites based on bits up/down as well as traffic rate.

by ge0rg 8y ago

kardos 8y ago

For a clean setup where you're interacting with one website that makes sense. Perhaps less so with many streams. Could VPN protocols be modified to obfuscate traffic patterns (without adding intolerable latency or extra bandwidth costs)? Eg, rapidly change the MSS or add some padding?

namibj 8y ago
If there is significant data that just has to be transferred within a given, larger timespan, e.g., if you need that update within the day or upload the picture(s) you took over the course of your lunchbreak, or similar situations, you could transfer that data when you want to send masking traffic. This way you don't have to generate dummy data to serve as masking traffic.
- kardos 8y ago
  Ah, that's clever. It's hard to come up with a bunch of bulk data that needs to be transferred 'sometime in the next day or two'. Phone updates might be one but they are sporadic, and backups could be another. Also you'd need a supply of near-term bulk transfers in both directions. Interesting idea for sure.
  - myself248 8y ago
    I hope someone notices this idea and implements this. Having two virtual network interfaces, one for high-priority traffic that you want to mask, and one for low-priority traffic that only gets sent as masking data, might be a good way to keep it low in the layer stack.
    - namibj 8y ago
      You need to be careful as to the interactivity of the protocols. Non-interactive transfers are _much_ easier to mask if you can use such delays due to the lack of things to correlate without massive noise.

e12e 8y ago

This might be true, but also AFAIK a new attack on otherwise secure VPNs: being able to predict visited sites based on bits up/down as well as traffic rate.