Rendered at 08:05:08 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
usernomdeguerre 1 days ago [-]
I get the impression that much of Xray's usage is in mainland China, do many other ecosystems use it? If not, why not?
Naively I would expect solutions out of Mainland China to be more sophisticated due to the internet restrictions within the country and the number of people who are digitally-connected.
But perhaps they cover for usecases one doesn't see outside the gfw.
amritananda 1 days ago [-]
You can also use it to get around captive portals where some traffic is still allowed. Some Airline flights where messaging services are free only check the SNI, so setting the Xray domain to whatsapp.com or something similar usually works.
ranger_danger 1 days ago [-]
What if ESNI/ECH is being used?
amritananda 1 days ago [-]
I'm assuming you'll have to configure your DNS to use the captive portal DNS which would defeat ECH. The only time I was able to get this working as a captive portal bypass I was using a hardcoded remote IP as my Xray host so DNS wasn't an issue.
ranger_danger 13 hours ago [-]
I don't see how that would be possible as DNS requests are not technically linked to web requests in any way, other than that they are sometimes made in close temporal proximity to each other, but caching means this isn't always the case.
I could just visit 1.2.3.4 to reach the captive portal, but my question was more about "how can they allow based on SNI if that is encrypted too"?
Regardless of what DNS server is used, my connection requests to websites (whether to a real messaging site, or a faked xray one, or whatever) might be using ECH, so how could they allow the request in that case? I don't think they can control whether those messaging services are using ECH either.
amritananda 11 hours ago [-]
ECH is bootstrapped using DoH. IIRC there's a TXT or other record that distributes the key used used for encrypting the initial handshake.
Just blocking DoH would probably be enough to force clients to fall back to regular DNS. This happens automatically for a captive portal with a whitelist. You could probably take care of clients with a cache by just dropping any connection without a readable SNI. I guess it depends on implementation, but I'd wager most clients would fall back to a non-ECH connection anyway (since it doesn't really add anything - you could just sniff DNS to figure out what domain the client is trying to connect to).
ranger_danger 8 hours ago [-]
But not everyone has their system set to use the DHCP's DNS, and browsers/some devices override that with some other public DoH provider by default (or as an option)... and not allowing that would break too many people's access IMO.
I feel like a simple IP block/whitelist for the messaging service would be so much easier than all this SNI business. There's nothing stopping them from verifying specific SNI certs against the real ones anyway if you went the xray route.
wartywhoa23 1 days ago [-]
Xray is huge in Russia now. Often the only way to set up a tunnel to the outer Internet.
As to the vulnerability reported - I think it's still better to place Xray behind a reverse proxy and make that manage the TLS stuff.
ranger_danger 1 days ago [-]
There are other countries that routinely block traffic like Iran or Russia, but there are also some simple methods that go right past the GFW many times, like VPN traffic that is tunneled through regular TLS, or even just plain SSH.
The "new hotness" is randomizing your TLS fingerprints and masquerading as legitimate web traffic/domains, as well as tunnel/proxy/VPN setups that utilize multiple endpoints at once to spread out the "suspicion" of all your traffic going through a single host all the time.
1 days ago [-]
sekisusam 1 days ago [-]
[dead]
eriwang915 1 days ago [-]
Xray-core's pinnedPeerCertSha256 treated an inserted leaf as the pinned cert, and the fix commit never called it a vulnerability.
LoganDark 1 days ago [-]
Your LLM left out the clear hypocrisy and the part where the fixed version still had a vulnerability
ddtaylor 22 hours ago [-]
His comment actually added value, but yours doesn't seem to have the same value.
LoganDark 20 hours ago [-]
Mine specifies the value that I thought was missing, though?
21 hours ago [-]
soltanov 1 days ago [-]
Fixing the code is only half of incident response. Without an advisory, affected-version range, and downstream notification, users cannot know whether they remain exposed.
Naively I would expect solutions out of Mainland China to be more sophisticated due to the internet restrictions within the country and the number of people who are digitally-connected.
But perhaps they cover for usecases one doesn't see outside the gfw.
I could just visit 1.2.3.4 to reach the captive portal, but my question was more about "how can they allow based on SNI if that is encrypted too"?
Regardless of what DNS server is used, my connection requests to websites (whether to a real messaging site, or a faked xray one, or whatever) might be using ECH, so how could they allow the request in that case? I don't think they can control whether those messaging services are using ECH either.
Just blocking DoH would probably be enough to force clients to fall back to regular DNS. This happens automatically for a captive portal with a whitelist. You could probably take care of clients with a cache by just dropping any connection without a readable SNI. I guess it depends on implementation, but I'd wager most clients would fall back to a non-ECH connection anyway (since it doesn't really add anything - you could just sniff DNS to figure out what domain the client is trying to connect to).
I feel like a simple IP block/whitelist for the messaging service would be so much easier than all this SNI business. There's nothing stopping them from verifying specific SNI certs against the real ones anyway if you went the xray route.
As to the vulnerability reported - I think it's still better to place Xray behind a reverse proxy and make that manage the TLS stuff.
The "new hotness" is randomizing your TLS fingerprints and masquerading as legitimate web traffic/domains, as well as tunnel/proxy/VPN setups that utilize multiple endpoints at once to spread out the "suspicion" of all your traffic going through a single host all the time.