From 449174d796930b7bcb4269c012d9251ca2140ad8 Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Sun, 3 Aug 2008 15:34:28 +0000 Subject: [PATCH] update and integrate proposals 125 (bridges) and 137 (bootstrap status) svn:r16374 --- doc/spec/address-spec.txt | 9 +- .../125-bridges.txt => bridges-spec.txt} | 142 +++---------- doc/spec/control-spec.txt | 232 +++++++++++++++++++-- doc/spec/proposals/000-index.txt | 8 +- doc/spec/proposals/125-bridges.txt | 91 ++------ doc/spec/proposals/137-bootstrap-phases.txt | 2 +- .../proposals/ideas/xxx-bridge-disbursement.txt | 2 +- 7 files changed, 268 insertions(+), 218 deletions(-) copy doc/spec/{proposals/125-bridges.txt => bridges-spec.txt} (63%) diff --git a/doc/spec/address-spec.txt b/doc/spec/address-spec.txt index 966f34c3d9..2a84d857e6 100644 --- a/doc/spec/address-spec.txt +++ b/doc/spec/address-spec.txt @@ -5,10 +5,11 @@ $Id$ 1. Overview - Most of the time, Tor treats user-specified hostnames as opaque: When the - user connects to www.torproject.org, Tor picks an exit node and uses that node to - connect to "www.torproject.org". Some hostnames, however, can be used to override - Tor's default behavior and circuit-building rules. + Most of the time, Tor treats user-specified hostnames as opaque: When + the user connects to www.torproject.org, Tor picks an exit node and uses + that node to connect to "www.torproject.org". Some hostnames, however, + can be used to override Tor's default behavior and circuit-building + rules. These hostnames can be passed to Tor as the address part of a SOCKS4a or SOCKS5 request. If the application is connected to Tor using an IP-only diff --git a/doc/spec/proposals/125-bridges.txt b/doc/spec/bridges-spec.txt similarity index 63% copy from doc/spec/proposals/125-bridges.txt copy to doc/spec/bridges-spec.txt index bc6de66083..4a9b373c8e 100644 --- a/doc/spec/proposals/125-bridges.txt +++ b/doc/spec/bridges-spec.txt @@ -1,11 +1,6 @@ -Filename: 125-bridges.txt -Title: Behavior for bridge users, bridge relays, and bridge authorities -Version: $Revision$ -Last-Modified: $Date$ -Author: Roger Dingledine -Created: 11-Nov-2007 -Status: Finished -Implemented-In: 0.2.0.x +$Id$ + + Tor bridges specification 0. Preface @@ -36,52 +31,23 @@ Implemented-In: 0.2.0.x which will cause your relay to not publish anywhere. This could be useful for private bridges. -1.2. Defining DirPort - - Bridges need to answer BEGIN_DIR requests, both so they can answer - "/server/authority" questions ("what's your descriptor?") and so they - can supply their bridge users with cached copies of all the various - Tor network information. - - As of Tor 0.2.0.13-alpha, bridges will answer begin_dir questions - (and cache dir info they see so the answers will be more useful) - whether their DirPort is enabled or not. (After all, we don't care if - they have an open or reachable DirPort to answer begin_dir questions.) - - We need to investigate if there are any anonymity worries with answering - BEGIN_DIR requests when our DirPort is off. I claim that we don't open - any new attacks: it's still a fine question to ask what partitioning - attacks there are when you can query a Tor client about its current - directory opinions, but these attacks already exist when DirPort is on. - We should investigate this in 0.2.1.x. - -1.3. Exit policy +1.2. Recommendations. Bridge relays should use an exit policy of "reject *:*". This is because they only need to relay traffic between the bridge users and the rest of the Tor network, so there's no need to let people exit directly from them. -1.4. RelayBandwidthRate / RelayBandwidthBurst - We invented the RelayBandwidth* options for this situation: Tor clients who want to allow relaying too. See proposal 111 for details. Relay operators should feel free to rate-limit their relayed traffic. -1.5. Helping the user with port forwarding, NAT, etc. - - Just as for operating normal relays, our documentation and hints for - how to make your ORPort reachable are inadequate for normal users. - - We need to work harder on this step, perhaps in 0.2.1.x. - -1.6. Vidalia integration +1.3. Implementation note. Vidalia 0.0.15 has turned its "Relay" settings page into a tri-state "Don't relay" / "Relay for the Tor network" / "Help censored users". - If you click the third choice, it forces your exit policy to reject *:*, - and it forces your DirPort to 9030 (but see Sec 1.2 above about DirPort). + If you click the third choice, it forces your exit policy to reject *:*. If all the bridges end up on port 9001, that's not so good. On the other hand, putting the bridges on a low-numbered port in the Unix @@ -93,26 +59,15 @@ Implemented-In: 0.2.0.x the bridge identifier to the operator (see Section 3.1) so he can pass it on to bridge users. -1.7. What if the default ORPort is already used? - - If the user already has a webserver or some other application - bound to port 443, then Tor will fail to bind it and complain to the - user, probably in a cryptic way. Rather than just working on a better - error message (though we should do this), we should consider an - "ORPort auto" option that tells Tor to try to find something that's - bindable and reachable. This would also help us tolerate ISPs that - filter incoming connections on port 80 and port 443. But this should - be a different proposal, and can wait until 0.2.1.x. - 2. Bridge authorities. - Bridge authorities are like normal directory authorities, except they - don't create their own network-status documents or votes. So if you - ask an authority for a network-status document or consensus, they - behave like a directory mirror: they give you one from one of the main - authorities. But if you ask the bridge authority for the descriptor - corresponding to a particular identity fingerprint, it will happily - give you the latest descriptor for that fingerprint. + Bridge authorities are like normal v3 directory authorities, except + they don't create their own network-status documents or votes. So if + you ask a bridge authority for a network-status document or consensus, + they behave like a directory mirror: they give you one from one of + the main authorities. But if you ask the bridge authority for the + descriptor corresponding to a particular identity fingerprint, it will + happily give you the latest descriptor for that fingerprint. To become a bridge authority, add these lines to your torrc: AuthoritativeDirectory 1 @@ -127,25 +82,16 @@ Implemented-In: 0.2.0.x annotations, it's easy to look through it and find the bridge-purpose descriptors. - We should work with Tonga to export its router-descriptors file to - some place where we can distribute the bridge addresses according to - the policies in blocking.pdf. It might even be easier to have it write - out a separate file, just for export, that includes only the bridge - descriptors; or maybe a six-liner perl postprocessing script is the - better plan there to create a file for export. + Currently we export the bridge descriptors from Tonga to the + BridgeDB server, so it can give them out according to the policies + in blocking.pdf. 2.2. Reachability/uptime testing - Right now the bridge authorities just passively collect bridge - descriptors, and give them out on request. At some point we are going - to want to recommend new bridges to users, and we'll want to have - some way of deciding which ones are up right now, which ones have - been around for a while, etc. We should have the bridge authorities - do active measurements of bridges just as the normal authorities do - active measurements of normal relays. Then we can export the results - just like in Section 2.1. above. + Right now the bridge authorities do active reachability testing of + bridges, so we know which ones to recommend for users. - In the design document, we suggested that bridges should publish + But in the design document, we suggested that bridges should publish anonymously (i.e. via Tor) to the bridge authority, so somebody watching the bridge authority can't just enumerate all the bridges. But if we're doing active measurement, the game is up. Perhaps we should back off on @@ -153,7 +99,7 @@ Implemented-In: 0.2.0.x Answering this issue is scheduled for 0.2.1.x. -2.3. Migrating to multiple bridge authorities +2.3. Future work: migrating to multiple bridge authorities Having only one bridge authority is both a trust bottleneck (if you break into one place you learn about every single bridge we've got) @@ -164,7 +110,7 @@ Implemented-In: 0.2.0.x a random bridge authority. This resolves the robustness bottleneck, but makes the trust bottleneck even worse. - In 0.2.1.x and later we should think about better ways to have multiple + In 0.2.2.x and later we should think about better ways to have multiple bridge authorities. 3. Bridge users. @@ -174,10 +120,8 @@ Implemented-In: 0.2.0.x entry guards (their first hop) and directory guards (the source of all their directory information). - To become a bridge user, add the following two lines to your torrc: - + To become a bridge user, add the following line to your torrc: UseBridges 1 - TunnelDirConns 1 and then add at least one "Bridge" line to your torrc based on the format below. @@ -293,48 +237,14 @@ Implemented-In: 0.2.0.x first attempt, after 15 minutes for the second attempt, and after 60 minutes for subsequent attempts. - In 0.2.1.x we should come up with some smarter retry schedules. + In 0.2.2.x we should come up with some smarter retry schedules. -3.6. Vidalia integration +3.6. Implementation note. - Vidalia 0.0.15 has a new checkbox in its Network config window called + Vidalia 0.1.0 has a new checkbox in its Network config window called "My ISP blocks connections to the Tor network." Users who click that box change their configuration to: - TunnelDirConns 1 - PreferTunneledDirConns 1 - - Once the box is checked, there is also a section for adding bridge - identifiers. When at least one bridge identifier is present, Vidalia - also changes their config to: UseBridges 1 UpdateBridgesFromAuthority 1 - and updates their Bridge config option accordingly. - -3.7. When should we make TunnelDirConns default - - Right now Tor's directory requests can be filtered on the network, - and some tools used by Middle Eastern governments even do this. A user - who wants to circumvent these filters should click the above box in - Vidalia 0.0.15. But at what point should we make tunneled directory - requests the default? - - Once proposal 124 (modified TLS handshake) is in place, we should - consider doing the switch. This might even be in the 0.2.0.x timeframe. - -3.8. Do we need a second layer of entry guards? - - If the bridge user uses the bridge as its entry guard, then the - triangulation attacks from Lasse and Paul's Oakland paper work to - locate the user's bridge(s). - - Worse, this is another way to enumerate bridges: if the bridge users - keep rotating through second hops, then if you run a few fast servers - (and avoid getting considered an Exit or a Guard) you'll quickly get - a list of the bridges in active use. - - That's probably the strongest reason why bridge users will need to - pick second-layer guards. Would this mean bridge users should switch - to four-hop circuits? - - We should figure this out in the 0.2.1.x timeframe. + and should add at least one bridge identifier. diff --git a/doc/spec/control-spec.txt b/doc/spec/control-spec.txt index 4693407de6..ceb671e16f 100644 --- a/doc/spec/control-spec.txt +++ b/doc/spec/control-spec.txt @@ -564,10 +564,17 @@ $Id$ "OR=" ("0"/"1") SP "DIR=" ("0"/"1") Combines status/reachability/*; controllers MUST ignore unrecognized elements in this entry. - - "status/version/recommended" -- List of currently recommended versions - "status/version/current" -- Status of the current version. One of: - new, old, unrecommended, recommended, new in series, obsolete. + "status/bootstrap-phase" + Returns the most recent bootstrap phase status event + sent. Specifically, it returns a string starting with either + "NOTICE BOOTSTRAP ..." or "WARN BOOTSTRAP ...". Controllers should + use this getinfo when they connect or attach to Tor to learn its + current bootstrap state. + "status/version/recommended" + List of currently recommended versions. + "status/version/current" + Status of the current version. One of: new, old, unrecommended, + recommended, new in series, obsolete. Examples: C: GETINFO version desc/name/moria1 @@ -663,7 +670,7 @@ $Id$ This message informs the server about a new descriptor. If Purpose is specified, it must be either "general", "controller", or "bridge", - else we return a 552 error. + else we return a 552 error. The default is "general". If Cache is specified, it must be either "no" or "yes", else we return a 552 error. If Cache is not specified, Tor will decide for @@ -673,11 +680,11 @@ $Id$ The descriptor, when parsed, must contain a number of well-specified fields, including fields for its nickname and identity. - If there is an error in parsing the descriptor, the server must send a "554 - Invalid descriptor" reply. If the descriptor is well-formed but the server - chooses not to add it, it must reply with a 251 message whose body explains - why the server was not added. If the descriptor is added, Tor replies with - "250 OK". + If there is an error in parsing the descriptor, the server must send a + "554 Invalid descriptor" reply. If the descriptor is well-formed but + the server chooses not to add it, it must reply with a 251 message + whose body explains why the server was not added. If the descriptor + is added, Tor replies with "250 OK". 3.15. REDIRECTSTREAM @@ -1017,9 +1024,9 @@ $Id$ accept reasons not listed above. Reasons are as given in tor-spec.txt, except for: - END (We received a RELAY_END cell from the other side of thise + END (We received a RELAY_END cell from the other side of this stream.) - [XXXX document more.] + [XXXX document more. -NM] The "REMOTE_REASON" field is provided only when we receive a RELAY_END cell, and only if extended events are enabled. It contains the actual @@ -1038,7 +1045,6 @@ $Id$ that requested the connection, and can be (e.g.) used to look up the requesting program. - Purpose = "DIR_FETCH" / "UPLOAD_DESC" / "DNS_REQUEST" / "USER" / "DIRPORT_TEST" @@ -1046,7 +1052,6 @@ $Id$ only if extended events are enabled (see 3.19). Clients MUST accept purposes not listed above. - 4.1.3. OR Connection status changed The syntax is: @@ -1083,9 +1088,9 @@ $Id$ Type = "DIR" / "OR" / "EXIT" / "APP" / ... Num = 1*DIGIT - BytesRead and BytesWritten are the totals. In Tor 0.1.x.y-alpha - and later, we also include a breakdown of the connection types - that used bandwidth this second (not implemented yet). + BytesRead and BytesWritten are the totals. [In a future Tor version, + we may also include a breakdown of the connection types that used + bandwidth this second (not implemented yet).] 4.1.5. Log messages @@ -1174,7 +1179,7 @@ $Id$ controllers. These recommendations are suggestions only; no controller is required to implement them. - Compatibility node: versions of Tor before 0.2.0.22-rc incorrectly + Compatibility note: versions of Tor before 0.2.0.22-rc incorrectly generated "STATUS_SERVER" as "STATUS_SEVER". To be compatible with those versions, tools should accept both. @@ -1280,6 +1285,60 @@ $Id$ Actions for STATUS_CLIENT events can be as follows: + BOOTSTRAP + "PROGRESS=" num + "TAG=" Keyword + "SUMMARY=" String + ["WARNING=" String + "REASON=" Keyword + "COUNT=" num + "RECOMMENDATION=" Keyword + ] + + Tor has made some progress at establishing a connection to the + Tor network, fetching directory information, or making its first + circuit; or it has encountered a problem while bootstrapping. This + status event is especially useful for users with slow connections + or with connectivity problems. + + "Progress" gives a number between 0 and 100 for how far through + the bootstrapping process we are. "Summary" is a string that can + be displayed to the user to describe the *next* task that Tor + will tackle, i.e., the task it is working on after sending the + status event. "Tag" is a string that controllers can use to + recognize bootstrap phases, if they want to do something smarter + than just blindly displaying the summary string; see Section 5 + for the current tags that Tor issues. + + The StatusSeverity describes whether this is a normal bootstrap + phase (severity notice) or an indication of a bootstrapping + problem (severity warn). + + For bootstrap problems, we include the same progress, tag, and + summary values as we would for a normal bootstrap event, but we + also include "warning", "reason", "count", and "recommendation" + key/value combos. The "count" number tells how many bootstrap + problems there have been so far at this phase. The "reason" + string lists one of the reasons allowed in the ORCONN event. The + "warning" argument string with any hints Tor has to offer about + why it's having troubles bootstrapping. + + The "reason" values are long-term-stable controller-facing tags to + identify particular issues in a bootstrapping step. The warning + strings, on the other hand, are human-readable. Controllers + SHOULD NOT rely on the format of any warning string. Currently + the possible values for "recommendation" are either "ignore" or + "warn" -- if ignore, the controller can accumulate the string in + a pile of problems to show the user if the user asks; if warn, + the controller should alert the user that Tor is pretty sure + there's a bootstrapping problem. + + Currently Tor uses recommendation=ignore for the first + nine bootstrap problem reports for a given phase, and then + uses recommendation=warn for subsequent problems at that + phase. Hopefully this is a good balance between tolerating + occasional errors and reporting serious problems quickly. + ENOUGH_DIR_INFO Tor now knows enough network-status documents and enough server descriptors that it's going to start trying to build circuits now. @@ -1533,9 +1592,9 @@ $Id$ 5.3. Backward compatibility with v0 control protocol. - The 'version 0' control protocol was replaced in Tor 0.1.1.x. Support was - removed in Tor 0.2.0.x. Every non-obsolete version of Tor now supports the - version 1 control protocol. + The 'version 0' control protocol was replaced in Tor 0.1.1.x. Support + was removed in Tor 0.2.0.x. Every non-obsolete version of Tor now + supports the version 1 control protocol. For backward compatibility with the "version 0" control protocol, Tor used to check whether the third octet of the first command is zero. @@ -1543,7 +1602,7 @@ $Id$ This compatibility was removed in Tor 0.1.2.16 and 0.2.0.4-alpha. -5.4. Options for use by controllers +5.4. Tor config options for use by controllers Tor provides a few special configuration options for use by controllers. These options can be set and examined by the SETCONF and GETCONF commands, @@ -1583,4 +1642,131 @@ $Id$ As HashedControlPassword, but is not saved to the torrc file by SAVECONF. Added in Tor 0.2.0.20-rc. - + +5.5. Phases from the Bootstrap status event. + + This section describes the various bootstrap phases currently reported + by Tor. Controllers should not assume that the percentages and tags + listed here will continue to match up, or even that the tags will stay + in the same order. Some phases might also be skipped (not reported) + if the associated bootstrap step is already complete, or if the phase + no longer is necessary. Only "starting" and "done" are guaranteed to + exist in all future versions. + + Current Tor versions enter these phases in order, monotonically. + Future Tors MAY revisit earlier stages. + + Phase 0: + tag=starting summary="starting" + + Tor starts out in this phase. + + Phase 5: + tag=conn_dir summary="Connecting to directory mirror" + + Tor sends this event as soon as Tor has chosen a directory mirror -- + e.g. one of the authorities if bootstrapping for the first time or + after a long downtime, or one of the relays listed in its cached + directory information otherwise. + + Tor will stay at this phase until it has successfully established + a TCP connection with some directory mirror. Problems in this phase + generally happen because Tor doesn't have a network connection, or + because the local firewall is dropping SYN packets. + + Phase 10 + tag=handshake_dir summary="Finishing handshake with directory mirror" + + This event occurs when Tor establishes a TCP connection with a relay used + as a directory mirror (or its https proxy if it's using one). Tor remains + in this phase until the TLS handshake with the relay is finished. + + Problems in this phase generally happen because Tor's firewall is + doing more sophisticated MITM attacks on it, or doing packet-level + keyword recognition of Tor's handshake. + + Phase 15: + tag=onehop_create summary="Establishing one-hop circuit for dir info" + + Once TLS is finished with a relay, Tor will send a CREATE_FAST cell + to establish a one-hop circuit for retrieving directory information. + It will remain in this phase until it receives the CREATED_FAST cell + back, indicating that the circuit is ready. + + Phase 20: + tag=requesting_status summary="Asking for networkstatus consensus" + + Once we've finished our one-hop circuit, we will start a new stream + for fetching the networkstatus consensus. We'll stay in this phase + until we get the 'connected' relay cell back, indicating that we've + established a directory connection. + + Phase 25: + tag=loading_status summary="Loading networkstatus consensus" + + Once we've established a directory connection, we will start fetching + the networkstatus consensus document. This could take a while; this + phase is a good opportunity for using the "progress" keyword to indicate + partial progress. + + This phase could stall if the directory mirror we picked doesn't + have a copy of the networkstatus consensus so we have to ask another, + or it does give us a copy but we don't find it valid. + + Phase 40: + tag=loading_keys summary="Loading authority key certs" + + Sometimes when we've finished loading the networkstatus consensus, + we find that we don't have all the authority key certificates for the + keys that signed the consensus. At that point we put the consensus we + fetched on hold and fetch the keys so we can verify the signatures. + + Phase 45 + tag=requesting_descriptors summary="Asking for relay descriptors" + + Once we have a valid networkstatus consensus and we've checked all + its signatures, we start asking for relay descriptors. We stay in this + phase until we have received a 'connected' relay cell in response to + a request for descriptors. + + Phase 50: + tag=loading_descriptors summary="Loading relay descriptors" + + We will ask for relay descriptors from several different locations, + so this step will probably make up the bulk of the bootstrapping, + especially for users with slow connections. We stay in this phase until + we have descriptors for at least 1/4 of the usable relays listed in + the networkstatus consensus. This phase is also a good opportunity to + use the "progress" keyword to indicate partial steps. + + Phase 80: + tag=conn_or summary="Connecting to entry guard" + + Once we have a valid consensus and enough relay descriptors, we choose + some entry guards and start trying to build some circuits. This step + is similar to the "conn_dir" phase above; the only difference is + the context. + + If a Tor starts with enough recent cached directory information, + its first bootstrap status event will be for the conn_or phase. + + Phase 85: + tag=handshake_or summary="Finishing handshake with entry guard" + + This phase is similar to the "handshake_dir" phase, but it gets reached + if we finish a TCP connection to a Tor relay and we have already reached + the "conn_or" phase. We'll stay in this phase until we complete a TLS + handshake with a Tor relay. + + Phase 90: + tag=circuit_create "Establishing circuits" + + Once we've finished our TLS handshake with an entry guard, we will + set about trying to make some 3-hop circuits in case we need them soon. + + Phase 100: + tag=done summary="Done" + + A full 3-hop exit circuit has been established. Tor is ready to handle + application connections now. + diff --git a/doc/spec/proposals/000-index.txt b/doc/spec/proposals/000-index.txt index 87ff2b952b..2747b0fb62 100644 --- a/doc/spec/proposals/000-index.txt +++ b/doc/spec/proposals/000-index.txt @@ -47,7 +47,7 @@ Proposals by number: 122 Network status entries need a new Unnamed flag [CLOSED] 123 Naming authorities automatically create bindings [CLOSED] 124 Blocking resistant TLS certificate usage [SUPERSEDED] -125 Behavior for bridge users, bridge relays, and bridge authorities [FINISHED] +125 Behavior for bridge users, bridge relays, and bridge authorities [CLOSED] 126 Getting GeoIP data and publishing usage summaries [CLOSED] 127 Relaying dirport requests to Tor download site / website [DRAFT] 128 Families of private bridges [FINISHED] @@ -59,7 +59,7 @@ Proposals by number: 134 More robust consensus voting with diverse authority sets [ACCEPTED] 135 Simplify Configuration of Private Tor Networks [ACCEPTED] 136 Mass authority migration with legacy keys [FINISHED] -137 Keep controllers informed as Tor bootstraps [FINISHED] +137 Keep controllers informed as Tor bootstraps [CLOSED] 138 Remove routers that are not Running from consensus documents [CLOSED] 139 Download consensus documents only when it will be trusted [CLOSED] 140 Provide diffs between consensuses [ACCEPTED] @@ -117,10 +117,8 @@ Proposals by status: 099 Miscellaneous proposals FINISHED: 111 Prioritizing local traffic over relayed traffic - 125 Behavior for bridge users, bridge relays, and bridge authorities 128 Families of private bridges 136 Mass authority migration with legacy keys - 137 Keep controllers informed as Tor bootstraps CLOSED: 101 Voting on the Tor Directory System 102 Dropping "opt" from the directory format @@ -135,9 +133,11 @@ Proposals by status: 119 New PROTOCOLINFO command for controllers 122 Network status entries need a new Unnamed flag 123 Naming authorities automatically create bindings + 125 Behavior for bridge users, bridge relays, and bridge authorities 126 Getting GeoIP data and publishing usage summaries 129 Block Insecure Protocols by Default 130 Version 2 Tor connection protocol + 137 Keep controllers informed as Tor bootstraps 138 Remove routers that are not Running from consensus documents 139 Download consensus documents only when it will be trusted 150 Exclude Exit Nodes from a circuit diff --git a/doc/spec/proposals/125-bridges.txt b/doc/spec/proposals/125-bridges.txt index bc6de66083..8bb3169780 100644 --- a/doc/spec/proposals/125-bridges.txt +++ b/doc/spec/proposals/125-bridges.txt @@ -4,7 +4,7 @@ Version: $Revision$ Last-Modified: $Date$ Author: Roger Dingledine Created: 11-Nov-2007 -Status: Finished +Status: Closed Implemented-In: 0.2.0.x 0. Preface @@ -36,52 +36,32 @@ Implemented-In: 0.2.0.x which will cause your relay to not publish anywhere. This could be useful for private bridges. -1.2. Defining DirPort - - Bridges need to answer BEGIN_DIR requests, both so they can answer - "/server/authority" questions ("what's your descriptor?") and so they - can supply their bridge users with cached copies of all the various - Tor network information. - - As of Tor 0.2.0.13-alpha, bridges will answer begin_dir questions - (and cache dir info they see so the answers will be more useful) - whether their DirPort is enabled or not. (After all, we don't care if - they have an open or reachable DirPort to answer begin_dir questions.) - - We need to investigate if there are any anonymity worries with answering - BEGIN_DIR requests when our DirPort is off. I claim that we don't open - any new attacks: it's still a fine question to ask what partitioning - attacks there are when you can query a Tor client about its current - directory opinions, but these attacks already exist when DirPort is on. - We should investigate this in 0.2.1.x. - -1.3. Exit policy +1.2. Exit policy Bridge relays should use an exit policy of "reject *:*". This is because they only need to relay traffic between the bridge users and the rest of the Tor network, so there's no need to let people exit directly from them. -1.4. RelayBandwidthRate / RelayBandwidthBurst +1.3. RelayBandwidthRate / RelayBandwidthBurst We invented the RelayBandwidth* options for this situation: Tor clients who want to allow relaying too. See proposal 111 for details. Relay operators should feel free to rate-limit their relayed traffic. -1.5. Helping the user with port forwarding, NAT, etc. +1.4. Helping the user with port forwarding, NAT, etc. Just as for operating normal relays, our documentation and hints for how to make your ORPort reachable are inadequate for normal users. - We need to work harder on this step, perhaps in 0.2.1.x. + We need to work harder on this step, perhaps in 0.2.2.x. -1.6. Vidalia integration +1.5. Vidalia integration - Vidalia 0.0.15 has turned its "Relay" settings page into a tri-state + Vidalia has turned its "Relay" settings page into a tri-state "Don't relay" / "Relay for the Tor network" / "Help censored users". - If you click the third choice, it forces your exit policy to reject *:*, - and it forces your DirPort to 9030 (but see Sec 1.2 above about DirPort). + If you click the third choice, it forces your exit policy to reject *:*. If all the bridges end up on port 9001, that's not so good. On the other hand, putting the bridges on a low-numbered port in the Unix @@ -93,7 +73,7 @@ Implemented-In: 0.2.0.x the bridge identifier to the operator (see Section 3.1) so he can pass it on to bridge users. -1.7. What if the default ORPort is already used? +1.6. What if the default ORPort is already used? If the user already has a webserver or some other application bound to port 443, then Tor will fail to bind it and complain to the @@ -102,7 +82,7 @@ Implemented-In: 0.2.0.x "ORPort auto" option that tells Tor to try to find something that's bindable and reachable. This would also help us tolerate ISPs that filter incoming connections on port 80 and port 443. But this should - be a different proposal, and can wait until 0.2.1.x. + be a different proposal, and can wait until 0.2.2.x. 2. Bridge authorities. @@ -127,25 +107,16 @@ Implemented-In: 0.2.0.x annotations, it's easy to look through it and find the bridge-purpose descriptors. - We should work with Tonga to export its router-descriptors file to - some place where we can distribute the bridge addresses according to - the policies in blocking.pdf. It might even be easier to have it write - out a separate file, just for export, that includes only the bridge - descriptors; or maybe a six-liner perl postprocessing script is the - better plan there to create a file for export. + Currently we export the bridge descriptors from Tonga to the + BridgeDB server, so it can give them out according to the policies + in blocking.pdf. 2.2. Reachability/uptime testing - Right now the bridge authorities just passively collect bridge - descriptors, and give them out on request. At some point we are going - to want to recommend new bridges to users, and we'll want to have - some way of deciding which ones are up right now, which ones have - been around for a while, etc. We should have the bridge authorities - do active measurements of bridges just as the normal authorities do - active measurements of normal relays. Then we can export the results - just like in Section 2.1. above. + Right now the bridge authorities do active reachability testing of + bridges, so we know which ones to recommend for users. - In the design document, we suggested that bridges should publish + But in the design document, we suggested that bridges should publish anonymously (i.e. via Tor) to the bridge authority, so somebody watching the bridge authority can't just enumerate all the bridges. But if we're doing active measurement, the game is up. Perhaps we should back off on @@ -164,7 +135,7 @@ Implemented-In: 0.2.0.x a random bridge authority. This resolves the robustness bottleneck, but makes the trust bottleneck even worse. - In 0.2.1.x and later we should think about better ways to have multiple + In 0.2.2.x and later we should think about better ways to have multiple bridge authorities. 3. Bridge users. @@ -174,10 +145,9 @@ Implemented-In: 0.2.0.x entry guards (their first hop) and directory guards (the source of all their directory information). - To become a bridge user, add the following two lines to your torrc: + To become a bridge user, add the following line to your torrc: UseBridges 1 - TunnelDirConns 1 and then add at least one "Bridge" line to your torrc based on the format below. @@ -293,35 +263,18 @@ Implemented-In: 0.2.0.x first attempt, after 15 minutes for the second attempt, and after 60 minutes for subsequent attempts. - In 0.2.1.x we should come up with some smarter retry schedules. + In 0.2.2.x we should come up with some smarter retry schedules. 3.6. Vidalia integration - Vidalia 0.0.15 has a new checkbox in its Network config window called + Vidalia 0.0.16 has a checkbox in its Network config window called "My ISP blocks connections to the Tor network." Users who click that box change their configuration to: - TunnelDirConns 1 - PreferTunneledDirConns 1 - - Once the box is checked, there is also a section for adding bridge - identifiers. When at least one bridge identifier is present, Vidalia - also changes their config to: UseBridges 1 UpdateBridgesFromAuthority 1 - and updates their Bridge config option accordingly. - -3.7. When should we make TunnelDirConns default - - Right now Tor's directory requests can be filtered on the network, - and some tools used by Middle Eastern governments even do this. A user - who wants to circumvent these filters should click the above box in - Vidalia 0.0.15. But at what point should we make tunneled directory - requests the default? - - Once proposal 124 (modified TLS handshake) is in place, we should - consider doing the switch. This might even be in the 0.2.0.x timeframe. + and should specify at least one Bridge identifier. -3.8. Do we need a second layer of entry guards? +3.7. Do we need a second layer of entry guards? If the bridge user uses the bridge as its entry guard, then the triangulation attacks from Lasse and Paul's Oakland paper work to diff --git a/doc/spec/proposals/137-bootstrap-phases.txt b/doc/spec/proposals/137-bootstrap-phases.txt index 34800e4b20..18d3dfae12 100644 --- a/doc/spec/proposals/137-bootstrap-phases.txt +++ b/doc/spec/proposals/137-bootstrap-phases.txt @@ -4,7 +4,7 @@ Version: $Revision$ Last-Modified: $Date$ Author: Roger Dingledine Created: 07-Jun-2008 -Status: Finished +Status: Closed Implemented-In: 0.2.1.x 1. Overview. diff --git a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt b/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt index 653630c592..6c9a3c71ed 100644 --- a/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt +++ b/doc/spec/proposals/ideas/xxx-bridge-disbursement.txt @@ -55,7 +55,7 @@ IP-based. approach would also resolve the "Make sure you can't construct a distinct address to match an existing one" note below. -RD] - [I think, if we get a replay, we need to sen back the same + [I think, if we get a replay, we need to send back the same answer as we did the first time, not say "try again." Otherwise we need to worry that an attacker can keep people from getting bridges by preemtively asking for them, -- 2.11.4.GIT