170-user-path-config.txt 4.0 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495
  1. Title: Configuration options regarding circuit building
  2. Filename: 170-user-path-config.txt
  3. Author: Sebastian Hahn
  4. Created: 01-March-2010
  5. Status: Draft
  6. Overview:
  7. This document outlines how Tor handles the user configuration
  8. options to influence the circuit building process.
  9. Motivation:
  10. Tor's treatment of the configuration *Nodes options was surprising
  11. to many users, and quite a few conspiracy theories have crept up. We
  12. should update our specification and code to better describe and
  13. communicate what is going during circuit building, and how we're
  14. honoring configuration. So far, we've been tracking a bugreport
  15. about this behaviour (
  16. https://bugs.torproject.org/flyspray/index.php?do=details&id=1090 )
  17. and Nick replied in a thread on or-talk (
  18. http://archives.seul.org/or/talk/Feb-2010/msg00117.html ).
  19. This proposal tries to document our intention for those configuration
  20. options.
  21. Design:
  22. Five configuration options are available to users to influence Tor's
  23. circuit building. EntryNodes and ExitNodes define a list of nodes
  24. that are for the Entry/Exit position in all circuits. ExcludeNodes
  25. is a list of nodes that are used for no circuit, and
  26. ExcludeExitNodes is a list of nodes that aren't used as the last
  27. hop. StrictNodes defines Tor's behaviour in case of a conflict, for
  28. example when a node that is excluded is the only available
  29. introduction point. Setting StrictNodes to 1 breaks Tor's
  30. functionality in that case, and it will refuse to build such a
  31. circuit.
  32. Neither Nick's email nor bug 1090 have clear suggestions how we
  33. should behave in each case, so I tried to come up with something
  34. that made sense to me.
  35. Security implications:
  36. Deviating from normal circuit building can break one's anonymity, so
  37. the documentation of the above option should contain a warning to
  38. make users aware of the pitfalls.
  39. Specification:
  40. It is proposed that the "User configuration" part of path-spec
  41. (section 2.2.2) be replaced with this:
  42. Users can alter the default behavior for path selection with
  43. configuration options. In case of conflicts (excluding and requiring
  44. the same node) the "StrictNodes" option is used to determine
  45. behaviour. If a nodes is both excluded and required via a
  46. configuration option, the exclusion takes preference.
  47. - If "ExitNodes" is provided, then every request requires an exit
  48. node on the ExitNodes list. If a request is supported by no nodes
  49. on that list, and "StrictNodes" is false, then Tor treats that
  50. request as if ExitNodes were not provided.
  51. - "EntryNodes" behaves analogously.
  52. - If "ExcludeNodes" is provided, then no circuit uses any of the
  53. nodes listed. If a circuit requires an excluded node to be used,
  54. and "StrictNodes" is false, then Tor uses the node in that
  55. position while not using any other of the excluded nodes.
  56. - If "ExcludeExitNodes" is provided, then Tor will not use the nodes
  57. listed for the exit position in a circuit. If a circuit requires
  58. an excluded node to be used in the exit position and "StrictNodes"
  59. is false, then Tor builds that circuit as if ExcludeExitNodes were
  60. not provided.
  61. - If a user tries to connect to or resolve a hostname of the form
  62. <target>.<servername>.exit and the "AllowDotExit" configuration
  63. option is set to 1, the request is rewritten to a request for
  64. <target>, and the request is only supported by the exit whose
  65. nickname or fingerprint is <servername>. If "AllowDotExit" is set
  66. to 0 (default), any request for <anything>.exit is denied.
  67. - When any of the *Nodes settings are changed, all circuits are
  68. expired immediately, to prevent a situation where a previously
  69. built circuit is used even though some of its nodes are now
  70. excluded.
  71. Compatibility:
  72. The old Strict*Nodes options are deprecated, and the StrictNodes
  73. option is new. Tor users may need to update their configuration file.