-
Notifications
You must be signed in to change notification settings - Fork 82
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
what does webtunnel do for tls-in-tls, and novelty #342
Comments
i wanted to know more about this too. i was really hoping that this could have been used to make a more robust proxy to talk to my friends/family over signal but this seems like it won't work either for long. but of course, i am not very knowledgable in protocols and circumvention and hopefully it will be built upon soon |
As we tested in the last 24 hours, Webtunnel is blocked by default in most of Iran's ISPs. Years ago, v2ray/xray has been doing this since then, and they are partially blocked. Now, Tor has been updated to a method that is already blocked in Iran! (if not blocked, extremely high jitter or limited UL speed) |
You didn't need to test. It has been specifically noted that WebTunnel doesn't work in Iran. This information can be found in the Tor Project's blog:
https://blog.torproject.org/introducing-webtunnel-evading-censorship-by-hiding-in-plain-sight/ For Tor users in Iran looking for alternative methods, they can use Snowflake: https://metrics.torproject.org/userstats-bridge-combined.html?start=2023-12-15&end=2024-03-14&country=ir |
I'm under the impression that WebTunnel, or let's say HTTPT (FOCI 2020), is specifically designed to address the unique challenge of circumvention servers CAN BE actively probed by censors (Detecting Probe-resistant Proxies, NDSS 2020). In section 3 of the paper, you may see many interesting designs adopted by later implementations such as shadow-tls. So I do see the novelties in terms of implementing active probing resistance, but as you mentioned the design does not include any effort in traffic shaping, which is proved to be a major vulnerability at a later time. It might be more proper to compare HTTPT to plain designs like Shadowsocks and Trojan. Apparently it is not as complex as *Ray designs which introduced multiple factors of complexity and did a better job in the context of against real-world censors. |
Actually I am curious, do we have more information on "why" would WebTunnel not work in Iran? |
I'm not entirely sure, but I believe the websocket implementation in v2ray is older than 2020. I'm not entirely sure if the |
Well, it works. Just tested several from Zi-Tel ISP.
|
uTLS for everyone! 🥂 |
I am reading through #263 and https://www.usenix.org/system/files/foci20-paper-frolov.pdf, and come across quotes like this:
is it really though? there's a year-long precedent for tcp/ip-in-websocket-in-https, and avid readers of this forum or the xtls bugtracker are most certainly aware that countermeasures have already been deployed. Prior art is not at all mentioned or cited in the paper, and the discussion in the above linked ticket that RPRX started went nowhere. Meanwhile it's acknowledged that the just-deployed webtunnel protocol in Tor is already defeated in Iran.
I hope this isn't too harsh, but I find this baffling. I can understand that Tor is very popular and therefore a massive target for censors, and so I do not expect Tor to constantly be on the forefront of censorship circumvention. But it seems to me there is either a process, an iteration-speed or communication problem when years-old approaches are being presented as novel, and the deployment of a new kind of obfuscation protocol is dead-at-birth in Iran.
It reminds me of discussions in #136 (comment) because it seems to me that the way new things are being deployed in Tor is very much working within the academic framework, against a censor that has employed market forces long ago.
The text was updated successfully, but these errors were encountered: