How to set up a new censorship-circumvention improvement on the server side for WebTunnel bridges

[unic3rn]

@DerangedSquid, your topic closed, so I couldn’t reply to you here. The discussion before can also be viewed here.

@DerangedSquid

To be honest I am not sure if I get the sni-limitation-feature correctly, maybe you, @unic3rn can point me to additional documentation (I tried to find additional info, but was not successfull).

Well, unfortunately there is no documentation yet. There are a few threads on the Tor Project code development instance of GitLab where there were discussions while the feature was being developed:

Original merge request of the feature. (doesn’t contain a lot insight for users)

A longer discussion of the feature/more development processes. (more explanation)

@DerangedSquid

As far as I understand my part as a bridge-operator would be to make sure, that my webbridge does either acceppt an SNI given (catchall, like you linked with __ in nginx) or I would make my webserver accept an additional SNI (example .com and vk . ru).

Yes, it would make a user’s connection to your bridge look like the user is legit connecting to a site with the domain of vk.ru, for example. You also can whitelist a few SNI’s like ya.ru, vk.ru, food.ru, but if you only whitelist a few more additional SNIs in addition to example.com, then you would somehow need to inform the user of the specific whitelisted SNIs, *if you can whitelist a single SNI and make it so it gets distributed with the sni-imitation=yourspecificwhitelistedsni, then the user will be able to connect using the example.com and the yourspecifiedwhitelisted.sni domain address. (I think it’s possible, maybe by finding where the bridge line is stored on your bridge server and adding a sni-imitation line there) But if you don’t host any other sites on your bridge server, then enabling the “catch-all” SNI option would be more flexible/easier for users.

@DerangedSquid

On the client side lyrebird would take care about resolving vk .ru to 1.1.1.1 (in your example) and ignoring the failed TLS-check for vk .ru. correct?

Yes, lyrebird ignores the fact that the TLS/SSL record is not assigned to vk.ru, it checks the record for the url= (original ‘example.com’ address) value and then verifies the certificate using your device’s SSL-authority database, so the connection is secure, here is how the resolving works:

webtunnel [ipv6-gibberish]:443 fingerprint url=https://example.com/whereverwebtunnelishidden

here is a generic webtunnel bridge address, it always comes with a url= argument, when sni-imitation is set, lyrebird resolves the dns record using that exact url=https://example.com line.

So, here is how an SNI-spoofed bridge line would look:

webtunnel [ipv6-gibberish]:443 fingerprint url=https://example.com/whereverwebtunnelishidden sni-imitation=ya.ru

But if you don’t want lyrebird to resolve the bridge dns, you can add the addr= argument:

webtunnel [ipv6-gibberish]:443 fingerprint url=https://example.com/whereverwebtunnelishidden sni-imitation=ya.ru addr=1.1.1.1

you can specify an ipv4 or ipv6 address.

@DerangedSquid

Regarding the sni-limitation in torrc, as an operator I don’t actually create the bridge-line. It is generated from contents from the torrc (like sni and path) and the relays fingerprint.

Well, originally yes, (and again, the url= argument is generated automatically because your original domain is example.com, sni-imitation is an extension to it) but in torrc, for example for obfs4 you can set the iat-mode= obfuscation level(found this online, also snowflake uses the same setting for setting custom arguments, which most likely means that webtunnel sees/uses these lines too!!!):

ServerTransportOptions obfs4 iat-mode=2

So, if you used the same ServerTransportOptions line with sni-imitation, it technically should distribute your bridge with the added options. This is just a line you put in torrc. Here’s an example:

ServerTransportOptions webtunnel sni-imitation=ya.ru

(optionally, you can provide the addr= cached dns option)

I guess that you can verify that the bridge line gets ‘corrected’ by checking the Tor logs?

Btw, just noticed that the official WebTunnel setup docs have this in them, which means that you have this in your torrc:

ServerTransportOptions webtunnel url=https://yourdomain/path

Just make a space after your url= argument and add the sni-imitation argument right there:

ServerTransportOptions webtunnel url=https://yourdomain/path sni-imitation=ya.ru

@DerangedSquid

Additionally: since it’s the SNI that get blocked, wouldn’t it help to have multiple SNI pointed to the same relay? Server capacity (and IPv4 adresses) are expensive, domains aren’t.

Correct, but doesn’t using sni-imitation solve the problem? You sort of make it better because now the user’s connection won’t get ‘blocked’ because the user is connecting via a whitelisted SNI.

But, you can set up a few webtunnels on a few different subdomains of a single domain, at least in Russia they don’t block the whole domain + all subdomains, I like totally don’t recommend it, I don’t see any clear benefit from it, in the slightest you might have your bridge spread/distributed out more, but, nah…

On the informative side, there’s some info here on how to create another tor instance, I don’t know if it creates multiple tor processes, or just allows you to create multiple different torrc’s

So in the end I would honestly not advise you to set up several bridges in one place for the sake of making it more accessible.

[unic3rn]

Wanted to add a few more things:

1. Also, you can add SNI rotation for sni-imitation like this(no spaces between the different SNIs):

sni-imitation=ya.ru,ok.ru,vkvideo.ru,food.ru

2. Adding the addr= argument (dns cache) might help some users with dns poisoning, if it occurs. Right now it doesn’t seem like a big problem in Russia, but letting you know just in case it’ll become a problem. (users can manually set it if they start running into issues because of dns poisoning, but you would be able to turn this feature on manually, so it would be manually distributed with the addr= option, I don’t think that it’s super necessary to set up for distribution right now.)

3. Forgot to mention, but idk if you can run/set up multiple bridges in one torrc - maybe if you try to group the ‘bridge configs’ into different blocks.

4. And finally, if you make any changes in torrc, please don’t forget to restart the service. If you edited your web config, then, accordingly restart your web server service!

[DerangedSquid]

Wow thank you so much for taking the time to explain all of this in great length and detail!

I planned to set up a new webbridge anyway and will include this in the new bridge and will roll it out to the existing ones afterwards. I guess adding the addr-field

And yes, having multiple domains point to a single server seems to be inferior to sni-limitation.

[jabdoa2]

I got a bridge with sni-imitation working. I first tried to implement this using Kubernetes Gateway API with Traefik as gateway controller. This almost worked but you cannot force Traefik to serve an SSL cert which does not match the hostname which breaks SSL for tor. To work around that I deployed an nginx container with certbot on a separate IP. Nginx always uses the SSL cert for the main domain and forwards traffic to the Webtunnel container. So far I do not yet see a lot of traffic but I guess it will take a while to get the bridge distributed.