New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REALITY servers in Iran being abused as sort-of SNI proxies #359
Comments
YouTube 上有一些中文教程教你寻找 REALITY dest 指向了 Cloudflare 的服务器 IP 并使用它们提升自己 WS proxies 的速度 There are some Chinese tutorials on YouTube that teach you to look for REALITY dest server IPs that point to Cloudflare and use them to speed up your WS proxies.
有这种可能,不过根据我们收到的消息,现在在伊朗很多正常的网站也会被封,就是说现在已经在乱封了? It's possible, but according to the information we've received, a lot of normal websites are now blocked in Iran as well, meaning it's already being blocked indiscriminately now? |
Well, I don't really have any answers, so here's some rambling instead.
there are similar tutorials in persian, and an entire economy around building, scanning and selling port-forwarders (see details in xray discussions thread, i can repost here if this is desired for archival) Now, a tangent around intent. I was initially convinced that REALITY is not being specifically targeted, and rather that it is detected as "port forwarder" or SNI proxy by some scanner. But now I wonder, why was I able to MITM the SSL with the most basic self-signed certificate? If one scans for port-forwarders and already pulls in a proper HTTPS client, isn't it more effort to write code to disable certificate verification, or are "they" looking for any kind of reverse proxy that works at all? But then, why do they expect to find a decent amount of http reverse proxies pointing to a CDN? And if their intent is on finding port forwarders, is there a point in sending full vless+ws connections and leak credentials just for probing? I feel that a basic HTTP request would be more efficient to build a scanner around (wouldn't you get way more information with
I don't understand, sorry
About possible collateral damage... From what I can tell, the vless+ws+cdn proxies people build in Iran basically make no attempt at camouflaging, and it feels to me that they in fact make an active effort at standing out. SNIs contain the name of the VPN vendor, and they attempt to exploit case-sensitivity bugs in GFW around SNI (for example I see those kinds of SNIs both in public "daily config" telegram channels, in the more private technical groups, and in the SNIs I captured on my own server. It's a reason I struggle with analyzing the GFW because some of it and how people bypass it cannot be reasoned about from first principles. Anyway. For this reason I do not think that the blocking of legitimate websites is related. If you have any suggestions for experiments I should do, I'm open to them (can also email me if you want, see bio). My brain is a bit too fried right now to systematically find answers and eliminate possibilities. And from what I've heard in Telegram it seems that the MCI GFW is also able to find steal-yourself setups that do not attempt to pass any "SNI whitelist", so even if we can reach a conclusion for this discussion, it cannot comprehensively explain how/why REALITY gets blocked in Iran. |
Since i see some chatter about SNI proxies here, I'm crossposting this thread from Xray-core forum: XTLS/Xray-core#3318
The TL;DR is that a REALITY server I set up for Iran with
dest=www.speedtest.net
got used really quickly as a proxy for talking to other cloudflare pages. When intercepting the SSL stream, it was observed that those other cloudflare pages (and workers) are serving vless+ws tunnels.I was able to trace back some of the used domain names to popular VPN vendors in Iran.
I was also able to extract VLESS passwords (UUIDs) from the decrypted HTTP traffic, and found them again in large vless "proxy lists" on github. I didn't try connecting yet.
There's a lot of speculation but no clear answers on who is doing this or why, but if anybody has a clue what's going on, that would help. Either way I am convinced that this tunneling of (poorly camouflaged) vless+ws connections over REALITY IPs contributes to those servers getting blocked, either as part of a deliberate active probing attack, or as a second-hand effect of the censor detecting those websocket connections and blocking the server because of them.
The text was updated successfully, but these errors were encountered: