You say what I described is impossible but it’s been demonstrated by researchers such as “CPV: Delay-Based Location Verification for the Internet” by AbdelRahman Abdou with the Department of Systems and Computer Engineering, Carleton University Ontario.
Furthermore, on top of that method, if a company has access to data from servers in multiple places along the chain between endpoints, then they can see that a series of packets of specific size are traveling in a specific direction, narrowing down the location of the other endpoint. A company like Amazon, whose AWS servers make up almost 30% of the internet.
One of the more convoluted methods to defeat this approach was to simply add more stops along the chain, fragment the encrypted data into multiple parts, and pass it along random paths to the endpoint. I believe, but I could be wrong, that Tor utilizes this method. The problem with that is: it’s slower.
It is impossible. CPV is only going to allow the attacker to know that the device is probably not located next to the VPN server. It can only prove a positive, not a negative.
The second method you’re describing is only possible for people who control internet infrastructure and are able to infer correlations data going into your VPN server with data going out of your VPN server, which is both easier and more difficult than you’re suggesting. The attacker does not need to most of the internet routers because they only care about the data going into and out of the VPN server (it’s onion routing where the attacker needs to control many routers), but the attacker does need to have a powerful enough device to be inferring (hopefully) encrypted network flows on the public network to the packet sizes of encrypted VPN traffic for all of the traffic that is passing through that VPN server at the same time.
You say what I described is impossible but it’s been demonstrated by researchers such as “CPV: Delay-Based Location Verification for the Internet” by AbdelRahman Abdou with the Department of Systems and Computer Engineering, Carleton University Ontario.
Furthermore, on top of that method, if a company has access to data from servers in multiple places along the chain between endpoints, then they can see that a series of packets of specific size are traveling in a specific direction, narrowing down the location of the other endpoint. A company like Amazon, whose AWS servers make up almost 30% of the internet.
One of the more convoluted methods to defeat this approach was to simply add more stops along the chain, fragment the encrypted data into multiple parts, and pass it along random paths to the endpoint. I believe, but I could be wrong, that Tor utilizes this method. The problem with that is: it’s slower.
It is impossible. CPV is only going to allow the attacker to know that the device is probably not located next to the VPN server. It can only prove a positive, not a negative.
The second method you’re describing is only possible for people who control internet infrastructure and are able to infer correlations data going into your VPN server with data going out of your VPN server, which is both easier and more difficult than you’re suggesting. The attacker does not need to most of the internet routers because they only care about the data going into and out of the VPN server (it’s onion routing where the attacker needs to control many routers), but the attacker does need to have a powerful enough device to be inferring (hopefully) encrypted network flows on the public network to the packet sizes of encrypted VPN traffic for all of the traffic that is passing through that VPN server at the same time.