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:
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.
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.
I personally ran into the legacy setup issue for running vanilla Wireguard for my setup before Tailscale is a thing and have to manually manage keys, routing and DNS.
But one thing Tailscale has that annoyed me is that they are using 100.64 CGNAT addresses (which is more RFC-compliant) but conflicts with one of my cloud service provider's pre-configured DNS, NTP and software mirrors setup. Using it became more or less messy for this reason.
The ZIP code system in the US CAN somewhat work the same way.
The usual 5 digit ZIP code routes to your Post Office. The longer ZIP+4 code routes more detailed locations: a city block, an apartment building. The even longer ZIP+6 code goes to something called delivery point, which to my understanding is basically a single mailbox. The ZIP+6 code is in fact embedded in the bar code sprayed onto the mail piece.
This kind of techniques is also used to send underground gambling, crypto, sex and so on scams on Apple's platform targeting Chinese speaking community in the past few years.
They will typically change their name to scam text just like the one here and share an album in iCloud Photos to the victim. This will trigger a legit notification email from Apple to you and a push notification on your Apple devices. Both has low chance of being filtered by anyone.
Moral aspect apart, it is a very clever way of exploiting a system.
<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.