Call for WebTunnel bridges

[wkrp]

https://forum.torproject.org/t/8180

We're excited to announce WebTunnel, a new bridge pluggable transport (PT) for the Tor ecosystem. It is a censor resistant proxy that try to imitate HTTPS traffic, based on HTTPT research. We are currently operating a trial soft launch for WebTunnel, and encourage bridge operators to set up WebTunnel bridges to discover issues within the implementation of this new pluggable transport.

How it works

When connecting to a WebTunnel Bridge, the client send a http 1.1 upgrade request to the load balancer over an encrypted connection, like how WebSocket works. Thus, from an observator’s point of view, this process looks like a real websocket connection to the real website. If one ever try to connect to the fronting website, then what will be presented will be that fronting website. Without the full URL including the path, which the censor don’t know, it is very difficult to tell if a website hosts a WebTunnel by probing the HTTPS port.

Technical requirements

To set up a WebTunnel Bridge, you will need a self-hosted website, a domain under your control,a configurable load balancer, static IPv4, and environment to setup Tor Bridge to setup a WebTunnel Bridge. Docker or other container runtime is recommended to streamline setup process, but is not required.

The setup guide is available here: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/webtunnel#docker-setup

WebTunnel support is already included in current Tor Browser alpha releases, but the only way to use it at this point is by manually pasting in a bridge line from https://bridges.torproject.org/.

[RPRX]

根据我们的实践，“looks like a real websocket”正是问题。WSS 常被用来翻墙，故已被中国 GFW 针对，WSS 被封的报告持续不断。

建议改用 streaming request，比如，一条子连接负责上传数据，另一条子连接负责下载数据。它不仅支持 h2，还支持 h3。

According to our experience, "looks like a real websocket" is a problem. WSS is often used to jump the wall, so it has been targeted by China GFW, and the reports of WSS have continued.

It is recommended to use streaming request. For example, one sub-connection is responsible for uploading data, and the other is responsible for downloading data. It supports not only h2, but also h3.

[computerscot]

@RPRX When you say "streaming request," would gRPC or h2 be recommended methods?

[RPRX]

@RPRX When you say "streaming request," would gRPC or h2 be recommended methods?

我的意思是对 Tor 来说，一个 HTTP 请求加另一个 HTTP 响应拼成全双工，就不必用 WSS 了，这样能解决 ALPN 问题，还能走 H3

Xray-core 的话，早已 deprecated WSS，推荐换用 gRPC：https://github.com/XTLS/Xray-core/issues/1750#issuecomment-1459340564 、https://github.com/XTLS/Xray-core/issues/1750#issuecomment-1459469821

---

What I mean is that for Tor, one HTTP request plus another HTTP response is spliced into full duplex, so you don't have to use WSS, which solves the ALPN problem, and you can still use H3.

Xray-core has long since deprecated WSS, so I recommend switching to gRPC: https://github.com/XTLS/Xray-core/issues/1750#issuecomment-1459340564, https://github.com/XTLS/Xray-core/issues/1750#issuecomment-1459469821

[RPRX]

More info about WSS in China: https://github.com/XTLS/Xray-core/issues/2175#issuecomment-1575632179, https://github.com/XTLS/Xray-core/issues/2175#issuecomment-1611696893