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:
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.
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.
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.
Honestly I think interviews are just not something Linus does a lot of. He has a particular workflow where he writes a script for himself and then acts it out for the camera. Changing it up would be going outside his comfort zone and there wasn't a lot of time.
That said there is a "behind the scenes" video where we initially toured him through the house which is a lot more conversational, but it's on their pain subscription service.
They are using BGP and routing nodes (backbones), recreating a mini IP (layer 3) network I think.
I've used raw wireguard in a p2p fashion to interconnect LANs. I run wireguard on each segment directly inside the network routers.
Just make sure all LANs are using a different subnet. A /24 is standard. Then configure all the peers and you get a fully peer to peer network. No relays. You only need one side of every peer "pair" to be reachable from the internet.
I do have a small management script to help peer discovery (dynamic IPs) and key exchange, but it's not strictly required. With a dozen nodes or so, it's maintainable manually. Wireguard supports roaming natively, as long as one peer can reach the other.
I have my own Wireguard mesh network between my home network and a couple of VPSes. I configured it all manually, too. I'm basically running a virtual public network and have it routing a /24 (BGP announced at the VPSes) back to my home.
A little morbid, but have you considered setting up a beneficiary for the allocation or detailing this asset in a will? That's some special, virtual real estate you have there.
That is correct. IPSec sucks but we have already paid the price of being forced to figure it out in big organizations, so, not much motivation to figure out another thing.
The only use case I can imagine is a legacy game which performs a server search by broadcasting/scanning the local network. And even then - most of the time these games had server browsers.
My personal choice for something like this would be Tailscale/Headscale. Runs over Wireguard and handles a ton of niceties like DNS for connected nodes automatically.
This kind of defeats the purpose of TPL. Part of TPL is setting up your own network segment. There's a dashboard that shows who has what working.
Part of the fun of TPL isn't just that your computer can talk to another computer, it's that you have your own setup configured form the ground up so your /24 can talk to other /24s on TPL. I 100% understand some people will not enjoy that and won't find it fun, and that is ok. Some people do enjoy learning new things about setting up infrastructure, and this scratches some of that itch.
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.
I mean, this is pretty much the standard of setting up satellite offices for businesses and whatnot. Lots of people are extremely familiar with IPSec, it's not that hard.
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.
If there was a zip code that was just virtual PO Boxes, it could use the existing change of address machinery to slap the actual delivery address on when addressed with a virtual box. Assuming they used an entire sectional center facility for it, you could have 100 zip codes, with 6 digits of unique delivery points, so 100 million virtual boxes.
he said "somewhat work the same way". For a person who doesn't care about whether they have to get a new code when they move, the systems are equivalent in their value proposition. Thus is the case for most things that "somewhat work the same way".
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.