1 Filename: 125-bridges.txt
2 Title: Behavior for bridge users, bridge relays, and bridge authorities
3 Author: Roger Dingledine
6 Implemented-In: 0.2.0.x
10 This document describes the design decisions around support for bridge
11 users, bridge relays, and bridge authorities. It acts as an overview
12 of the bridge design and deployment for developers, and it also tries
13 to point out limitations in the current design and implementation.
15 For more details on what all of these mean, look at blocking.tex in
20 Bridge relays are just like normal Tor relays except they don't publish
21 their server descriptors to the main directory authorities.
23 1.1. PublishServerDescriptor
25 To configure your relay to be a bridge relay, just add
27 PublishServerDescriptor bridge
28 to your torrc. This will cause your relay to publish its descriptor
29 to the bridge authorities rather than to the default authorities.
31 Alternatively, you can say
33 PublishServerDescriptor 0
34 which will cause your relay to not publish anywhere. This could be
35 useful for private bridges.
39 Bridge relays should use an exit policy of "reject *:*". This is
40 because they only need to relay traffic between the bridge users
41 and the rest of the Tor network, so there's no need to let people
42 exit directly from them.
44 1.3. RelayBandwidthRate / RelayBandwidthBurst
46 We invented the RelayBandwidth* options for this situation: Tor clients
47 who want to allow relaying too. See proposal 111 for details. Relay
48 operators should feel free to rate-limit their relayed traffic.
50 1.4. Helping the user with port forwarding, NAT, etc.
52 Just as for operating normal relays, our documentation and hints for
53 how to make your ORPort reachable are inadequate for normal users.
55 We need to work harder on this step, perhaps in 0.2.2.x.
57 1.5. Vidalia integration
59 Vidalia has turned its "Relay" settings page into a tri-state
60 "Don't relay" / "Relay for the Tor network" / "Help censored users".
62 If you click the third choice, it forces your exit policy to reject *:*.
64 If all the bridges end up on port 9001, that's not so good. On the
65 other hand, putting the bridges on a low-numbered port in the Unix
66 world requires jumping through extra hoops. The current compromise is
67 that Vidalia makes the ORPort default to 443 on Windows, and 9001 on
70 At the bottom of the relay config settings window, Vidalia displays
71 the bridge identifier to the operator (see Section 3.1) so he can pass
72 it on to bridge users.
74 1.6. What if the default ORPort is already used?
76 If the user already has a webserver or some other application
77 bound to port 443, then Tor will fail to bind it and complain to the
78 user, probably in a cryptic way. Rather than just working on a better
79 error message (though we should do this), we should consider an
80 "ORPort auto" option that tells Tor to try to find something that's
81 bindable and reachable. This would also help us tolerate ISPs that
82 filter incoming connections on port 80 and port 443. But this should
83 be a different proposal, and can wait until 0.2.2.x.
85 2. Bridge authorities.
87 Bridge authorities are like normal directory authorities, except they
88 don't create their own network-status documents or votes. So if you
89 ask an authority for a network-status document or consensus, they
90 behave like a directory mirror: they give you one from one of the main
91 authorities. But if you ask the bridge authority for the descriptor
92 corresponding to a particular identity fingerprint, it will happily
93 give you the latest descriptor for that fingerprint.
95 To become a bridge authority, add these lines to your torrc:
96 AuthoritativeDirectory 1
97 BridgeAuthoritativeDir 1
99 Right now there's one bridge authority, running on the Tonga relay.
101 2.1. Exporting bridge-purpose descriptors
103 We've added a new purpose for server descriptors: the "bridge"
104 purpose. With the new router-descriptors file format that includes
105 annotations, it's easy to look through it and find the bridge-purpose
108 Currently we export the bridge descriptors from Tonga to the
109 BridgeDB server, so it can give them out according to the policies
112 2.2. Reachability/uptime testing
114 Right now the bridge authorities do active reachability testing of
115 bridges, so we know which ones to recommend for users.
117 But in the design document, we suggested that bridges should publish
118 anonymously (i.e. via Tor) to the bridge authority, so somebody watching
119 the bridge authority can't just enumerate all the bridges. But if we're
120 doing active measurement, the game is up. Perhaps we should back off on
121 this goal, or perhaps we should do our active measurement anonymously?
123 Answering this issue is scheduled for 0.2.1.x.
125 2.3. Migrating to multiple bridge authorities
127 Having only one bridge authority is both a trust bottleneck (if you
128 break into one place you learn about every single bridge we've got)
129 and a robustness bottleneck (when it's down, bridge users become sad).
131 Right now if we put up a second bridge authority, all the bridges would
132 publish to it, and (assuming the code works) bridge users would query
133 a random bridge authority. This resolves the robustness bottleneck,
134 but makes the trust bottleneck even worse.
136 In 0.2.2.x and later we should think about better ways to have multiple
141 Bridge users are like ordinary Tor users except they use encrypted
142 directory connections by default, and they use bridge relays as both
143 entry guards (their first hop) and directory guards (the source of
144 all their directory information).
146 To become a bridge user, add the following line to your torrc:
150 and then add at least one "Bridge" line to your torrc based on the
153 3.1. Format of the bridge identifier.
155 The canonical format for a bridge identifier contains an IP address,
156 an ORPort, and an identity fingerprint:
157 bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
159 However, the identity fingerprint can be left out, in which case the
160 bridge user will connect to that relay and use it as a bridge regardless
161 of what identity key it presents:
162 bridge 128.31.0.34:9009
163 This might be useful for cases where only short bridge identifiers
164 can be communicated to bridge users.
166 In a future version we may also support bridge identifiers that are
167 only a key fingerprint:
168 bridge 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
169 and the bridge user can fetch the latest descriptor from the bridge
170 authority (see Section 3.4).
172 3.2. Bridges as entry guards
174 For now, bridge users add their bridge relays to their list of "entry
175 guards" (see path-spec.txt for background on entry guards). They are
176 managed by the entry guard algorithms exactly as if they were a normal
177 entry guard -- their keys and timing get cached in the "state" file,
178 etc. This means that when the Tor user starts up with "UseBridges"
179 disabled, he will skip past the bridge entries since they won't be
180 listed as up and usable in his networkstatus consensus. But to be clear,
181 the "entry_guards" list doesn't currently distinguish guards by purpose.
183 Internally, each bridge user keeps a smartlist of "bridge_info_t"
184 that reflects the "bridge" lines from his torrc along with a download
185 schedule (see Section 3.5 below). When he starts Tor, he attempts
186 to fetch a descriptor for each configured bridge (see Section 3.4
187 below). When he succeeds at getting a descriptor for one of the bridges
188 in his list, he adds it directly to the entry guard list using the
189 normal add_an_entry_guard() interface. Once a bridge descriptor has
190 been added, should_delay_dir_fetches() will stop delaying further
191 directory fetches, and the user begins to bootstrap his directory
192 information from that bridge (see Section 3.3).
194 Currently bridge users cache their bridge descriptors to the
195 "cached-descriptors" file (annotated with purpose "bridge"), but
196 they don't make any attempt to reuse descriptors they find in this
197 file. The theory is that either the bridge is available now, in which
198 case you can get a fresh descriptor, or it's not, in which case an
199 old descriptor won't do you much good.
201 We could disable writing out the bridge lines to the state file, if
202 we think this is a problem.
204 As an exception, if we get an application request when we have one
205 or more bridge descriptors but we believe none of them are running,
206 we mark them all as running again. This is similar to the exception
207 already in place to help long-idle Tor clients realize they should
208 fetch fresh directory information rather than just refuse requests.
210 3.3. Bridges as directory guards
212 In addition to using bridges as the first hop in their circuits, bridge
213 users also use them to fetch directory updates. Other than initial
214 bootstrapping to find a working bridge descriptor (see Section 3.4
215 below), all further non-anonymized directory fetches will be redirected
218 This means that bridge relays need to have cached answers for all
219 questions the bridge user might ask. This makes the upgrade path
220 tricky --- for example, if we migrate to a v4 directory design, the
221 bridge user would need to keep using v3 so long as his bridge relays
222 only knew how to answer v3 queries.
224 In a future design, for cases where the user has enough information
225 to build circuits yet the chosen bridge doesn't know how to answer a
226 given query, we might teach bridge users to make an anonymized request
227 to a more suitable directory server.
229 3.4. How bridge users get their bridge descriptor
231 Bridge users can fetch bridge descriptors in two ways: by going directly
232 to the bridge and asking for "/tor/server/authority", or by going to
233 the bridge authority and asking for "/tor/server/fp/ID". By default,
234 they will only try the direct queries. If the user sets
235 UpdateBridgesFromAuthority 1
236 in his config file, then he will try querying the bridge authority
237 first for bridges where he knows a digest (if he only knows an IP
238 address and ORPort, then his only option is a direct query).
240 If the user has at least one working bridge, then he will do further
241 queries to the bridge authority through a full three-hop Tor circuit.
242 But when bootstrapping, he will make a direct begin_dir-style connection
243 to the bridge authority.
245 As of Tor 0.2.0.10-alpha, if the user attempts to fetch a descriptor
246 from the bridge authority and it returns a 404 not found, the user
247 will automatically fall back to trying a direct query. Therefore it is
248 recommended that bridge users always set UpdateBridgesFromAuthority,
249 since at worst it will delay their fetches a little bit and notify
250 the bridge authority of the identity fingerprint (but not location)
251 of their intended bridges.
253 3.5. Bridge descriptor retry schedule
255 Bridge users try to fetch a descriptor for each bridge (using the
256 steps in Section 3.4 above) on startup. Whenever they receive a
257 bridge descriptor, they reschedule a new descriptor download for 1
260 If on the other hand it fails, they try again after 15 minutes for the
261 first attempt, after 15 minutes for the second attempt, and after 60
262 minutes for subsequent attempts.
264 In 0.2.2.x we should come up with some smarter retry schedules.
266 3.6. Vidalia integration
268 Vidalia 0.0.16 has a checkbox in its Network config window called
269 "My ISP blocks connections to the Tor network." Users who click that
270 box change their configuration to:
272 UpdateBridgesFromAuthority 1
273 and should specify at least one Bridge identifier.
275 3.7. Do we need a second layer of entry guards?
277 If the bridge user uses the bridge as its entry guard, then the
278 triangulation attacks from Lasse and Paul's Oakland paper work to
279 locate the user's bridge(s).
281 Worse, this is another way to enumerate bridges: if the bridge users
282 keep rotating through second hops, then if you run a few fast servers
283 (and avoid getting considered an Exit or a Guard) you'll quickly get
284 a list of the bridges in active use.
286 That's probably the strongest reason why bridge users will need to
287 pick second-layer guards. Would this mean bridge users should switch
288 to four-hop circuits?
290 We should figure this out in the 0.2.1.x timeframe.