Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2024-03-05T15:17:58Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/11101Bridges should report implementation versions of their pluggable transports2024-03-05T15:17:58ZRoger DingledineBridges should report implementation versions of their pluggable transportsOur bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge ...Our bridges now run a variety of pluggable transports. What if there's a bug in, say, the Scramblesuit implementation (like it appears there is)? If we fix the bug, how do bridgedb or the Tor clients know whether the Scramblesuit bridge they just learned about is one of the new (updated) ones or one of the old (buggy) ones?
One option would be for Tor to include a version for each supported PT in its bridge (or extrainfo) descriptor, so if we turn out to not want to use certain versions for certain situations, we can do it.
Are there better options than this one?Tor: 0.4.9.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40578Let bridge users choose to only reach their first working bridge2024-02-28T17:55:43ZRoger DingledineLet bridge users choose to only reach their first working bridgeWe have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is...We have some users in Russia who collect dozens or hundreds of obfs4 bridges, and when they start their Tor, it bursts out dozens/hundreds of connections at once to try to reach every single bridge and see which ones are working. That is loud, wasteful, and maybe even dangerous.
In Snowflake (https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651) we are heading toward a world where Tor Browser users have k snowflake bridge lines, one per destination bridge, in order to scale up and improve resiliency. But the Snowflake people worry that doing more than one-ish Snowflake connection will be wasteful (since each connection involves a domain front, a stun connection, a webrtc handshake, etc) and also it will stand out on the network. So they are considering having Tor Browser choose just one Snowflake line at random for each user, which helps with the scaling but it discards all the resiliency features that we would be so close to getting.
I think the answer in both these cases is that we want an option in Tor that makes you only try to fetch bridge descriptors from the bridges you actually hope to use.
I expect the main two parts of this change will be:
* When considering launching a bridge descriptor fetch, decide if you would call this bridge one of your primary guards if it worked, and if not, don't fetch.
* As soon as any bridge fails, immediately go through and see if you need to launch any new descriptor fetches (because otherwise you could end up in a situation where your existing bridges failed and you aren't trying any new ones yet).
(I do think we want to retain the existing "try them all" behavior as an option too (maybe even the default? that's a decision we should make), first for the people who use bridges for connectivity because it gives you the best connectivity, and second because we use the "try them all" functionality in e.g. bridgestrap.)Roger DingledineRoger Dingledine