Russian VPS as proxy for webbridge, bad idea?

[DerangedSquid]

Hi,

I am currently running multiple relays, including webbridges, on european VPS. I was wondering if using a russian VPS as a proxy for a webbridge would have sufficient advantages?

My idea is to use a russian VPS and a european VPS, connect them via wireguard. The webbridge itself and Tor would be running on the european VPS. The russian VPS would only be used to tunnel all traffic, that way the TLS-termination and Tor related stuff would happen on the european VPS. Via iptables or UFW all traffic via wireguard but the proxied traffic would be blocked.

My hope is that using a russian VPS would make the webbridge less suspicious. But I don’t know if that would actually work. Has anybody experience with this?

I am aware of multiple downsides, yet I don’t know if they outweight the advantage (if there is one).

I know that this would cause additional delay since it basically adds one more hop. Yet most relays are located in europa and US. Therefore the additional delay might not be critical.

Additionally this would increase the attack surface on the relay simply because more services are running (wireguard tunnel, nginx proxy). Yet nginx would be used for the webbridge anyway, so the additional surface is not huge.

I see more potential that the russian regime would try to silently take over the vps to manipulate it. Since TLS-termination and all Tor related stuff is done on another machine, the possibilities might be limited (given I am able to secure the european VPS accordingly).

Do I miss something? Has anybody tried this (I can’t be the first one to think of this) and can give an insight if this is helpful or not?

[shdwcodr]

Hey, I’m still pretty new myself, but from what I’ve learned this setup probably isn’t worth it. Using a Russian VPS just as a tunnel adds more risk and complexity, and those hosts can be pressured or monitored pretty easily. Since all the Tor/TLS stuff stays on your EU VPS, the Russian box doesn’t give you much real benefit besides a different IP, and that IP might actually look more suspicious depending on the situation.

Extra latency, bigger attack surface, and more things that can break. Most people seem to recommend keeping bridges simple and in a place you trust.

Just sharing what I’ve picked up while learning — hope it helps!

~shdwcodr

[unic3rn]

@DerangedSquid

My hope is that using a russian VPS would make the webbridge less suspicious.

Well, technically IMHO it would do the opposite… (also, on some ISPs in Russia WireGuard is blocked)

Currently, it’s as if the Russian censor is manually collecting the WebTunnel domain addresses and blocking them using their SNI (server name identification aka domain) blocking technology. I haven’t witnessed a WebTunnel bridge being blocked by IP. (always been able to bypass any WebTunnel bridge block via different anti-censorship methods like bypassing SNI blocking, you can technically do it without the bridge operator configuring his setup, but it’s much harder for users to configure than the reliable sni-imitation feature)

In the latest version of lyrebird (basically the Tor anti-censorship package containing obfs4, webtunnel, meek and snowflake clients that are used in the Tor Browser and elsewhere), a new feature was added that lets users (clients) set the SNI for a WebTunnel connection. So suppose you have bridge X on IP address 1.1.1.1 with the domain: example.com, now if the censor blocked your ‘example.com’ by SNI, then your bridge IP address should still be accessible (when it’s an SNI block). So on your server setup you allow any SNI connection to connect to your ‘website’, not only requests with the SNI example.com

Here is an example of how you can set it like that in nginx:

In catch-all server examples the strange name “_” can be seen:

server {
    listen       80  default_server;
    server_name  _;
    return       444;
}

So if you have a catch-all server name set up for a WebTunnel bridge, a user in the next Tor Browser version will be able to add a sni-imitation=whateversniyouwantaslongasits.whitelisted line to their bridge address. But that feature would only work if the bridge operator has a catch-all servername setup. That’s the best way to bypass SNI blocks, but other methods bypass it not even by directly changing the SNI (like playing tricks with the censorship firewall), the latter is not a stable method and requires users to download additional anti-censorship tools, the sni-imitation is built into the Tor Browser. (it will be included in the next TB release)

There’s a thing that I wonder if works: can a bridge operator manually set a custom sni-imitation line so that when it was distributed the line would already be included and the user won’t have to configure anything additionally? (i.e.

webtunnel … … … … … sni-imitation=ya.ru

Like maybe you can set this line in torrc or something? If anyone knows anything about this specific thing, please chime in!

So that kind of setup would allow you to host a WebTunnel bridge on a ‘foreign’ server and it can’t be blocked by SNI if you use SNI’s that can’t be blocked. (i.e. ya.ru, vk.ru, vk.com, vkvideo.ru, any major Russian site) I think that’s a better setup than specifically configuring a server in Russia for bridge purposes.

As long as

1. The user configures the sni-imitation feature (or, of possible, it would be distributed along with the bridge line)
2. The censor is not blocking the WebTunnel bridge by IP

this method should work well.

[DerangedSquid]

Thank you to both of you for your valuable insights!

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).

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).

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?

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. As far as I know, I can add anything sni-limitation-specific to the torrc yet.

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. The problem here seems to be that I can only set one URL in torrc, therefore I would to run multiple tor-processes each with it’s own torrc.