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.

6 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.

    1. Re:Seems trivial to mask by joshuao3 · · Score: 4, Funny

      Actually I think you are missing a completely different point. You don't have to speed up connections to match the speed of non-vpn traffic, you just have to slow everything down so that you can't be sure which is VPN and which is normal.

      So... Comcast really had our best interests in mind after all?

      --
      Monitor bandwidth usage on IIS6 in real-time: http://www.waetech.com/services/iisbm/
  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. 97% is not even close to commercially viable by Thanshin · · Score: 4, Insightful

    97% to detect irregular behavior is completely useless unless the rate of regular and irregular behavior is reasonably balanced. In most commercial settings the rate is biased towards regular behavior by several orders of magnitude. In other words, thousands of times more more biased than 97:3.

    Therefore, this system will have orders of magnitude more false positives than positives. So the positives will just disappear inside a mass of angry customers.

    In short; the ratio of success has to be in the same order of magnitude as the ratio of irregular behavior. e.g.: for Netflix you'd need better than 99.99% precision.

  5. 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.