torproject/tor
1
0
Fork 0
mirror of https://gitlab.torproject.org/tpo/core/tor.git synced 2024-12-06 19:41:15 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

update and integrate proposals 125 (bridges) and 137 (bootstrap status)

Browse Source 
svn:r16374
This commit is contained in:
Roger Dingledine
2008-08-03 15:34:28 +00:00
parent 44536fddbc
commit 449174d796
7 changed files with 492 additions and 102 deletions
Download Patch File Download Diff File Expand all files Collapse all files
doc/spec/address-spec.txt
+5 -4
View File
@@ -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
doc/spec/bridges-spec.txt
+250
View File
@@ -0,0 +1,250 @@
$Id$
Tor bridges specification
0. Preface
This document describes the design decisions around support for bridge
users, bridge relays, and bridge authorities. It acts as an overview
of the bridge design and deployment for developers, and it also tries
to point out limitations in the current design and implementation.
For more details on what all of these mean, look at blocking.tex in
/doc/design-paper/
1. Bridge relays
Bridge relays are just like normal Tor relays except they don't publish
their server descriptors to the main directory authorities.
1.1. PublishServerDescriptor
To configure your relay to be a bridge relay, just add
BridgeRelay 1
PublishServerDescriptor bridge
to your torrc. This will cause your relay to publish its descriptor
to the bridge authorities rather than to the default authorities.
Alternatively, you can say
BridgeRelay 1
PublishServerDescriptor 0
which will cause your relay to not publish anywhere. This could be
useful for private bridges.
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.
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.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 *:*.
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
world requires jumping through extra hoops. The current compromise is
that Vidalia makes the ORPort default to 443 on Windows, and 9001 on
other platforms.
At the bottom of the relay config settings window, Vidalia displays
the bridge identifier to the operator (see Section 3.1) so he can pass
it on to bridge users.
2. Bridge authorities.
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
BridgeAuthoritativeDir 1
Right now there's one bridge authority, running on the Tonga relay.
2.1. Exporting bridge-purpose descriptors
We've added a new purpose for server descriptors: the "bridge"
purpose. With the new router-descriptors file format that includes
annotations, it's easy to look through it and find the bridge-purpose
descriptors.
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 do active reachability testing of
bridges, so we know which ones to recommend for users.
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
this goal, or perhaps we should do our active measurement anonymously?
Answering this issue is scheduled for 0.2.1.x.
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)
and a robustness bottleneck (when it's down, bridge users become sad).
Right now if we put up a second bridge authority, all the bridges would
publish to it, and (assuming the code works) bridge users would query
a random bridge authority. This resolves the robustness bottleneck,
but makes the trust bottleneck even worse.
In 0.2.2.x and later we should think about better ways to have multiple
bridge authorities.
3. Bridge users.
Bridge users are like ordinary Tor users except they use encrypted
directory connections by default, and they use bridge relays as both
entry guards (their first hop) and directory guards (the source of
all their directory information).
To become a bridge user, add the following line to your torrc:
UseBridges 1
and then add at least one "Bridge" line to your torrc based on the
format below.
3.1. Format of the bridge identifier.
The canonical format for a bridge identifier contains an IP address,
an ORPort, and an identity fingerprint:
bridge 128.31.0.34:9009 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
However, the identity fingerprint can be left out, in which case the
bridge user will connect to that relay and use it as a bridge regardless
of what identity key it presents:
bridge 128.31.0.34:9009
This might be useful for cases where only short bridge identifiers
can be communicated to bridge users.
In a future version we may also support bridge identifiers that are
only a key fingerprint:
bridge 4C17 FB53 2E20 B2A8 AC19 9441 ECD2 B017 7B39 E4B1
and the bridge user can fetch the latest descriptor from the bridge
authority (see Section 3.4).
3.2. Bridges as entry guards
For now, bridge users add their bridge relays to their list of "entry
guards" (see path-spec.txt for background on entry guards). They are
managed by the entry guard algorithms exactly as if they were a normal
entry guard -- their keys and timing get cached in the "state" file,
etc. This means that when the Tor user starts up with "UseBridges"
disabled, he will skip past the bridge entries since they won't be
listed as up and usable in his networkstatus consensus. But to be clear,
the "entry_guards" list doesn't currently distinguish guards by purpose.
Internally, each bridge user keeps a smartlist of "bridge_info_t"
that reflects the "bridge" lines from his torrc along with a download
schedule (see Section 3.5 below). When he starts Tor, he attempts
to fetch a descriptor for each configured bridge (see Section 3.4
below). When he succeeds at getting a descriptor for one of the bridges
in his list, he adds it directly to the entry guard list using the
normal add_an_entry_guard() interface. Once a bridge descriptor has
been added, should_delay_dir_fetches() will stop delaying further
directory fetches, and the user begins to bootstrap his directory
information from that bridge (see Section 3.3).
Currently bridge users cache their bridge descriptors to the
"cached-descriptors" file (annotated with purpose "bridge"), but
they don't make any attempt to reuse descriptors they find in this
file. The theory is that either the bridge is available now, in which
case you can get a fresh descriptor, or it's not, in which case an
old descriptor won't do you much good.
We could disable writing out the bridge lines to the state file, if
we think this is a problem.
As an exception, if we get an application request when we have one
or more bridge descriptors but we believe none of them are running,
we mark them all as running again. This is similar to the exception
already in place to help long-idle Tor clients realize they should
fetch fresh directory information rather than just refuse requests.
3.3. Bridges as directory guards
In addition to using bridges as the first hop in their circuits, bridge
users also use them to fetch directory updates. Other than initial
bootstrapping to find a working bridge descriptor (see Section 3.4
below), all further non-anonymized directory fetches will be redirected
to the bridge.
This means that bridge relays need to have cached answers for all
questions the bridge user might ask. This makes the upgrade path
tricky --- for example, if we migrate to a v4 directory design, the
bridge user would need to keep using v3 so long as his bridge relays
only knew how to answer v3 queries.
In a future design, for cases where the user has enough information
to build circuits yet the chosen bridge doesn't know how to answer a
given query, we might teach bridge users to make an anonymized request
to a more suitable directory server.
3.4. How bridge users get their bridge descriptor
Bridge users can fetch bridge descriptors in two ways: by going directly
to the bridge and asking for "/tor/server/authority", or by going to
the bridge authority and asking for "/tor/server/fp/ID". By default,
they will only try the direct queries. If the user sets
UpdateBridgesFromAuthority 1
in his config file, then he will try querying the bridge authority
first for bridges where he knows a digest (if he only knows an IP
address and ORPort, then his only option is a direct query).
If the user has at least one working bridge, then he will do further
queries to the bridge authority through a full three-hop Tor circuit.
But when bootstrapping, he will make a direct begin_dir-style connection
to the bridge authority.
As of Tor 0.2.0.10-alpha, if the user attempts to fetch a descriptor
from the bridge authority and it returns a 404 not found, the user
will automatically fall back to trying a direct query. Therefore it is
recommended that bridge users always set UpdateBridgesFromAuthority,
since at worst it will delay their fetches a little bit and notify
the bridge authority of the identity fingerprint (but not location)
of their intended bridges.
3.5. Bridge descriptor retry schedule
Bridge users try to fetch a descriptor for each bridge (using the
steps in Section 3.4 above) on startup. Whenever they receive a
bridge descriptor, they reschedule a new descriptor download for 1
hour from then.
If on the other hand it fails, they try again after 15 minutes for the
first attempt, after 15 minutes for the second attempt, and after 60
minutes for subsequent attempts.
In 0.2.2.x we should come up with some smarter retry schedules.
3.6. Implementation note.
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:
UseBridges 1
UpdateBridgesFromAuthority 1
and should add at least one bridge identifier.
doc/spec/control-spec.txt
+209 -23
View File
@@ -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.
doc/spec/proposals/000-index.txt
+4 -4
View File
@@ -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
doc/spec/proposals/125-bridges.txt
+22 -69
View File
@@ -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.
and should specify at least one Bridge identifier.
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?
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
doc/spec/proposals/137-bootstrap-phases.txt
+1 -1
View File
@@ -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.
doc/spec/proposals/ideas/xxx-bridge-disbursement.txt
+1 -1
View File
@@ -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,