aboutsummaryrefslogtreecommitdiff
path: root/doc/spec/proposals/170-user-path-config.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/spec/proposals/170-user-path-config.txt')
-rw-r--r--doc/spec/proposals/170-user-path-config.txt95
1 files changed, 0 insertions, 95 deletions
diff --git a/doc/spec/proposals/170-user-path-config.txt b/doc/spec/proposals/170-user-path-config.txt
deleted file mode 100644
index fa74c76f7..000000000
--- a/doc/spec/proposals/170-user-path-config.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-Title: Configuration options regarding circuit building
-Filename: 170-user-path-config.txt
-Author: Sebastian Hahn
-Created: 01-March-2010
-Status: Draft
-
-Overview:
-
- This document outlines how Tor handles the user configuration
- options to influence the circuit building process.
-
-Motivation:
-
- Tor's treatment of the configuration *Nodes options was surprising
- to many users, and quite a few conspiracy theories have crept up. We
- should update our specification and code to better describe and
- communicate what is going during circuit building, and how we're
- honoring configuration. So far, we've been tracking a bugreport
- about this behaviour (
- https://bugs.torproject.org/flyspray/index.php?do=details&id=1090 )
- and Nick replied in a thread on or-talk (
- http://archives.seul.org/or/talk/Feb-2010/msg00117.html ).
-
- This proposal tries to document our intention for those configuration
- options.
-
-Design:
-
- Five configuration options are available to users to influence Tor's
- circuit building. EntryNodes and ExitNodes define a list of nodes
- that are for the Entry/Exit position in all circuits. ExcludeNodes
- is a list of nodes that are used for no circuit, and
- ExcludeExitNodes is a list of nodes that aren't used as the last
- hop. StrictNodes defines Tor's behaviour in case of a conflict, for
- example when a node that is excluded is the only available
- introduction point. Setting StrictNodes to 1 breaks Tor's
- functionality in that case, and it will refuse to build such a
- circuit.
-
- Neither Nick's email nor bug 1090 have clear suggestions how we
- should behave in each case, so I tried to come up with something
- that made sense to me.
-
-Security implications:
-
- Deviating from normal circuit building can break one's anonymity, so
- the documentation of the above option should contain a warning to
- make users aware of the pitfalls.
-
-Specification:
-
- It is proposed that the "User configuration" part of path-spec
- (section 2.2.2) be replaced with this:
-
- Users can alter the default behavior for path selection with
- configuration options. In case of conflicts (excluding and requiring
- the same node) the "StrictNodes" option is used to determine
- behaviour. If a nodes is both excluded and required via a
- configuration option, the exclusion takes preference.
-
- - If "ExitNodes" is provided, then every request requires an exit
- node on the ExitNodes list. If a request is supported by no nodes
- on that list, and "StrictNodes" is false, then Tor treats that
- request as if ExitNodes were not provided.
-
- - "EntryNodes" behaves analogously.
-
- - If "ExcludeNodes" is provided, then no circuit uses any of the
- nodes listed. If a circuit requires an excluded node to be used,
- and "StrictNodes" is false, then Tor uses the node in that
- position while not using any other of the excluded nodes.
-
- - If "ExcludeExitNodes" is provided, then Tor will not use the nodes
- listed for the exit position in a circuit. If a circuit requires
- an excluded node to be used in the exit position and "StrictNodes"
- is false, then Tor builds that circuit as if ExcludeExitNodes were
- not provided.
-
- - If a user tries to connect to or resolve a hostname of the form
- <target>.<servername>.exit and the "AllowDotExit" configuration
- option is set to 1, the request is rewritten to a request for
- <target>, and the request is only supported by the exit whose
- nickname or fingerprint is <servername>. If "AllowDotExit" is set
- to 0 (default), any request for <anything>.exit is denied.
-
- - When any of the *Nodes settings are changed, all circuits are
- expired immediately, to prevent a situation where a previously
- built circuit is used even though some of its nodes are now
- excluded.
-
-
-Compatibility:
-
- The old Strict*Nodes options are deprecated, and the StrictNodes
- option is new. Tor users may need to update their configuration file.