[tor-relays] Question regarding bandwidth ratio on bridges.torproject.org and a few further, small, (probably related) questions

[telekobold]

Hello together,

I'm operating two Tor bridges. When calling bridges.torproject.org, for 
one of the bridges (set up in March, 2023), there are three outputs:

- obfs4: functional
- a bandwidth ratio
- a "last tested" entry.
But for my second bridge (set up at the beginning of June 2023), 
bridges.torproject.org does not output a bandwidth ratio.


What does this missing bandwidth ratio output mean, since everything 
else seems to be normal? When starting nyx on the relays, I see 
connections there (even more on the bridge with the missing bandwidth 
ratio output), I can connect to both bridges using the Bridge's IP 
addresses and ORPorts via Tor browser, and metrics.torproject.org also 
outputs an advertised bandwidth, which is even much higher (4.87 MiB/s 
at the moment) than for my other bridge (1.43MiB/s at the momemt) for 
which bridges.torproject.org outputs a bandwidth ratio.


The bridges run on virtual servers at the same hoster, but in two 
different countries. Nothing else runs on these virtual servers.


I am honestly not quite sure to what extent the fingerprint of the 
bridge is information worth protecting, or whether only the port and IP 
address need to be protected.


By the way, I also don't understand why my two bridges don't have a 
higher advertised bandwidth - currently, it's 4.87MiB/s for one and 
1.43MiB/s for the other relay. I never got the fast flag for either 
bridge yet, in contrast to my two "normal" relays. On both servers, at 
least 1.6GiB/s is available, and a monthly data throughput of several 
terabytes.


As a further issue, nyx doesn't output (in constrast to my two other 
relays) - not sure if this is a known issue.


And, as a last issue, I didn't specify a distribution mechanism for my 
bridge, in the hope that the most suitable mechanism will be selected 
automatically. Initially, for one of my bridges (the one for which 
bridges.torproject.org outputs a bandwidth ratio) the bridge was 
assigned distribution mechanism "Moat". But suddenly, "None" is 
displayed under distribution mechanisms at metrics.torproject.org, which 
means that apparently the bridge is no longer distributed. What could be 
the reason that the distribution mechanism suddenly changed?


Kind regards
telekobold
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Security implications of disabling onion key rotation?

[Roger Dingledine]

On Wed, Jun 28, 2023 at 02:09:34AM -0600, David Fifield wrote:
> Thanks, that was a subtlety I had missed. Since we are writing about
> bridges, I mostly want to give the bridge perspective. We had formerly
> written this:
>   A relay's current onion keys appear in the Tor network
>   consensus; when clients make circuits through it, they expect it
>   to use certain onion keys.
> We've now changed it to:
>   Tor clients cache a bridge's onion public keys when they
>   connect; subsequent connections only work if the cached keys are
>   among the bridge's two most recently used sets of onion keys.

Makes sense.

> So it sounds like compromise of an onion key is no worse than compromise
> of an identity key, because with an identity key an attacker could cook
> up and sign a new onion key. The exception is that if an attacker
> somehow got an identity key but not current onion keys, and it's a
> bridge that's affected rather than a relay, then the attacker would not
> be able to fool clients that had previously connected and cached the
> past genuine onion keys.

Right. But that window where the cached version protects you is quite
narrow -- it looks like modern clients fetch a new bridge descriptor
every TestingBridgeDownloadInitialDelay (3 hours) (see where we set
next_attempt_at in learned_bridge_descriptor()), and not too long ago
we fetched a fresh bridge descriptor hourly.

The reasoning for the frequent fetches is that fetching the bridge's
descriptor over a one-hop circuit is a low cost operation, and it doubles
as a crude liveness check (since if it succeeds, the bridge should work
for real circuits too, and if it fails, we should mark the bridge as
not working currently).

When Tor starts up with a cached bridge descriptor with a timestamp we like,
I imagine it is not long until we attempt to fetch a fresh descriptor. I
haven't checked our current behavior though. But I would not rely on
this onion key caching for security.

Hope this helps!
--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays