Bridge lifecycle expectations
Hi All, I have three lifecycle questions: 1) How long is typical (or what factors are involved ) before the bridge address is given out to users. 2) How do I know when the bridge is burned (identified and blocked) 3) When it is burned and I build a new one on an other address should I copy the key with the config to maintain "trust" continuity or is that neutral or bad for bridges? As a little context I've run relays before and just started up an obfs4proxy Bridge (well 10days ago). https://bridges.torproject.org/status?id=<MY_BRIDGE_ID> says it's good, logs look good but I've yet to see any real traffic, just the same 8 German node that I presume are Tor infrastructure checking status. $ cat bridge-stats bridge-stats-end 2022-03-22 18:44:43 (86400 s) bridge-ips de=8 bridge-ip-versions v4=8,v6=0 bridge-ip-transports <OR>=8,obfs4=8 every day is the same (other than bridge-stats-end) Thanks, A. Pleb
Quoting Just a Pleb (2022-03-23 02:43:54)
1) How long is typical (or what factors are involved ) before the bridge address is given out to users.
It should take less than 3 hours to start being taken into account by rdsys/bridgedb. But unless you configure a specific distributor you will be assigned randomly to one and depending on the distributor it might have different ways to distribute bridges or it might get into the 'reserve' which means is a bridge reserved and not distributed (yet).
2) How do I know when the bridge is burned (identified and blocked)
Usually a 'burnded' bridge is a per country situation, I mean your bridge might be burned in Russia but be still working in Iran. You can monitor how many connections you get from each country (by looking at stats/bridgestats) and if you were getting many connections from a certain country and they drop to 0 that means your bridge is burned in that country.
No, is better to set up a new bridge. An attacker that knows the bridge fingerprint can get access to the rest of the bridge information. I will recommend setting up a fresh new bridge if you consider yours burned.
As a little context I've run relays before and just started up an obfs4proxy Bridge (well 10days ago).
BTW, is not recommended to run exit relays and bridges by the same organization, as the family parameter doesn't exist for bridges.
https://bridges.torproject.org/status?id=<MY_BRIDGE_ID>
says it's good, logs look good but I've yet to see any real traffic, just the same 8 German node that I presume are Tor infrastructure checking status.
What distributor the metrics website say your bridge is in? https://metrics.torproject.org/rs.html#search/<fingerprint> Your bridge might be assigned to a distributor that is not in use yet (like settings or telegram), but will be very useful in the coming weeks. BTW, ip counting is rounded to 8, so seeing 8 might mean you have a single client connecting to it or up to 8. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.
Quoting flux via tor-relays (2022-03-23 22:52:29)
You are right, this is not well documented neither there is a clear protocol for it. You could look manually this file once in a while and see how it evolves, or set up a monitoring software to watch it and alert you on a drop. -- meskio | https://meskio.net/ -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- My contact info: https://meskio.net/crypto.txt -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Nos vamos a Croatan.
participants (3)
-
flux -
Just a Pleb -
meskio