[ramity]

I see I was mistaken, but I'm tempted to continue poking holes. Trying a different angle, though it may be a stretch, but could a caching layer within the VPN provider cause these sort of "too fast" RTTs?

Let's say you're a global VPN provider and you want to reduce as much traffic as possible. A user accesses the entry point of your service to access a website that's blocked in their country. For the benefit of this thought experiment, let's say the content is static/easily cacheable or because the user is testing multiple times, that dynamic content becomes cached. Could this play into the results presented in this article? Again, I know I'm moving goalposts here, but I'm just trying to be critical of how the author arrived at their conclusion.

[seszett]

This is about ping though, so presumably ICMP packets. There is no content to cache as the request is sent with random data that must be sent back in the reply.

It is very unlikely that VPN providers use convoluted caching systems just to make their ping replies appear to come from a different region than the one they claim to be in. It would be much more likely for them to add a little latency to their responses to make them more plausible, instead.

[ghxst]

Assuming a secure connection this isn't possible without terminating TLS and re-negotiating.