Xray-core concealed a certificate verification bypass vulnerability | Hacker News Reader

Xray-core concealed a certificate verification bypass vulnerability

github.com

88 pointstimbill16 comments

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.

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.

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.

What if ESNI/ECH is being used?

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.

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.

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).

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.

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.

Xray-core's pinnedPeerCertSha256 treated an inserted leaf as the pinned cert, and the fix commit never called it a vulnerability.

Your LLM left out the clear hypocrisy and the part where the fixed version still had a vulnerability

His comment actually added value, but yours doesn't seem to have the same value.

Mine specifies the value that I thought was missing, though?

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.

https://github.com/XTLS/Xray-core/issues/6477#issuecomment-6...

Unfortunately, the Xray author publicly downplayed the severity of the vulnerability and used insulting language toward the vulnerability reporter.

The reaction to Xray-core is disappointing

Reply on news.ycombinator.com