Slashdot Mirror


How To Defeat VPN Location-Spoofing By Mapping Network Delays (thestack.com)

An anonymous reader writes: An interesting paper from a PhD student in Ontario outlines a system which in initial tests has proved 97% effective at unmasking geo-spoofing VPN users. The Client Presence Verification (CPV) system presented in the paper utilises analysis of delays in network packets in order to determine the user's location, disregarding the IP address geolocation information which currently underpins the efforts of content providers such as Netflix to prevent VPN users accessing content which is not licensed in their country. The detection system was tested at global network laboratory PlanetLab using 80 network nodes based in the U.S. and Canada.

4 of 81 comments (clear)

  1. Seems trivial to mask by DreamMaster · · Score: 5, Interesting

    I haven't RTFA yet, but If the analysis is solely based on network delays, then a VPN company could simply introduce randomized delays to all it's users, even the local ones. Then an analysing service wouldn't be able to definitively say whether any given user is geo-spoofing or not. The best they could say is that the connecting service is likely a VPN.

  2. False positives by Stuarticus · · Score: 4, Interesting

    False positives are a pretty major issue when you look at Netflix's user base, 97% effective isn't very good if you're going to refuse to serve content to over a million paying customers every day.

    --
    If you think someone isn't free to have a different definition of "freedom" you may be a tyrant.
  3. Re:Mask this by violating TCP rules? by silas_moeckel · · Score: 5, Interesting

    The satellite guys have done this forever. Moving the syn/ack to the VPN head end is a stock application at this point.

    --
    No sir I dont like it.
  4. Re:Mask this by violating TCP rules? by Quince+alPillan · · Score: 4, Interesting

    What you're talking about is a forward proxy. Forward proxy servers do this (and will even proxy SSL traffic).

    In the whitepaper, they're actually talking about making a new protocol that measures the one way distance time and compares it to their database of network speeds and distances to determine your location. Their solution is an application-level solution, which depends upon a Forward Proxy to know about the protocol and spoof it correctly.

    The problem with their solution is that network speeds are fluid and a computer with a problem (e.g. a local neighborhood node or a legitimately slow client that is delaying all traffic 20-30ms) can make their estimates wildly inaccurate. Even today, Cogent to Level 3 has a 197ms ping in LA. In the paper, they used average speeds for various known networks. This can be mitigated somewhat by measuring client traffic and only counting outliers (e.g. all traffic from a certain area being delayed the same, except for our rogue client) but it still doesn't mitigate the local computer problem.

    A second problem with their solution is that it only measures distance - a server in Miami, Florida accepting data from a client in Seattle, Washington is 2732 mi and the same distance (roughly) as Lima, Peru. This means that a client in Lima should pretend to be from Seattle when they connect to their combo VPN/Forward Proxy in Miami. Satellite customers are will almost always have extremely high latency because of the round trip between Earth and the Satellite, even if they're legitimately in the correct area.

    In addition, they were only able to make this accurate to about 400km, which means if you have a nearby beneficial country within that range, you can use a VPN in that country and they still won't know.