Overview of issues with bridges in 1.1.0
Merge request reports
Activity
assigned to @nickm
requested review from @Diziet
mentioned in issue #543 (closed)
doc/BridgeIssues.md 0 → 100644187 we'll need to reconsider our required guard parallelism, our recommended 188 guard parallelism, our willingness to retry a guard that seems not to be 189 working, our timeouts, our happy-eyeballs parameters, and more. 190 191 192 ### Problem 6: Existing bridge-line format 193 194 We would like to have backward compatibility with Tor's current bridge 195 configuration mechanism, which uses a line format something like this: 196 197 ``` 198 bridge TransportId 1.2.3.4:9100 RsaIdentity Param1=Val1 Param2=Val2 ... 199 ``` 200 201 We'd also like to avoid making this mandatory forever, since it's crufty 202 and out of keeping with the way we configure everything else. - Comment on lines +201 to +202
I'm new here, but: I got the impression that bridgelines were a thing that users would c&p about, share in a cargo cult kind of way, get distributed via back channels etc.
If so I think Arti will want to support bridgelines (or something like them) indefinitely? And we probably want to provide APIs that make it easy to write a program that accepts bridgelines and awkward to make one that doesn't.
In the toplevel config we're probably going to want to accept
| something.bridges = ``` | bridge TransportId 1.2.3.4:9100 RsaIdentity Param1=Val1 Param2=Val2 ... | ``` 
I agree bridgelines are the main way of sharing bridges right now, and is the expected way users will use to configure bridges in arti.
We are working on bridge URIs, but are still on discussion. And we are not planning to deprecate bridgelines yet.
BTW, a bridgeline usually doesn't contain the 'bridge' word in it. The way bridges.tpo and other distributors provides them:
TransportId 1.2.3.4:9100 RsaIdentity Param1=Val1 Param2=Val2 ...Some places do mention bridgelines starting with the word Bridge (with capital B), as this is the torrc keyword you need to add at the beginning to be recognized. Tor Browser does accept bridge lines both with and without the word Bridge on it.
changed this line in version 2 of the diff
doc/BridgeIssues.md 0 → 1006441 # Adding Bridges and Pluggable Transports to Arti 2 3 This document will go over the general issues that we face when building 4 client-side support for bridges and pluggable transports in Arti. 5 6 7 ## Tor's anticensorship features: a lower-level perspective 8 9 Here's what I think you need to know about bridges. changed this line in version 2 of the diff
- doc/BridgeIssues.md 0 → 100644
96 addresses and transports, we may need to treat them as different 97 bridges.[^3] We may need to assign configured bridges a local unique ID, 98 and use that identify which bridge is which in ChanMgr. We may need a 99 flexible matching approach in our `GuardMgr` code to see which 100 remembered guard is equivalent to which configured bridge. 101 102 We'll need to download and cache bridge's router descriptors as needed. 103 This is different from downloading regular directory information in 104 several ways: 105 * We can only download a bridge's descriptor _from that bridge_. 106 * We need to be able to download a bridge's descriptor _even when we 107 have no directory_. 108 * When using bridges, we _only use bridges_ as our directory caches: 109 never fallback directories. 110 111 I suggest that we put all of the client-side bridge and pluggable changed this line in version 2 of the diff
- doc/BridgeIssues.md 0 → 100644
154 155 When a user turns bridges on and off, or changes the set of configured 156 bridges, we can easily have the `ChanMgr` and the `CircMgr` drop all of 157 their existing channels and circuits. That will cause these channels 158 and circuits to close once there are no longer any streams using them, 159 which is all well and good. 160 161 But the user may want channels and circuits to close sooner! People 162 sometimes get worried when an they flip a "anticensorship" switch and 163 their non-resistant channels and circuits don't close immediately. 164 165 That's a challenge in our current `ChanMgr`/`CircMgr` API, since we 166 don't actually keep track of the channels and circuits that we no longer 167 track in those managers. We might instead need to keep weak references 168 to deprecated channels and circuits. But doing _that_ might require new 169 `WeakChannel` and `WeakCircuit` types in `tor-proto`. - doc/BridgeIssues.md 0 → 100644
15 A "Bridge" can either be reached by the regular Tor (cells over TLS) 16 protocol, or by some different censorship-resistant "**transport**" 17 protocol.[^2] 18 19 Users configure a single bridge by listing some of the following: 20 * A set of supported transports that can be used. If this set is 21 empty, the client just uses the default transport. 22 * A set of IP:Port addresses that can be used to reach the bridge. 23 (With some transports, the transport itself figures out how to 24 contact the bridge, and this set is empty or ignored.) 25 * A set of identities to expect for the bridge. (Note that C Tor 26 allows this set to be empty; Arti will not, since it tends to 27 create severe implementation headaches.) 28 * For each transport, a set of transport-specific parameters. (These 29 might, for example, be additional protocol-specific authentication 30 keys.) -
Not sure if that matters, but from the user perspective a bridge is the combination of one transport with one IP:port, one identity and its parameters. The two bridges might share the same identity and/or ip:port, but for the user those are two different bridges.
But maybe here we care more about about how it will be implemented internally and the user input is not so important.
-
Personally, I'm fine with merging this as-is; alternatively, maybe @nickm, you want to try to fold in some of the observations from the discussion.
Anyway, given this is mostly an intro doc I don't think we need to stand on ceremony. I'm happy to do further updates in-tree. So I've hit "approve".
enabled an automatic merge when the pipeline for 8f714993 succeeds
mentioned in commit 35c2a5dc