I created a terraform/ansible setup that deploys a collection virtual machines running a tor bridge. Using a small offset script I can easily remove the oldest virtual machine and replace it with a new one, using a new public IP.
Right now I run 10 bridges, where I could periodically replace a single host, thus replacing the public IP addresses over time (but not all at once for stability).
Is this at all useful for tor bridges? I’m not sure how people learn about these bridges.
I’d also like to know this. I have access to a huge pool of dynamic IPs through my ISP and could write a script to get a new dynamic IP everytime ping requests to certain Chinese IP addresses fail (probably checking once every 4 hours).
I imagine that in order to do this, I would have to set my BridgeDistribution method to moat or another method where getting obfs4 bridges are low-barrier/often refreshed.
I’ve heard that this is actually a negative thing, because getting bridges through a distribution method such as via email can be rather labour-intensive, and you don’t want those bridges to go dead.
Would be curious if the pros of adding bridges that are not blocked in China/Russia outweigh the cons of staling the overall distributed bridge pool.
Iain (@irl) is working in a similar concept with Terraform:
Is this at all useful for tor bridges? I’m not sure how people learn about these bridges.
It is and we have been calling it “dynamic bridges”.
As censors are bypassing the bridge distributions anti-enumeration methods that we have (Captcha, email verification), rotating the bridge IP address is one way to have working bridges in Russia and China.
I have opened this ticket to find out how we can help relay operators to test their bridges:
Hey Nolo, the problem here is when your IP address is rotating too often, like more than once in a week. For the “dynamic bridges”, you should rotate only when the bridge gets blocked.
Thanks. So in my particular use case, rotating IP addresses only when my bridge is blocked in China/Russia, would this be beneficial for the Tor network?
What Bridge distribution method would have the fastest uptake for a Bridge in China/Russia? I’m guessing moat because it’s low barrier and constantly refreshed? Or should I choose email/Telegram distribution because that’s the most accessible way to distribute bridges in those countries?
This is cool to see. My approach to this was purely Terraform, no Ansible, and I treat the bridges as very disposable.
My bridges have only rudimentary monitoring, like “is it working?” (checked with bridgestrap) and “am i going over any bandwidth limit?” (checked with the provider API). I also haven’t configured anything fancy with the firewall or anything else, the hosts are very much embracing the defaults of a bare Debian installation. This approach is partly about blending in, and partly about being lazy.
I notice you’re setting the reverse DNS of the hosts. obfs4 makes an effort to hide, and you can only really know it’s an obfs4 bridge by also knowing the certificate it uses, but in this case the reverse DNS will give it away. Sticking to the generic Hetzner reverse DNS will help the bridges last longer.
To handle replacement, I’m tracking bridges in an SQL database, and regular background tasks check for signs of blocks. One source that I’ve not yet configured is the new blocklist= parameter that rdsys now provides. You could write a Python script to fetch the latest bridge-pool-assignments document, and then rotate your bridges when you see that your bridge is blocked. I think right now that measurements are only done in Russia, but that later this will be a comma-seperated country list. @hiro would know more. Note: this will have the “hashed fingerprint” of the bridge, and you’ll find those in /var/lib/tor/hashed_fingerprint.
