Xray-core concealed a certificate verification bypass vulnerability

85 points by timbill a day ago on hackernews | 14 comments

The reaction to Xray-core is disappointing

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

LoganDark | 17 hours ago

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

ddtaylor | 12 hours ago

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

: LoganDark | 10 hours ago
Mine specifies the value that I thought was missing, though?

usernomdeguerre | 18 hours 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.

ranger_danger | 17 hours 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.

amritananda | 17 hours 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 | 17 hours ago

What if ESNI/ECH is being used?

amritananda | 16 hours 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 | 2 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 | 46 minutes 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).

wartywhoa23 | 15 hours 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.

soltanov | 17 hours 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.