Readit Newsericdiao commented on VPN location claims don't match real traffic exits ipinfo.io/blog/vpn-locati... · Posted by u/mmaia
Some of our (IPinfo) services are hosted on GCP, and because our service is widely used (with 2 trillion requests processed in 2024) people sometimes say they cannot access our service. It is usually due to how Google's device-based IP geolocation is used. The user's IP address is often mistakenly identified as being located in a country where Google does not offer service.
I have seen a Europe-based cloud hosting provider's IP ranges located in countries where Google does not provide service. This is because these IP ranges are used as exit nodes by VPN users in that country.
Device-based IP geolocation is strange. We prefer IP geolocation based on the last node's IP geolocation. We hope to collaborate with Google, Azure, and other big tech on this if they reach out to us.
Yeah. This can be a problem.
The device-based IP geolocation, because the algo is so sensitive and the result can be altered with few devices behind the IP (at least for Google), can be used theoretically steering / trick big techs to believe that the IP is at location it is not, just like VPN providers in your article by publishing "bogon" geofeed etc. This defies their purpose of doing this in the first place: geolocking and regulatory requirements.
The "tech" is already there: browser extensions [1] that overwrite the JS GeoLocation API to show "fake" locations to the website (designed for privacy purpose). also dongles are available on gray market that can be attached to iPhone / Android devices to alter the geolocation API result by pretending it is some kind of higher precision GPS device but instead providing bogon data to the OS. Let alone after jailbreaking / rooting your device, you can provide whatever geolocation to the apps.
ericdiao commented on VPN location claims don't match real traffic exits ipinfo.io/blog/vpn-locati... · Posted by u/mmaia
Another related but non-VPN story related to IP geolocation:
Big techs (most notably Google) is using the location permission they have from the apps / websites on the user's phones / browsers to silently update their internal IP geolocation database instead of relying on external databases and claims of IP owners (geofeed etc). And this can be hyper-sensitive.
I was traveling back home in China last year and was using a convoluted setup to use my US apartment IP for US based services, LLM and streaming. Days into the trip and after coming back, I found that Google has been consistently redirecting me to their .hk subdomain (serving HK and (blocked by gov) mainland China), regardless of if I was logged in or not. The Gmail security and login history page also shows my hometown city for the IP. I realized that I have been using Google's apps including YouTube, Maps and so on while granting them geolocation permission (which I should not do for YouTube) in my iPhone while on the IP and in my hometown.
After using the same IP again in the US with Maps and so on for weeks and submitting a correction request to Google, it comes back to the correct city. (The tricks of restarting the modem / gateway, changing MAC address to get a new IP is not working somehow this time with my IS.
You can change what IP addresses it uses: https://tailscale.com/kb/1304/ip-pool
Uh Great. They added this feature! It cannot last time (few years ago) I checked.
I can somehow consider migrating now.
Heh, of all arguably-valid definitions of "LAN Party" I think this one is as far away from mine as you can get.
Traditional LAN party: Everyone brings their computers to one place to connect via a LAN, where they play games, swap files, demo stuff to each other, etc.
My LAN party: All my friends come over to my house and use the computers that I have already set up for them. Nobody brings their own. The point is to interact face-to-face, with video games as a catalyst. Swapping files and demos doesn't really happen since nobody brought their own computer. (My house: https://lanparty.house)
The Promised LAN Party: The LAN is extended, virtually, across multiple houses, so that the participants can play games, swap files, and demo stuff without actually leaving home. It's arguably no longer "local" but functionally it enables the same activities as a LAN party, other than the face-to-face interaction part.
I wonder who gets told their definition is "wrong" more. :)
Haha, have to drop the link to the recent Linus Tech Tips video on your house!
<del>No post / incident on CA/Browser Forum also.</del>
Edit: Incident on dev-security-policy@moz: https://groups.google.com/a/mozilla.org/g/dev-security-polic...
---
Translation by LLM of the post on Chinese forum V2EX:
LiteSSL appears to be a CA that only emerged last year. It provides free TrustAsia-backed wildcard certificates issued via ACME.
However, in my testing, its ACME server very frequently errors out with:
> Too many concurrent connections from IP 10.254.14.70 (limit: 10), > urn:ietf:params:acme:error:rateLimited:concurrent
This clearly indicates a backend misconfiguration: LiteSSL incorrectly treats the reverse proxy’s internal IP as the client’s real IP when applying rate limits.
More seriously, LiteSSL has a *critical authentication vulnerability*.
Its DNS-01 challenge cache appears to have a very long validity period, and it does *not* verify that a certificate issuance request comes from the same ACME account that completed the original DNS-01 challenge. As a result, anyone can arbitrarily re-issue (steal-sign) certificates that were originally issued via DNS-01.
You can browse certificates issued by this CA here (ECC/RSA behave similarly). Pick any certificate with a wildcard domain, and you can re-issue it using your own LiteSSL ACME account without triggering validation:
[https://crt.sh/?CN=%25&iCAID=438132](https://crt.sh/?CN=%25&iCAID=438132)
`ssyhwa.cloudns.cl` is a temporary domain I created for testing; it has already passed DNS-01 validation and can reproduce the issue.
`*.vaadd.com` was a randomly selected victim domain, and I was also able to successfully steal its certificate.