Weird SNIs being requested from REALITY server in Iran, possible abuse?

[mmmray]

I have a REALITY server for Iran with dest=www.speedtest.net. In theory this is not a great dest because there are many ways to distinguish my server from the real speedtest. Many people use it anyway because it is a whitelisted (=unthrottled) SNI, and this has worked great until recently.

So I wanted to understand whether this specific dest is targeted by the GFW, so I patched xray to log all client IPs who reach the fallback dest.

Then I set up two REALITY servers with this patch:

• one REALITY server is set up normally with dest=www.speedtest.net
• one REALITY server reaches the target site through nginx, nginx uses a self-signed certificate and proxy_pass https://www.speedtest.net. So the camouflaging is really bad (bad SSL cert), but in exchange I can look at HTTP headers.

On both servers, besides the regular security scanning, I see very strange requests with SNIs that resolve to cloudflare, such as:

• <randomstring>.pages.dev
• <username>.pages.dev, where <username> is the name of a popular VPN config provider in Iran, and where I found configs from that VPN provider using the same pages.dev domain.
• other domains that resolve to cloudflare

On the server where I am able to decrypt HTTP, the user agent is always Go-http-client/1.1, and the path is either / or a randomly generated string (sometimes looks like base64, sometimes like hex, sometimes exactly like a UUID)

The client IP is always from a popular ISP in Iran, and does not seem to vary a lot.

So I wondered, is this an active probe, specifically for REALITY servers where dest is behind cloudflare?

I extended the nginx logging to also add $http_upgrade header and request/response body size, and a prefix of the request body.

I found that those requests are not just normal HTTP requests, they are fully blown vless+ws connections, going through REALITY fallback! Based on response size, I think it's only urltest, not a long-lived connection.

BTW, you can test this yourself:

1. have a websocket config for cloudflare
2. have a reality server for www.speedtest.net -- you do not need a full config, only the IP
3. in your ws config, replace the address with your REALITY IP
4. disable certificate verification
5. happy browsing!

Just so that people don't get the wrong idea: REALITY is not broken. The REALITY server behaves correctly here, if it behaved differently from www.speedtest.net it could be used for active probing as well. In fact, in the above steps you can also insert the IP of www.speedtest.net, and it will behave the same.

Why are those requests being sent? I have no idea. Here is some speculation:

• Some other VPN provider is scanning IPs, to see if there are clean IPs that can be used for his own cloudflare configs.
• or, that same VPN provider does not want to use my IPs, but just wants to get them blocked.
• There is a bug in ISP NAT
• or, ISP randomly diverts traffic between cloudflare IPs (and IPs that look like cloudflare, such as my REALITY server)
• poisoned DNS caches, no malicious intent, just software bugs
• active probing by censor. I think this is least likely, because there are simpler ways to probe REALITY with dest=www.speedtest.net.

In the end I have no idea why those requests are being sent, but regardless of intent and who sends them, there is a problem with CDN-based dest, and now we have proof it's not just a theoretical one in Iran.

Because even if those requests are friendly, they still come from Iranian ISP, meaning that the ISP can see those weak protocols, and block my REALITY IP because somebody is talking vless+ws to it. And I have zero control over which protocols are being used, which security is being used, which ALPN, and whether this actor even enabled basic things like uTLS.

What do you think?

Note:

• do not confuse www.speedtest.net with speedtest.net, they do not have the same IP and are behind different CDN.
• speedtest.net has similar issues

[us254]

@mmmray #2360

[uuonda]

What's the point of this on Cloudflare? Last time I checked Cloudflare domain fronting is extremely limited. Am I missing something here?

[mmmray]

@uuonda putting what on cloudflare? do you mean choosing a cloudflare dest, or stealing somebody else's reality server that was set up this way? there's no domain fronting going on, people use cloudflare purely to deal with IP reputation systems.

[uuonda]

Maybe machine translated text is wrong. Us254 suggested that somebody is using your Reality fallback as CDN edge server. That doesn't make sense in your case since client does not control SNI for realitySettings dest and domain fronting is not available because pages.dev is served by Cloudflare.

3andne/restls#2 (comment)

最好给Failback加一个限速，不然有可能会被别人扫去当加速用。
It is best to add a speed limit to Failback, otherwise it may be swept away by others and used for acceleration.

Not sure what that means. How would somebody use this for "for acceleration"?

[mmmray]

That doesn't make sense in your case since client does not control SNI for realitySettings dest

The client does control the SNI for dest, and can reach any SNI through fallback for regular HTTPS, for as long as the dest IP can serve that SNI. But only the SNIs configured on the xray server will succeed in auth and open the VLESS tunnel.

Not sure what that means. How would somebody use this for "for acceleration"?

I cannot speak to what network behavior the author saw, but at least in Iran, simply changing destination IP to from one cloudflare IP to another can change the connection quality. Normally throttling in Iran is based on sniffed SNI, but it generally never harms to have more IPs for your Cloudflare config at your disposal.

[uuonda]

Are you directly exposing Reality? In my setup client does not even reach Reality without whitelisted SNI which is exactly how fallback dest behaves.

But then you are masquerading as Cloudflare backed dest so you should act as CDN edge. I see what you mean. Still, as you said, it's obvious your server is not real Speedtest. So, maybe reject other SNIs anyway?

it generally never harms to have more IPs for your Cloudflare config at your disposal

Yeah but if this theory is correct somebody is scanning for poorly configured Reality backends that use Cloudflare hosts as fallback.

[mmmray]

I was told by a user on Telegram that in Iran, there is an entire economy around buying clean IPs, port-forwarding them to Cloudflare, then selling those IPs to VPN vendors who want to build Cloudflare configs but cannot find clean Cloudflare IPs.

I think it is possible that some of these "IP vendors" simply scan the internet for IPs like this, and sells them as their own, to multiple VPN vendors.

[pulsarice]

alireza0/x-ui#1213
Some domestic vps are configured to redirect user requests to foreign vps using Dokodemo-Door (with sniffing enabled) which can be exploited by others to route their own traffic to their own destination servers.
It might be some of those people scanning servers for this vulnerability.

[mmmray]

does x-ui come with an SNI proxy like this by default? not sure i understand its role in this issue