2010-07-09 01:55:22 +00:00
|
|
|
## translation metadata
|
2010-10-27 10:31:57 +00:00
|
|
|
# Revision: $Revision$
|
2010-07-09 01:55:22 +00:00
|
|
|
|
|
|
|
|
#include "head.wmi" TITLE="Tor Project: manual"
|
|
|
|
|
|
|
|
|
|
# Translators shouldn't translate this file, unless they want
|
|
|
|
|
# to translate the whole man page too.
|
|
|
|
|
<div id="content" class="clearfix">
|
|
|
|
|
<div id="breadcrumbs">
|
2010-08-12 15:17:47 +00:00
|
|
|
<a href="<page index>">Home » </a>
|
2010-07-09 01:55:22 +00:00
|
|
|
<a href="<page docs/documentation>">Documentation » </a>
|
2011-03-25 13:08:28 +00:00
|
|
|
<a href="<page docs/tor-doc-osx>">Tor Manual</a>
|
2010-07-09 01:55:22 +00:00
|
|
|
</div>
|
2011-03-25 13:08:28 +00:00
|
|
|
<div id="maincol">
|
|
|
|
|
<h2 id="_synopsis">SYNOPSIS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p><strong>tor</strong> [<em>OPTION</em> <em>value</em>]…</p>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_description">DESCRIPTION</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p><em>tor</em> is a connection-oriented anonymizing communication
|
|
|
|
|
service. Users choose a source-routed path through a set of nodes, and
|
|
|
|
|
negotiate a "virtual circuit" through the network, in which each node
|
|
|
|
|
knows its predecessor and successor, but no others. Traffic flowing down
|
|
|
|
|
the circuit is unwrapped by a symmetric key at each node, which reveals
|
|
|
|
|
the downstream node.<br /></p></div>
|
|
|
|
|
|
|
|
|
|
<div class="paragraph"><p>Basically <em>tor</em> provides a distributed network of servers ("onion routers").
|
|
|
|
|
Users bounce their TCP streams — web traffic, ftp, ssh, etc — around the
|
|
|
|
|
routers, and recipients, observers, and even the routers themselves have
|
|
|
|
|
difficulty tracking the source of the stream.</p></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_options">OPTIONS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>-h</strong>, <strong>-help</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Display a short help message and exit.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>-f</strong> <em>FILE</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
FILE contains further "option value" pairs. (Default: @CONFDIR@/torrc)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>--hash-password</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Generates a hashed password for control port access.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>--list-fingerprint</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Generate your keys and output your nickname and fingerprint.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>--verify-config</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Verify the configuration file is valid.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>--nt-service</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
<strong>--service [install|remove|start|stop]</strong> Manage the Tor Windows
|
|
|
|
|
NT/2000/XP service. Current instructions can be found at
|
2011-06-11 18:55:49 +00:00
|
|
|
<a href="<wiki>doc/TorFAQ#WinNTService">https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#WinNTService</a>
|
2011-03-25 13:08:28 +00:00
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>--list-torrc-options</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
List all valid options.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>--version</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Display Tor version and exit.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>--quiet</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Do not start Tor with a console log unless explicitly requested to do so.
|
|
|
|
|
(By default, Tor starts out logging messages at level "notice" or higher to
|
|
|
|
|
the console, until it has parsed its configuration.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="paragraph">
|
|
|
|
|
<p>Other options can be specified either on the command-line (--option
|
|
|
|
|
value), or in the configuration file (option value or option "value").
|
|
|
|
|
Options are case-insensitive. C-style escaped characters are allowed inside
|
|
|
|
|
quoted values. Options on the command line take precedence over
|
|
|
|
|
options found in the configuration file, except indicated otherwise. To
|
|
|
|
|
split one configuration entry into multiple lines, use a single \ before
|
|
|
|
|
the end of the line. Comments can be used in such multiline entries, but
|
|
|
|
|
they must start at the beginning of a line.</p>
|
|
|
|
|
</div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>BandwidthRate</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A token bucket limits the average incoming bandwidth usage on this node to
|
|
|
|
|
the specified number of bytes per second, and the average outgoing
|
|
|
|
|
bandwidth usage to that same value. If you want to run a relay in the
|
|
|
|
|
public network, this needs to be <em>at the very least</em> 20 KB (that is,
|
|
|
|
|
20480 bytes). (Default: 5 MB)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>BandwidthBurst</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Limit the maximum token bucket size (also known as the burst) to the given
|
|
|
|
|
number of bytes in each direction. (Default: 10 MB)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>MaxAdvertisedBandwidth</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set, we will not advertise more than this amount of bandwidth for our
|
|
|
|
|
BandwidthRate. Server operators who want to reduce the number of clients
|
|
|
|
|
who ask to build circuits through them (since this is proportional to
|
|
|
|
|
advertised bandwidth rate) can thus reduce the CPU demands on their server
|
|
|
|
|
without impacting network performance.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RelayBandwidthRate</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If not 0, a separate token bucket limits the average incoming bandwidth
|
|
|
|
|
usage for _relayed traffic_ on this node to the specified number of bytes
|
|
|
|
|
per second, and the average outgoing bandwidth usage to that same value.
|
|
|
|
|
Relayed traffic currently is calculated to include answers to directory
|
|
|
|
|
requests, but that may change in future versions. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RelayBandwidthBurst</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If not 0, limit the maximum token bucket size (also known as the burst) for
|
|
|
|
|
_relayed traffic_ to the given number of bytes in each direction.
|
|
|
|
|
(Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ConnLimit</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The minimum number of file descriptors that must be available to the Tor
|
|
|
|
|
process before it will start. Tor will ask the OS for as many file
|
|
|
|
|
descriptors as the OS will allow (you can find this by "ulimit -H -n").
|
|
|
|
|
If this number is less than ConnLimit, then Tor will refuse to start.<br />
|
|
|
|
|
<br />
|
|
|
|
|
You probably don’t need to adjust this. It has no effect on Windows
|
|
|
|
|
since that platform lacks getrlimit(). (Default: 1000)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ConstrainedSockets</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set, Tor will tell the kernel to attempt to shrink the buffers for all
|
|
|
|
|
sockets to the size specified in <strong>ConstrainedSockSize</strong>. This is useful for
|
|
|
|
|
virtual servers and other environments where system level TCP buffers may
|
|
|
|
|
be limited. If you’re on a virtual server, and you encounter the "Error
|
|
|
|
|
creating network socket: No buffer space available" message, you are
|
|
|
|
|
likely experiencing this problem.<br />
|
|
|
|
|
<br />
|
|
|
|
|
The preferred solution is to have the admin increase the buffer pool for
|
|
|
|
|
the host itself via /proc/sys/net/ipv4/tcp_mem or equivalent facility;
|
|
|
|
|
this configuration option is a second-resort.<br />
|
|
|
|
|
<br />
|
|
|
|
|
The DirPort option should also not be used if TCP buffers are scarce. The
|
|
|
|
|
cached directory requests consume additional sockets which exacerbates
|
|
|
|
|
the problem.<br />
|
|
|
|
|
<br />
|
|
|
|
|
You should <strong>not</strong> enable this feature unless you encounter the "no buffer
|
|
|
|
|
space available" issue. Reducing the TCP buffers affects window size for
|
|
|
|
|
the TCP stream and will reduce throughput in proportion to round trip
|
|
|
|
|
time on long paths. (Default: 0.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ConstrainedSockSize</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When <strong>ConstrainedSockets</strong> is enabled the receive and transmit buffers for
|
|
|
|
|
all sockets will be set to this limit. Must be a value between 2048 and
|
|
|
|
|
262144, in 1024 byte increments. Default of 8192 is recommended.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ControlPort</strong> <em>Port</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set, Tor will accept connections on this port and allow those
|
|
|
|
|
connections to control the Tor process using the Tor Control Protocol
|
|
|
|
|
(described in control-spec.txt). Note: unless you also specify one of
|
|
|
|
|
<strong>HashedControlPassword</strong> or <strong>CookieAuthentication</strong>, setting this option will
|
|
|
|
|
cause Tor to allow any process on the local host to control it. This
|
|
|
|
|
option is required for many Tor controllers; most use the value of 9051.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ControlListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Bind the controller listener to this address. If you specify a port, bind
|
|
|
|
|
to this port rather than the one specified in ControlPort. We strongly
|
|
|
|
|
recommend that you leave this alone unless you know what you’re doing,
|
|
|
|
|
since giving attackers access to your control listener is really
|
|
|
|
|
dangerous. (Default: 127.0.0.1) This directive can be specified multiple
|
|
|
|
|
times to bind to multiple addresses/ports.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ControlSocket</strong> <em>Path</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Like ControlPort, but listens on a Unix domain socket, rather than a TCP
|
|
|
|
|
socket. (Unix and Unix-like systems only.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HashedControlPassword</strong> <em>hashed_password</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Don’t allow any connections on the control port except when the other
|
|
|
|
|
process knows the password whose one-way hash is <em>hashed_password</em>. You
|
|
|
|
|
can compute the hash of a password by running "tor --hash-password
|
|
|
|
|
<em>password</em>". You can provide several acceptable passwords by using more
|
|
|
|
|
than one HashedControlPassword line.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>CookieAuthentication</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If this option is set to 1, don’t allow any connections on the control port
|
|
|
|
|
except when the connecting process knows the contents of a file named
|
|
|
|
|
"control_auth_cookie", which Tor will create in its data directory. This
|
|
|
|
|
authentication method should only be used on systems with good filesystem
|
|
|
|
|
security. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>CookieAuthFile</strong> <em>Path</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set, this option overrides the default location and file name
|
|
|
|
|
for Tor’s cookie file. (See CookieAuthentication above.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>CookieAuthFileGroupReadable</strong> <strong>0</strong>|<strong>1</strong>|<em>Groupname</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If this option is set to 0, don’t allow the filesystem group to read the
|
|
|
|
|
cookie file. If the option is set to 1, make the cookie file readable by
|
|
|
|
|
the default GID. [Making the file readable by other groups is not yet
|
|
|
|
|
implemented; let us know if you need this for some reason.] (Default: 0).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DataDirectory</strong> <em>DIR</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Store working data in DIR (Default: @LOCALSTATEDIR@/lib/tor)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DirServer</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em>fingerprint</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Use a nonstandard authoritative directory server at the provided address
|
|
|
|
|
and port, with the specified key fingerprint. This option can be repeated
|
|
|
|
|
many times, for multiple authoritative directory servers. Flags are
|
|
|
|
|
separated by spaces, and determine what kind of an authority this directory
|
|
|
|
|
is. By default, every authority is authoritative for current ("v2")-style
|
|
|
|
|
directories, unless the "no-v2" flag is given. If the "v1" flags is
|
|
|
|
|
provided, Tor will use this server as an authority for old-style (v1)
|
|
|
|
|
directories as well. (Only directory mirrors care about this.) Tor will
|
|
|
|
|
use this server as an authority for hidden service information if the "hs"
|
|
|
|
|
flag is set, or if the "v1" flag is set and the "no-hs" flag is <strong>not</strong> set.
|
|
|
|
|
Tor will use this authority as a bridge authoritative directory if the
|
|
|
|
|
"bridge" flag is set. If a flag "orport=<strong>port</strong>" is given, Tor will use the
|
|
|
|
|
given port when opening encrypted tunnels to the dirserver. Lastly, if a
|
|
|
|
|
flag "v3ident=<strong>fp</strong>" is given, the dirserver is a v3 directory authority
|
|
|
|
|
whose v3 long-term signing key has the fingerprint <strong>fp</strong>.<br />
|
|
|
|
|
<br />
|
|
|
|
|
If no <strong>dirserver</strong> line is given, Tor will use the default directory
|
|
|
|
|
servers. NOTE: this option is intended for setting up a private Tor
|
|
|
|
|
network with its own directory authorities. If you use it, you will be
|
|
|
|
|
distinguishable from other users, because you won’t believe the same
|
|
|
|
|
authorities they do.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
<div class="paragraph"><p><strong>AlternateDirAuthority</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em>fingerprint</em><br /></p></div>
|
|
|
|
|
<div class="paragraph"><p><strong>AlternateHSAuthority</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em>fingerprint</em><br /></p></div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AlternateBridgeAuthority</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em> fingerprint</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
As DirServer, but replaces less of the default directory authorities. Using
|
|
|
|
|
AlternateDirAuthority replaces the default Tor directory authorities, but
|
|
|
|
|
leaves the hidden service authorities and bridge authorities in place.
|
|
|
|
|
Similarly, Using AlternateHSAuthority replaces the default hidden service
|
|
|
|
|
authorities, but not the directory or bridge authorities.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FetchDirInfoEarly</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 1, Tor will always fetch directory information like other
|
|
|
|
|
directory caches, even if you don’t meet the normal criteria for fetching
|
|
|
|
|
early. Normal users should leave it off. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FetchHidServDescriptors</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 0, Tor will never fetch any hidden service descriptors from the
|
|
|
|
|
rendezvous directories. This option is only useful if you’re using a Tor
|
|
|
|
|
controller that handles hidden service fetches for you. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FetchServerDescriptors</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 0, Tor will never fetch any network status summaries or server
|
|
|
|
|
descriptors from the directory servers. This option is only useful if
|
|
|
|
|
you’re using a Tor controller that handles directory fetches for you.
|
|
|
|
|
(Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FetchUselessDescriptors</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 1, Tor will fetch every non-obsolete descriptor from the
|
|
|
|
|
authorities that it hears about. Otherwise, it will avoid fetching useless
|
|
|
|
|
descriptors, for example for routers that are not running. This option is
|
|
|
|
|
useful if you’re using the contributed "exitlist" script to enumerate Tor
|
|
|
|
|
nodes that exit to certain addresses. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HTTPProxy</strong> <em>host</em>[:<em>port</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tor will make all its directory requests through this host:port (or host:80
|
|
|
|
|
if port is not specified), rather than connecting directly to any directory
|
|
|
|
|
servers.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HTTPProxyAuthenticator</strong> <em>username:password</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If defined, Tor will use this username:password for Basic HTTP proxy
|
|
|
|
|
authentication, as in RFC 2617. This is currently the only form of HTTP
|
|
|
|
|
proxy authentication that Tor supports; feel free to submit a patch if you
|
|
|
|
|
want it to support others.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HTTPSProxy</strong> <em>host</em>[:<em>port</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tor will make all its OR (SSL) connections through this host:port (or
|
|
|
|
|
host:443 if port is not specified), via HTTP CONNECT rather than connecting
|
|
|
|
|
directly to servers. You may want to set <strong>FascistFirewall</strong> to restrict
|
|
|
|
|
the set of ports you might try to connect to, if your HTTPS proxy only
|
|
|
|
|
allows connecting to certain ports.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HTTPSProxyAuthenticator</strong> <em>username:password</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If defined, Tor will use this username:password for Basic HTTPS proxy
|
|
|
|
|
authentication, as in RFC 2617. This is currently the only form of HTTPS
|
|
|
|
|
proxy authentication that Tor supports; feel free to submit a patch if you
|
|
|
|
|
want it to support others.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>KeepalivePeriod</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
To keep firewalls from expiring connections, send a padding keepalive cell
|
|
|
|
|
every NUM seconds on open connections that are in use. If the connection
|
|
|
|
|
has no open circuits, it will instead be closed after NUM seconds of
|
|
|
|
|
idleness. (Default: 5 minutes)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>Log</strong> <em>minSeverity</em>[-<em>maxSeverity</em>] <strong>stderr</strong>|<strong>stdout</strong>|<strong>syslog</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Send all messages between <em>minSeverity</em> and <em>maxSeverity</em> to the standard
|
|
|
|
|
output stream, the standard error stream, or to the system log. (The
|
|
|
|
|
"syslog" value is only supported on Unix.) Recognized severity levels are
|
|
|
|
|
debug, info, notice, warn, and err. We advise using "notice" in most cases,
|
|
|
|
|
since anything more verbose may provide sensitive information to an
|
|
|
|
|
attacker who obtains the logs. If only one severity level is given, all
|
|
|
|
|
messages of that level or higher will be sent to the listed destination.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>Log</strong> <em>minSeverity</em>[-<em>maxSeverity</em>] <strong>file</strong> <em>FILENAME</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
As above, but send log messages to the listed filename. The
|
|
|
|
|
"Log" option may appear more than once in a configuration file.
|
|
|
|
|
Messages are sent to all the logs that match their severity
|
|
|
|
|
level.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>OutboundBindAddress</strong> <em>IP</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Make all outbound connections originate from the IP address specified. This
|
|
|
|
|
is only useful when you have multiple network interfaces, and you want all
|
|
|
|
|
of Tor’s outgoing connections to use a single one. This setting will be
|
|
|
|
|
ignored for connections to the loopback addresses (127.0.0.0/8 and ::1).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>PidFile</strong> <em>FILE</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
On startup, write our PID to FILE. On clean shutdown, remove
|
|
|
|
|
FILE.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ProtocolWarnings</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If 1, Tor will log with severity 'warn' various cases of other parties not
|
|
|
|
|
following the Tor specification. Otherwise, they are logged with severity
|
|
|
|
|
'info'. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RunAsDaemon</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If 1, Tor forks and daemonizes to the background. This option has no effect
|
|
|
|
|
on Windows; instead you should use the --service command-line option.
|
|
|
|
|
(Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SafeLogging</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tor can scrub potentially sensitive strings from log messages (e.g.
|
|
|
|
|
addresses) by replacing them with the string [scrubbed]. This way logs can
|
|
|
|
|
still be useful, but they don’t leave behind personally identifying
|
|
|
|
|
information about what sites a user might have visited.<br />
|
|
|
|
|
<br />
|
|
|
|
|
If this option is set to 0, Tor will not perform any scrubbing, if it is
|
|
|
|
|
set to 1, all potentially sensitive strings are replaced. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>User</strong> <em>UID</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
On startup, setuid to this user and setgid to their primary group.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HardwareAccel</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If non-zero, try to use built-in (static) crypto hardware acceleration when
|
|
|
|
|
available. This is untested and probably buggy. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AvoidDiskWrites</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If non-zero, try to write to disk less frequently than we would otherwise.
|
|
|
|
|
This is useful when running on flash memory or other media that support
|
|
|
|
|
only a limited number of writes. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TunnelDirConns</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If non-zero, when a directory server we contact supports it, we will build
|
|
|
|
|
a one-hop circuit and make an encrypted connection via its ORPort.
|
|
|
|
|
(Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>PreferTunneledDirConns</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If non-zero, we will avoid directory servers that don’t support tunneled
|
|
|
|
|
directory connections, when possible. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_client_options">CLIENT OPTIONS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>The following options are useful only for clients (that is, if
|
|
|
|
|
<strong>SocksPort</strong> is non-zero):</p></div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AllowInvalidNodes</strong> <strong>entry</strong>|<strong>exit</strong>|<strong>middle</strong>|<strong>introduction</strong>|<strong>rendezvous</strong>|<strong>…</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If some Tor servers are obviously not working right, the directory
|
|
|
|
|
authorities can manually mark them as invalid, meaning that it’s not
|
|
|
|
|
recommended you use them for entry or exit positions in your circuits. You
|
|
|
|
|
can opt to use them in some circuit positions, though. The default is
|
|
|
|
|
"middle,rendezvous", and other choices are not advised.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ExcludeSingleHopRelays</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
This option controls whether circuits built by Tor will include relays with
|
|
|
|
|
the AllowSingleHopExits flag set to true. If ExcludeSingleHopRelays is set
|
|
|
|
|
to 0, these relays will be included. Note that these relays might be at
|
|
|
|
|
higher risk of being seized or observed, so they are not normally
|
|
|
|
|
included. Also note that relatively few clients turn off this option,
|
|
|
|
|
so using these relays might make your client stand out.
|
|
|
|
|
(Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>Bridge</strong> <em>IP</em>:<em>ORPort</em> [fingerprint]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When set along with UseBridges, instructs Tor to use the relay at
|
|
|
|
|
"IP:ORPort" as a "bridge" relaying into the Tor network. If "fingerprint"
|
|
|
|
|
is provided (using the same format as for DirServer), we will verify that
|
|
|
|
|
the relay running at that location has the right fingerprint. We also use
|
|
|
|
|
fingerprint to look up the bridge descriptor at the bridge authority, if
|
|
|
|
|
it’s provided and if UpdateBridgesFromAuthority is set too.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>CircuitBuildTimeout</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Try for at most NUM seconds when building circuits. If the circuit isn't
|
|
|
|
|
open in that time, give up on it. (Default: 1 minute.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>CircuitIdleTimeout</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If we have kept a clean (never used) circuit around for NUM seconds, then
|
|
|
|
|
close it. This way when the Tor client is entirely idle, it can expire all
|
|
|
|
|
of its circuits, and then expire its TLS connections. Also, if we end up
|
|
|
|
|
making a circuit that is not useful for exiting any of the requests we’re
|
|
|
|
|
receiving, it won’t forever take up a slot in the circuit list. (Default: 1
|
|
|
|
|
hour.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ClientOnly</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 1, Tor will under no circumstances run as a server or serve
|
|
|
|
|
directory requests. The default is to run as a client unless ORPort is
|
|
|
|
|
configured. (Usually, you don’t need to set this; Tor is pretty smart at
|
|
|
|
|
figuring out whether you are reliable and high-bandwidth enough to be a
|
|
|
|
|
useful server.) (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ExcludeNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A list of identity fingerprints, nicknames, country codes and address
|
|
|
|
|
patterns of nodes to never use when building a circuit. (Example:
|
|
|
|
|
ExcludeNodes SlowServer, $ EFFFFFFFFFFFFFFF, {cc}, 255.254.0.0/8)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ExcludeExitNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A list of identity fingerprints, nicknames, country codes and address
|
|
|
|
|
patterns of nodes to never use when picking an exit node. Note that any
|
|
|
|
|
node listed in ExcludeNodes is automatically considered to be part of this
|
|
|
|
|
list.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>EntryNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A list of identity fingerprints, nicknames and address
|
|
|
|
|
patterns of nodes to use for the first hop in normal circuits. These are
|
|
|
|
|
treated only as preferences unless StrictNodes (see below) is also set.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ExitNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A list of identity fingerprints, nicknames, country codes and address
|
|
|
|
|
patterns of nodes to use for the last hop in normal exit circuits. These
|
|
|
|
|
are treated only as preferences unless StrictNodes (see below) is also set.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>StrictEntryNodes</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If 1, Tor will never use any nodes besides those listed in "EntryNodes" for
|
|
|
|
|
the first hop of a circuit.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>StrictExitNodes</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If 1, Tor will never use any nodes besides those listed in "ExitNodes" for
|
|
|
|
|
the last hop of a circuit.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FascistFirewall</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If 1, Tor will only create outgoing connections to ORs running on ports
|
|
|
|
|
that your firewall allows (defaults to 80 and 443; see <strong>FirewallPorts</strong>).
|
|
|
|
|
This will allow you to run Tor as a client behind a firewall with
|
|
|
|
|
restrictive policies, but will not allow you to run as a server behind such
|
|
|
|
|
a firewall. If you prefer more fine-grained control, use
|
|
|
|
|
ReachableAddresses instead.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FirewallPorts</strong> <em>PORTS</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A list of ports that your firewall allows you to connect to. Only used when
|
|
|
|
|
<strong>FascistFirewall</strong> is set. This option is deprecated; use ReachableAddresses
|
|
|
|
|
instead. (Default: 80, 443)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HidServAuth</strong> <em>onion-address</em> <em>auth-cookie</em> [<em>service-name</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Client authorization for a hidden service. Valid onion addresses contain 16
|
|
|
|
|
characters in a-z2-7 plus ".onion", and valid auth cookies contain 22
|
|
|
|
|
characters in A-Za-z0-9+/. The service name is only used for internal
|
|
|
|
|
purposes, e.g., for Tor controllers. This option may be used multiple times
|
|
|
|
|
for different hidden services. If a hidden service uses authorization and
|
|
|
|
|
this option is not set, the hidden service is not accessible. Hidden
|
|
|
|
|
services can be configured to require authorization using the
|
|
|
|
|
<strong>HiddenServiceAuthorizeClient</strong> option.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ReachableAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]…
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A comma-separated list of IP addresses and ports that your firewall allows
|
|
|
|
|
you to connect to. The format is as for the addresses in ExitPolicy, except
|
|
|
|
|
that "accept" is understood unless "reject" is explicitly provided. For
|
|
|
|
|
example, 'ReachableAddresses 99.0.0.0/8, reject 18.0.0.0/8:80, accept
|
|
|
|
|
*:80' means that your firewall allows connections to everything inside net
|
|
|
|
|
99, rejects port 80 connections to net 18, and accepts connections to port
|
|
|
|
|
80 otherwise. (Default: 'accept *:*'.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ReachableDirAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]…
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Like <strong>ReachableAddresses</strong>, a list of addresses and ports. Tor will obey
|
|
|
|
|
these restrictions when fetching directory information, using standard HTTP
|
|
|
|
|
GET requests. If not set explicitly then the value of
|
|
|
|
|
<strong>ReachableAddresses</strong> is used. If <strong>HTTPProxy</strong> is set then these
|
|
|
|
|
connections will go through that proxy.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ReachableORAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]…
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Like <strong>ReachableAddresses</strong>, a list of addresses and ports. Tor will obey
|
|
|
|
|
these restrictions when connecting to Onion Routers, using TLS/SSL. If not
|
|
|
|
|
set explicitly then the value of <strong>ReachableAddresses</strong> is used. If
|
|
|
|
|
<strong>HTTPSProxy</strong> is set then these connections will go through that proxy.<br />
|
|
|
|
|
<br />
|
|
|
|
|
The separation between <strong>ReachableORAddresses</strong> and
|
|
|
|
|
<strong>ReachableDirAddresses</strong> is only interesting when you are connecting
|
|
|
|
|
through proxies (see <strong>HTTPProxy</strong> and <strong>HTTPSProxy</strong>). Most proxies limit
|
|
|
|
|
TLS connections (which Tor uses to connect to Onion Routers) to port 443,
|
|
|
|
|
and some limit HTTP GET requests (which Tor uses for fetching directory
|
|
|
|
|
information) to port 80.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>LongLivedPorts</strong> <em>PORTS</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A list of ports for services that tend to have long-running connections
|
|
|
|
|
(e.g. chat and interactive shells). Circuits for streams that use these
|
|
|
|
|
ports will contain only high-uptime nodes, to reduce the chance that a node
|
|
|
|
|
will go down before the stream is finished. (Default: 21, 22, 706, 1863,
|
|
|
|
|
5050, 5190, 5222, 5223, 6667, 6697, 8300)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>MapAddress</strong> <em>address</em> <em>newaddress</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When a request for address arrives to Tor, it will rewrite it to newaddress
|
|
|
|
|
before processing it. For example, if you always want connections to
|
|
|
|
|
www.indymedia.org to exit via <em>torserver</em> (where <em>torserver</em> is the
|
|
|
|
|
nickname of the server), use "MapAddress www.indymedia.org
|
|
|
|
|
www.indymedia.org.torserver.exit".
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>NewCircuitPeriod</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Every NUM seconds consider whether to build a new circuit. (Default: 30
|
|
|
|
|
seconds)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>MaxCircuitDirtiness</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Feel free to reuse a circuit that was first used at most NUM seconds ago,
|
|
|
|
|
but never attach a new stream to a circuit that is too old. (Default: 10
|
|
|
|
|
minutes)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>NodeFamily</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The Tor servers, defined by their identity fingerprints or nicknames,
|
|
|
|
|
constitute a "family" of similar or co-administered servers, so never use
|
|
|
|
|
any two of them in the same circuit. Defining a NodeFamily is only needed
|
|
|
|
|
when a server doesn’t list the family itself (with MyFamily). This option
|
|
|
|
|
can be used multiple times.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>EnforceDistinctSubnets</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If 1, Tor will not put two servers whose IP addresses are "too close" on
|
|
|
|
|
the same circuit. Currently, two addresses are "too close" if they lie in
|
|
|
|
|
the same /16 range. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SocksPort</strong> <em>PORT</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Advertise this port to listen for connections from Socks-speaking
|
|
|
|
|
applications. Set this to 0 if you don’t want to allow application
|
|
|
|
|
connections. (Default: 9050)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SocksListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Bind to this address to listen for connections from Socks-speaking
|
|
|
|
|
applications. (Default: 127.0.0.1) You can also specify a port (e.g.
|
|
|
|
|
192.168.0.1:9100). This directive can be specified multiple times to bind
|
|
|
|
|
to multiple addresses/ports.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SocksPolicy</strong> <em>policy</em>,<em>policy</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Set an entrance policy for this server, to limit who can connect to the
|
|
|
|
|
SocksPort and DNSPort ports. The policies have the same form as exit
|
|
|
|
|
policies below.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SocksTimeout</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Let a socks connection wait NUM seconds handshaking, and NUM seconds
|
|
|
|
|
unattached waiting for an appropriate circuit, before we fail it. (Default:
|
|
|
|
|
2 minutes.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TrackHostExits</strong> <em>host</em>,<em>.domain</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
For each value in the comma separated list, Tor will track recent
|
|
|
|
|
connections to hosts that match this value and attempt to reuse the same
|
|
|
|
|
exit node for each. If the value is prepended with a '.', it is treated as
|
|
|
|
|
matching an entire domain. If one of the values is just a '.', it means
|
|
|
|
|
match everything. This option is useful if you frequently connect to sites
|
|
|
|
|
that will expire all your authentication cookies (i.e. log you out) if
|
|
|
|
|
your IP address changes. Note that this option does have the disadvantage
|
|
|
|
|
of making it more clear that a given history is associated with a single
|
|
|
|
|
user. However, most people who would wish to observe this will observe it
|
|
|
|
|
through cookies or other protocol-specific means anyhow.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TrackHostExitsExpire</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Since exit servers go up and down, it is desirable to expire the
|
|
|
|
|
association between host and exit server after NUM seconds. The default is
|
|
|
|
|
1800 seconds (30 minutes).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>UpdateBridgesFromAuthority</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When set (along with UseBridges), Tor will try to fetch bridge descriptors
|
|
|
|
|
from the configured bridge authorities when feasible. It will fall back to
|
|
|
|
|
a direct request if the authority responds with a 404. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>UseBridges</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When set, Tor will fetch descriptors for each bridge listed in the "Bridge"
|
|
|
|
|
config lines, and use these relays as both entry guards and directory
|
|
|
|
|
guards. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>UseEntryGuards</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If this option is set to 1, we pick a few long-term entry servers, and try
|
|
|
|
|
to stick with them. This is desirable because constantly changing servers
|
|
|
|
|
increases the odds that an adversary who owns some servers will observe a
|
|
|
|
|
fraction of your paths. (Defaults to 1.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>NumEntryGuards</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If UseEntryGuards is set to 1, we will try to pick a total of NUM routers
|
|
|
|
|
as long-term entries for our circuits. (Defaults to 3.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SafeSocks</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is enabled, Tor will reject application connections that
|
|
|
|
|
use unsafe variants of the socks protocol — ones that only provide an IP
|
|
|
|
|
address, meaning the application is doing a DNS resolve first.
|
|
|
|
|
Specifically, these are socks4 and socks5 when not doing remote DNS.
|
|
|
|
|
(Defaults to 0.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TestSocks</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is enabled, Tor will make a notice-level log entry for
|
|
|
|
|
each connection to the Socks port indicating whether the request used a
|
|
|
|
|
safe socks protocol or an unsafe one (see above entry on SafeSocks). This
|
|
|
|
|
helps to determine whether an application using Tor is possibly leaking
|
|
|
|
|
DNS requests. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>VirtualAddrNetwork</strong> <em>Address</em>/<em>bits</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When Tor needs to assign a virtual (unused) address because of a MAPADDRESS
|
|
|
|
|
command from the controller or the AutomapHostsOnResolve feature, Tor
|
|
|
|
|
picks an unassigned address from this range. (Default:
|
|
|
|
|
127.192.0.0/10)<br />
|
|
|
|
|
<br />
|
|
|
|
|
When providing proxy server service to a network of computers using a tool
|
|
|
|
|
like dns-proxy-tor, change this address to "10.192.0.0/10" or
|
|
|
|
|
"172.16.0.0/12". The default <strong>VirtualAddrNetwork</strong> address range on a
|
|
|
|
|
properly configured machine will route to the loopback interface. For
|
|
|
|
|
local use, no change to the default VirtualAddrNetwork setting is needed.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AllowNonRFC953Hostnames</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is disabled, Tor blocks hostnames containing illegal
|
|
|
|
|
characters (like @ and :) rather than sending them to an exit node to be
|
|
|
|
|
resolved. This helps trap accidental attempts to resolve URLs and so on.
|
|
|
|
|
(Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FastFirstHopPK</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is disabled, Tor uses the public key step for the first
|
|
|
|
|
hop of creating circuits. Skipping it is generally safe since we have
|
|
|
|
|
already used TLS to authenticate the relay and to establish forward-secure
|
|
|
|
|
keys. Turning this option off makes circuit building slower.<br />
|
|
|
|
|
<br />
|
|
|
|
|
Note that Tor will always use the public key step for the first hop if it’s
|
|
|
|
|
operating as a relay, and it will never use the public key step if it
|
|
|
|
|
doesn’t yet know the onion key of the first hop. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TransPort</strong> <em>PORT</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If non-zero, enables transparent proxy support on <em>PORT</em> (by convention,
|
|
|
|
|
9040). Requires OS support for transparent proxies, such as BSDs' pf or
|
|
|
|
|
Linux’s IPTables. If you’re planning to use Tor as a transparent proxy for
|
|
|
|
|
a network, you’ll want to examine and change VirtualAddrNetwork from the
|
|
|
|
|
default setting. You’ll also want to set the TransListenAddress option for
|
|
|
|
|
the network you’d like to proxy. (Default: 0).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TransListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Bind to this address to listen for transparent proxy connections. (Default:
|
|
|
|
|
127.0.0.1). This is useful for exporting a transparent proxy server to an
|
|
|
|
|
entire network.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>NATDPort</strong> <em>PORT</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Allow old versions of ipfw (as included in old versions of FreeBSD, etc.)
|
|
|
|
|
to send connections through Tor using the NATD protocol. This option is
|
|
|
|
|
only for people who cannot use TransPort.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>NATDListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Bind to this address to listen for NATD connections. (Default: 127.0.0.1).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AutomapHostsOnResolve</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is enabled, and we get a request to resolve an address
|
|
|
|
|
that ends with one of the suffixes in <strong>AutomapHostsSuffixes</strong>, we map an
|
|
|
|
|
unused virtual address to that address, and return the new virtual address.
|
|
|
|
|
This is handy for making ".onion" addresses work with applications that
|
|
|
|
|
resolve an address and then connect to it. (Default: 0).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AutomapHostsSuffixes</strong> <em>SUFFIX</em>,<em>SUFFIX</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A comma-separated list of suffixes to use with <strong>AutomapHostsOnResolve</strong>.
|
|
|
|
|
The "." suffix is equivalent to "all addresses." (Default: .exit,.onion).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DNSPort</strong> <em>PORT</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If non-zero, Tor listens for UDP DNS requests on this port and resolves
|
|
|
|
|
them anonymously. (Default: 0).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DNSListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Bind to this address to listen for DNS connections. (Default: 127.0.0.1).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ClientDNSRejectInternalAddresses</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If true, Tor does not believe any anonymously retrieved DNS answer that
|
|
|
|
|
tells it that an address resolves to an internal address (like 127.0.0.1 or
|
|
|
|
|
192.168.0.1). This option prevents certain browser-based attacks; don’t
|
|
|
|
|
turn it off unless you know what you’re doing. (Default: 1).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DownloadExtraInfo</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If true, Tor downloads and caches "extra-info" documents. These documents
|
|
|
|
|
contain information about servers other than the information in their
|
|
|
|
|
regular router descriptors. Tor does not use this information for anything
|
|
|
|
|
itself; to save bandwidth, leave this option turned off. (Default: 0).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>FallbackNetworkstatusFile</strong> <em>FILENAME</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If Tor doesn’t have a cached networkstatus file, it starts out using this
|
|
|
|
|
one instead. Even if this file is out of date, Tor can still use it to
|
|
|
|
|
learn about directory mirrors, so it doesn’t need to put load on the
|
|
|
|
|
authorities. (Default: None).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>WarnPlaintextPorts</strong> <em>port</em>,<em>port</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tells Tor to issue a warnings whenever the user tries to make an anonymous
|
|
|
|
|
connection to one of these ports. This option is designed to alert users
|
|
|
|
|
to services that risk sending passwords in the clear. (Default:
|
|
|
|
|
23,109,110,143).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RejectPlaintextPorts</strong> <em>port</em>,<em>port</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Like WarnPlaintextPorts, but instead of warning about risky port uses, Tor
|
|
|
|
|
will instead refuse to make the connection. (Default: None).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_server_options">SERVER OPTIONS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>The following options are useful only for servers (that is, if ORPort
|
|
|
|
|
is non-zero):</p></div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>Address</strong> <em>address</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The IP address or fully qualified domain name of this server (e.g.
|
|
|
|
|
moria.mit.edu). You can leave this unset, and Tor will guess your IP
|
|
|
|
|
address.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AllowSingleHopExits</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
This option controls whether clients can use this server as a single hop
|
|
|
|
|
proxy. If set to 1, clients can use this server as an exit even if it is
|
|
|
|
|
the only hop in the circuit. Note that most clients will refuse to use
|
|
|
|
|
servers that set this option, since most clients have
|
|
|
|
|
ExcludeSingleHopRelays set. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AssumeReachable</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
This option is used when bootstrapping a new Tor network. If set to 1,
|
|
|
|
|
don’t do self-reachability testing; just upload your server descriptor
|
|
|
|
|
immediately. If <strong>AuthoritativeDirectory</strong> is also set, this option
|
|
|
|
|
instructs the dirserver to bypass remote reachability testing too and list
|
|
|
|
|
all connected servers as running.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>BridgeRelay</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Sets the relay to act as a "bridge" with respect to relaying connections
|
|
|
|
|
from bridge users to the Tor network. It mainly causes Tor to publish a
|
|
|
|
|
server descriptor to the bridge database, rather than publishing a relay
|
|
|
|
|
descriptor to the public directory authorities.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ContactInfo</strong> <em>email_address</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Administrative contact information for server. This line might get picked
|
|
|
|
|
up by spam harvesters, so you may want to obscure the fact that it’s an
|
|
|
|
|
email address.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ExitPolicy</strong> <em>policy</em>,<em>policy</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Set an exit policy for this server. Each policy is of the form
|
|
|
|
|
"<strong>accept</strong>|<strong>reject</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]". If /<em>MASK</em> is
|
|
|
|
|
omitted then this policy just applies to the host given. Instead of giving
|
|
|
|
|
a host or network you can also use "*" to denote the universe (0.0.0.0/0).
|
|
|
|
|
<em>PORT</em> can be a single port number, an interval of ports
|
|
|
|
|
"<em>FROM_PORT</em>-<em>TO_PORT</em>", or "*". If <em>PORT</em> is omitted, that means
|
|
|
|
|
"*".<br />
|
|
|
|
|
<br />
|
|
|
|
|
For example, "accept 18.7.22.69:*,reject 18.0.0.0/8:*,accept *:*" would
|
|
|
|
|
reject any traffic destined for MIT except for web.mit.edu, and accept
|
|
|
|
|
anything else.<br />
|
|
|
|
|
<br />
|
|
|
|
|
To specify all internal and link-local networks (including 0.0.0.0/8,
|
|
|
|
|
169.254.0.0/16, 127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8, and
|
|
|
|
|
172.16.0.0/12), you can use the "private" alias instead of an address.
|
|
|
|
|
These addresses are rejected by default (at the beginning of your exit
|
|
|
|
|
policy), along with your public IP address, unless you set the
|
|
|
|
|
ExitPolicyRejectPrivate config option to 0. For example, once you’ve done
|
|
|
|
|
that, you could allow HTTP to 127.0.0.1 and block all other connections to
|
|
|
|
|
internal networks with "accept 127.0.0.1:80,reject private:*", though that
|
|
|
|
|
may also allow connections to your own computer that are addressed to its
|
|
|
|
|
public (external) IP address. See RFC 1918 and RFC 3330 for more details
|
|
|
|
|
about internal and reserved IP address space.<br />
|
|
|
|
|
<br />
|
|
|
|
|
This directive can be specified multiple times so you don’t have to put it
|
|
|
|
|
all on one line.<br />
|
|
|
|
|
<br />
|
|
|
|
|
Policies are considered first to last, and the first match wins. If you
|
|
|
|
|
want to _replace_ the default exit policy, end your exit policy with
|
|
|
|
|
either a reject *:* or an accept *:*. Otherwise, you’re _augmenting_
|
|
|
|
|
(prepending to) the default exit policy. The default exit policy is:<br />
|
|
|
|
|
</p>
|
|
|
|
|
<div class="literalblock">
|
|
|
|
|
<div class="content">
|
|
|
|
|
<pre><tt>reject *:25^M
|
|
|
|
|
reject *:119^M
|
|
|
|
|
reject *:135-139^M
|
|
|
|
|
reject *:445^M
|
|
|
|
|
reject *:563^M
|
|
|
|
|
reject *:1214^M
|
|
|
|
|
reject *:4661-4666^M
|
|
|
|
|
reject *:6346-6429^M
|
|
|
|
|
reject *:6699^M
|
|
|
|
|
reject *:6881-6999^M
|
|
|
|
|
accept *:*</tt></pre>
|
|
|
|
|
</div></div>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ExitPolicyRejectPrivate</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Reject all private (local) networks, along with your own public IP address,
|
|
|
|
|
at the beginning of your exit policy. See above entry on ExitPolicy.
|
|
|
|
|
(Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>MaxOnionsPending</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If you have more than this number of onionskins queued for decrypt, reject
|
|
|
|
|
new ones. (Default: 100)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>MyFamily</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Declare that this Tor server is controlled or administered by a group or
|
|
|
|
|
organization identical or similar to that of the other servers, defined by
|
|
|
|
|
their identity fingerprints or nicknames. When two servers both declare
|
|
|
|
|
that they are in the same 'family', Tor clients will not use them in the
|
|
|
|
|
same circuit. (Each server only needs to list the other servers in its
|
|
|
|
|
family; it doesn’t need to list itself, but it won’t hurt.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>Nickname</strong> <em>name</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Set the server’s nickname to 'name'. Nicknames must be between 1 and 19
|
|
|
|
|
characters inclusive, and must contain only the characters [a-zA-Z0-9].
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>NumCPUs</strong> <em>num</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
How many processes to use at once for decrypting onionskins. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ORPort</strong> <em>PORT</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Advertise this port to listen for connections from Tor clients and servers.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ORListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Bind to this IP address to listen for connections from Tor clients and
|
|
|
|
|
servers. If you specify a port, bind to this port rather than the one
|
|
|
|
|
specified in ORPort. (Default: 0.0.0.0) This directive can be specified
|
|
|
|
|
multiple times to bind to multiple addresses/ports.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>PublishServerDescriptor</strong> <strong>0</strong>|<strong>1</strong>|<strong>v1</strong>|<strong>v2</strong>|<strong>v3</strong>|<strong>bridge</strong>,<strong>…</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
This option specifies which descriptors Tor will publish when acting as
|
|
|
|
|
a relay. You can
|
|
|
|
|
choose multiple arguments, separated by commas.
|
|
|
|
|
<br />
|
|
|
|
|
If this option is set to 0, Tor will not publish its
|
|
|
|
|
descriptors to any directories. (This is useful if you’re testing
|
|
|
|
|
out your server, or if you’re using a Tor controller that handles directory
|
|
|
|
|
publishing for you.) Otherwise, Tor will publish its descriptors of all
|
|
|
|
|
type(s) specified. The default is "1",
|
|
|
|
|
which means "if running as a server, publish the
|
|
|
|
|
appropriate descriptors to the authorities".
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ShutdownWaitLength</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When we get a SIGINT and we’re a server, we begin shutting down:
|
|
|
|
|
we close listeners and start refusing new circuits. After <strong>NUM</strong>
|
|
|
|
|
seconds, we exit. If we get a second SIGINT, we exit immedi-
|
|
|
|
|
ately. (Default: 30 seconds)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AccountingMax</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>|<strong>TB</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Never send more than the specified number of bytes in a given accounting
|
|
|
|
|
period, or receive more than that number in the period. For example, with
|
|
|
|
|
AccountingMax set to 1 GB, a server could send 900 MB and receive 800 MB
|
|
|
|
|
and continue running. It will only hibernate once one of the two reaches 1
|
|
|
|
|
GB. When the number of bytes gets low, Tor will stop accepting new
|
|
|
|
|
connections and circuits. When the number of bytes
|
|
|
|
|
is exhausted, Tor will hibernate until some
|
|
|
|
|
time in the next accounting period. To prevent all servers from waking at
|
|
|
|
|
the same time, Tor will also wait until a random point in each period
|
|
|
|
|
before waking up. If you have bandwidth cost issues, enabling hibernation
|
|
|
|
|
is preferable to setting a low bandwidth, since it provides users with a
|
|
|
|
|
collection of fast servers that are up some of the time, which is more
|
|
|
|
|
useful than a set of slow servers that are always "available".
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AccountingStart</strong> <strong>day</strong>|<strong>week</strong>|<strong>month</strong> [<em>day</em>] <em>HH:MM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Specify how long accounting periods last. If <strong>month</strong> is given, each
|
|
|
|
|
accounting period runs from the time <em>HH:MM</em> on the <em>dayth</em> day of one
|
|
|
|
|
month to the same day and time of the next. (The day must be between 1 and
|
|
|
|
|
28.) If <strong>week</strong> is given, each accounting period runs from the time <em>HH:MM</em>
|
|
|
|
|
of the <em>dayth</em> day of one week to the same day and time of the next week,
|
|
|
|
|
with Monday as day 1 and Sunday as day 7. If <strong>day</strong> is given, each
|
|
|
|
|
accounting period runs from the time <em>HH:MM</em> each day to the same time on
|
|
|
|
|
the next day. All times are local, and given in 24-hour time. (Defaults to
|
|
|
|
|
"month 1 0:00".)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ServerDNSResolvConfFile</strong> <em>filename</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Overrides the default DNS configuration with the configuration in
|
|
|
|
|
<em>filename</em>. The file format is the same as the standard Unix
|
|
|
|
|
"<strong>resolv.conf</strong>" file (7). This option, like all other ServerDNS options,
|
|
|
|
|
only affects name lookups that your server does on behalf of clients.
|
|
|
|
|
(Defaults to use the system DNS configuration.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ServerDNSAllowBrokenConfig</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If this option is false, Tor exits immediately if there are problems
|
|
|
|
|
parsing the system DNS configuration or connecting to nameservers.
|
|
|
|
|
Otherwise, Tor continues to periodically retry the system nameservers until
|
|
|
|
|
it eventually succeeds. (Defaults to "1".)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ServerDNSSearchDomains</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 1, then we will search for addresses in the local search domain.
|
|
|
|
|
For example, if this system is configured to believe it is in
|
|
|
|
|
"example.com", and a client tries to connect to "www", the client will be
|
|
|
|
|
connected to "www.example.com". This option only affects name lookups that
|
|
|
|
|
your server does on behalf of clients. (Defaults to "0".)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ServerDNSDetectHijacking</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set to 1, we will test periodically to determine
|
|
|
|
|
whether our local nameservers have been configured to hijack failing DNS
|
|
|
|
|
requests (usually to an advertising site). If they are, we will attempt to
|
|
|
|
|
correct this. This option only affects name lookups that your server does
|
|
|
|
|
on behalf of clients. (Defaults to "1".)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ServerDNSTestAddresses</strong> <em>address</em>,<em>address</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When we’re detecting DNS hijacking, make sure that these <em>valid</em> addresses
|
|
|
|
|
aren’t getting redirected. If they are, then our DNS is completely useless,
|
|
|
|
|
and we’ll reset our exit policy to "reject <strong>:</strong>". This option only affects
|
|
|
|
|
name lookups that your server does on behalf of clients. (Defaults to
|
|
|
|
|
"www.google.com, www.mit.edu, www.yahoo.com, www.slashdot.org".)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ServerDNSAllowNonRFC953Hostnames</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is disabled, Tor does not try to resolve hostnames
|
|
|
|
|
containing illegal characters (like @ and :) rather than sending them to an
|
|
|
|
|
exit node to be resolved. This helps trap accidental attempts to resolve
|
|
|
|
|
URLs and so on. This option only affects name lookups that your server does
|
|
|
|
|
on behalf of clients. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>BridgeRecordUsageByCountry</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is enabled and BridgeRelay is also enabled, and we have
|
|
|
|
|
GeoIP data, Tor keeps a keep a per-country count of how many client
|
|
|
|
|
addresses have contacted it so that it can help the bridge authority guess
|
|
|
|
|
which countries have blocked access to it. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>ServerDNSRandomizeCase</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set, Tor sets the case of each character randomly in
|
|
|
|
|
outgoing DNS requests, and makes sure that the case matches in DNS replies.
|
|
|
|
|
This so-called "0x20 hack" helps resist some types of DNS poisoning attack.
|
|
|
|
|
For more information, see "Increased DNS Forgery Resistance through
|
|
|
|
|
0x20-Bit Encoding". This option only affects name lookups that your server
|
|
|
|
|
does on behalf of clients. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>GeoIPFile</strong> <em>filename</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A filename containing GeoIP data, for use with BridgeRecordUsageByCountry.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_directory_server_options">DIRECTORY SERVER OPTIONS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>The following options are useful only for directory servers (that is,
|
|
|
|
|
if DirPort is non-zero):</p></div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set to 1, Tor operates as an authoritative directory
|
|
|
|
|
server. Instead of caching the directory, it generates its own list of
|
|
|
|
|
good servers, signs it, and sends that to the clients. Unless the clients
|
|
|
|
|
already have you listed as a trusted directory, you probably do not want
|
|
|
|
|
to set this option. Please coordinate with the other admins at
|
|
|
|
|
<a href="mailto:tor-ops@torproject.org">tor-ops@torproject.org</a> if you think you should be a directory.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DirPortFrontPage</strong> <em>FILENAME</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set, it takes an HTML file and publishes it as "/" on
|
|
|
|
|
the DirPort. Now relay operators can provide a disclaimer without needing
|
|
|
|
|
to set up a separate webserver. There’s a sample disclaimer in
|
|
|
|
|
contrib/tor-exit-notice.html.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>V1AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
|
|
|
|
|
generates version 1 directory and running-routers documents (for legacy
|
|
|
|
|
Tor clients up to 0.1.0.x).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>V2AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
|
|
|
|
|
generates version 2 network statuses and serves descriptors, etc as
|
|
|
|
|
described in doc/spec/dir-spec-v2.txt (for Tor clients and servers running
|
|
|
|
|
0.1.1.x and 0.1.2.x).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>V3AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
|
|
|
|
|
generates version 3 network statuses and serves descriptors, etc as
|
|
|
|
|
described in doc/spec/dir-spec.txt (for Tor clients and servers running at
|
|
|
|
|
least 0.2.0.x).
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>VersioningAuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set to 1, Tor adds information on which versions of
|
|
|
|
|
Tor are still believed safe for use to the published directory. Each
|
|
|
|
|
version 1 authority is automatically a versioning authority; version 2
|
|
|
|
|
authorities provide this service optionally. See <strong>RecommendedVersions</strong>,
|
|
|
|
|
<strong>RecommendedClientVersions</strong>, and <strong>RecommendedServerVersions</strong>.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>NamingAuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set to 1, then the server advertises that it has
|
|
|
|
|
opinions about nickname-to-fingerprint bindings. It will include these
|
|
|
|
|
opinions in its published network-status pages, by listing servers with
|
|
|
|
|
the flag "Named" if a correct binding between that nickname and fingerprint
|
|
|
|
|
has been registered with the dirserver. Naming dirservers will refuse to
|
|
|
|
|
accept or publish descriptors that contradict a registered binding. See
|
|
|
|
|
<strong>approved-routers</strong> in the <strong>FILES</strong> section below.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HSAuthoritativeDir</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set in addition to
|
|
|
|
|
<strong>AuthoritativeDirectory</strong>, Tor also accepts and serves hidden
|
|
|
|
|
service descriptors. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HSAuthorityRecordStats</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set in addition to <strong>HSAuthoritativeDir</strong>,
|
|
|
|
|
Tor periodically (every 15 minutes) writes statistics about hidden service
|
|
|
|
|
usage to a file <strong>hsusage</strong> in its data directory. (Default:
|
|
|
|
|
0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HidServDirectoryV2</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set, Tor accepts and serves v2 hidden service
|
|
|
|
|
descriptors. Setting DirPort is not required for this, because clients
|
|
|
|
|
connect via the ORPort by default. (Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>BridgeAuthoritativeDir</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
|
|
|
|
|
accepts and serves router descriptors, but it caches and serves the main
|
|
|
|
|
networkstatus documents rather than generating its own. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>MinUptimeHidServDirectoryV2</strong> <em>N</em> <strong>seconds</strong>|<strong>minutes</strong>|<strong>hours</strong>|<strong>days</strong>|<strong>weeks</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Minimum uptime of a v2 hidden service directory to be accepted as such by
|
|
|
|
|
authoritative directories. (Default: 24 hours)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DirPort</strong> <em>PORT</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Advertise the directory service on this port.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DirListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Bind the directory service to this address. If you specify a port, bind to
|
|
|
|
|
this port rather than the one specified in DirPort. (Default: 0.0.0.0)
|
|
|
|
|
This directive can be specified multiple times to bind to multiple
|
|
|
|
|
addresses/ports.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DirPolicy</strong> <em>policy</em>,<em>policy</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Set an entrance policy for this server, to limit who can connect to the
|
|
|
|
|
directory ports. The policies have the same form as exit policies above.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_directory_authority_server_options">DIRECTORY AUTHORITY SERVER OPTIONS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RecommendedVersions</strong> <em>STRING</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
STRING is a comma-separated list of Tor versions currently believed to be
|
|
|
|
|
safe. The list is included in each directory, and nodes which pull down the
|
|
|
|
|
directory learn whether they need to upgrade. This option can appear
|
|
|
|
|
multiple times: the values from multiple lines are spliced together. When
|
|
|
|
|
this is set then <strong>VersioningAuthoritativeDirectory</strong> should be set too.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RecommendedClientVersions</strong> <em>STRING</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
STRING is a comma-separated list of Tor versions currently believed to be
|
|
|
|
|
safe for clients to use. This information is included in version 2
|
|
|
|
|
directories. If this is not set then the value of <strong>RecommendedVersions</strong>
|
|
|
|
|
is used. When this is set then <strong>VersioningAuthoritativeDirectory</strong> should
|
|
|
|
|
be set too.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RecommendedServerVersions</strong> <em>STRING</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
STRING is a comma-separated list of Tor versions currently believed to be
|
|
|
|
|
safe for servers to use. This information is included in version 2
|
|
|
|
|
directories. If this is not set then the value of <strong>RecommendedVersions</strong>
|
|
|
|
|
is used. When this is set then <strong>VersioningAuthoritativeDirectory</strong> should
|
|
|
|
|
be set too.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>DirAllowPrivateAddresses</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 1, Tor will accept router descriptors with arbitrary "Address"
|
|
|
|
|
elements. Otherwise, if the address is not an IP address or is a private IP
|
|
|
|
|
address, it will reject the router descriptor. Defaults to 0.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirBadDir</strong> <em>AddressPattern…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. A set of address patterns for servers that
|
|
|
|
|
will be listed as bad directories in any network status document this
|
|
|
|
|
authority publishes, if <strong>AuthDirListBadDirs</strong> is set.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirBadExit</strong> <em>AddressPattern…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. A set of address patterns for servers that
|
|
|
|
|
will be listed as bad exits in any network status document this authority
|
|
|
|
|
publishes, if <strong>AuthDirListBadExits</strong> is set.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirInvalid</strong> <em>AddressPattern…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. A set of address patterns for servers that
|
|
|
|
|
will never be listed as "valid" in any network status document that this
|
|
|
|
|
authority publishes.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirReject</strong> <em>AddressPattern</em>…
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. A set of address patterns for servers that
|
|
|
|
|
will never be listed at all in any network status document that this
|
|
|
|
|
authority publishes, or accepted as an OR address in any descriptor
|
|
|
|
|
submitted for publication by this authority.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirListBadDirs</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. If set to 1, this directory has some
|
|
|
|
|
opinion about which nodes are unsuitable as directory caches. (Do not set
|
|
|
|
|
this to 1 unless you plan to list non-functioning directories as bad;
|
|
|
|
|
otherwise, you are effectively voting in favor of every declared
|
|
|
|
|
directory.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirListBadExits</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. If set to 1, this directory has some
|
|
|
|
|
opinion about which nodes are unsuitable as exit nodes. (Do not set this to
|
|
|
|
|
1 unless you plan to list non-functioning exits as bad; otherwise, you are
|
|
|
|
|
effectively voting in favor of every declared exit as an exit.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirRejectUnlisted</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. If set to 1, the directory server rejects
|
|
|
|
|
all uploaded server descriptors that aren’t explicitly listed in the
|
|
|
|
|
fingerprints file. This acts as a "panic button" if we get hit with a Sybil
|
|
|
|
|
attack. (Default: 0)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirMaxServersPerAddr</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. The maximum number of servers that we will
|
|
|
|
|
list as acceptable on a single IP address. Set this to "0" for "no limit".
|
|
|
|
|
(Default: 2)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>AuthDirMaxServersPerAuthAddr</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authoritative directories only. Like AuthDirMaxServersPerAddr, but applies
|
|
|
|
|
to addresses shared with directory authorities. (Default: 5)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>V3AuthVotingInterval</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
V3 authoritative directories only. Configures the server’s preferred voting
|
|
|
|
|
interval. Note that voting will <em>actually</em> happen at an interval chosen
|
|
|
|
|
by consensus from all the authorities' preferred intervals. This time
|
|
|
|
|
SHOULD divide evenly into a day. (Default: 1 hour)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>V3AuthVoteDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
V3 authoritative directories only. Configures the server’s preferred delay
|
|
|
|
|
between publishing its vote and assuming it has all the votes from all the
|
|
|
|
|
other authorities. Note that the actual time used is not the server’s
|
|
|
|
|
preferred time, but the consensus of all preferences. (Default: 5 minutes.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>V3AuthDistDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
V3 authoritative directories only. Configures the server’s preferred delay
|
|
|
|
|
between publishing its consensus and signature and assuming it has all the
|
|
|
|
|
signatures from all the other authorities. Note that the actual time used
|
|
|
|
|
is not the server’s preferred time, but the consensus of all preferences.
|
|
|
|
|
(Default: 5 minutes.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>V3AuthNIntervalsValid</strong> <em>NUM</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
V3 authoritative directories only. Configures the number of VotingIntervals
|
|
|
|
|
for which each consensus should be valid for. Choosing high numbers
|
|
|
|
|
increases network partitioning risks; choosing low numbers increases
|
|
|
|
|
directory traffic. Note that the actual number of intervals used is not the
|
|
|
|
|
server’s preferred number, but the consensus of all preferences. Must be at
|
|
|
|
|
least 2. (Default: 3.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_hidden_service_options">HIDDEN SERVICE OPTIONS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>The following options are used to configure a hidden service.</p></div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HiddenServiceDir</strong> <em>DIRECTORY</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Store data files for a hidden service in DIRECTORY. Every hidden service
|
|
|
|
|
must have a separate directory. You may use this option multiple times to
|
|
|
|
|
specify multiple services.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HiddenServicePort</strong> <em>VIRTPORT</em> [<em>TARGET</em>]
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Configure a virtual port VIRTPORT for a hidden service. You may use this
|
|
|
|
|
option multiple times; each time applies to the service using the most
|
|
|
|
|
recent hiddenservicedir. By default, this option maps the virtual port to
|
|
|
|
|
the same port on 127.0.0.1. You may override the target port, address, or
|
|
|
|
|
both by specifying a target of addr, port, or addr:port. You may also have
|
|
|
|
|
multiple lines with the same VIRTPORT: when a user connects to that
|
|
|
|
|
VIRTPORT, one of the TARGETs from those lines will be chosen at random.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>PublishHidServDescriptors</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 0, Tor will run any hidden services you configure, but it won’t
|
|
|
|
|
advertise them to the rendezvous directory. This option is only useful if
|
|
|
|
|
you’re using a Tor controller that handles hidserv publishing for you.
|
|
|
|
|
(Default: 1)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HiddenServiceVersion</strong> <em>version</em>,<em>version</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A list of rendezvous service descriptor versions to publish for the hidden
|
|
|
|
|
service. Currently, only version 2 is supported. (Default: 2)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>HiddenServiceAuthorizeClient</strong> <em>auth-type</em> <em>client-name</em>,<em>client-name</em>,<em>…</em>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If configured, the hidden service is accessible for authorized clients
|
|
|
|
|
only. The auth-type can either be 'basic' for a general-purpose
|
|
|
|
|
authorization protocol or 'stealth' for a less scalable protocol that also
|
|
|
|
|
hides service activity from unauthorized clients. Only clients that are
|
|
|
|
|
listed here are authorized to access the hidden service. Valid client names
|
|
|
|
|
are 1 to 19 characters long and only use characters in A-Za-z0-9+-_ (no
|
|
|
|
|
spaces). If this option is set, the hidden service is not accessible for
|
|
|
|
|
clients without authorization any more. Generated authorization data can be
|
|
|
|
|
found in the hostname file. Clients need to put this authorization data in
|
|
|
|
|
their configuration file using <strong>HidServAuth</strong>.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>RendPostPeriod</strong> <em>N</em> <strong>seconds</strong>|<strong>minutes</strong>|<strong>hours</strong>|<strong>days</strong>|<strong>weeks</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Every time the specified period elapses, Tor uploads any rendezvous
|
|
|
|
|
service descriptors to the directory servers. This information is also
|
|
|
|
|
uploaded whenever it changes. (Default: 1 hour)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_testing_network_options">TESTING NETWORK OPTIONS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>The following options are used for running a testing Tor network.</p></div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TestingTorNetwork</strong> <strong>0</strong>|<strong>1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If set to 1, Tor adjusts default values of the configuration options below,
|
|
|
|
|
so that it is easier to set up a testing Tor network. May only be set if
|
|
|
|
|
non-default set of DirServers is set. Cannot be unset while Tor is running.
|
|
|
|
|
(Default: 0)<br />
|
|
|
|
|
</p>
|
|
|
|
|
<div class="literalblock">
|
|
|
|
|
<div class="content">
|
|
|
|
|
<pre><tt>ServerDNSAllowBrokenConfig 1^M
|
|
|
|
|
DirAllowPrivateAddresses 1^M
|
|
|
|
|
EnforceDistinctSubnets 0^M
|
|
|
|
|
AssumeReachable 1^M
|
|
|
|
|
AuthDirMaxServersPerAddr 0^M
|
|
|
|
|
AuthDirMaxServersPerAuthAddr 0^M
|
|
|
|
|
ClientDNSRejectInternalAddresses 0^M
|
|
|
|
|
ExitPolicyRejectPrivate 0^M
|
|
|
|
|
V3AuthVotingInterval 5 minutes^M
|
|
|
|
|
V3AuthVoteDelay 20 seconds^M
|
|
|
|
|
V3AuthDistDelay 20 seconds^M
|
|
|
|
|
TestingV3AuthInitialVotingInterval 5 minutes^M
|
|
|
|
|
TestingV3AuthInitialVoteDelay 20 seconds^M
|
|
|
|
|
TestingV3AuthInitialDistDelay 20 seconds^M
|
|
|
|
|
TestingAuthDirTimeToLearnReachability 0 minutes^M
|
|
|
|
|
TestingEstimatedDescriptorPropagationTime 0 minutes</tt></pre>
|
|
|
|
|
</div></div>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TestingV3AuthInitialVotingInterval</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Like V3AuthVotingInterval, but for initial voting interval before the first
|
|
|
|
|
consensus has been created. Changing this requires that
|
|
|
|
|
<strong>TestingTorNetwork</strong> is set. (Default: 30 minutes)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TestingV3AuthInitialVoteDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Like TestingV3AuthInitialVoteDelay, but for initial voting interval before
|
|
|
|
|
the first consensus has been created. Changing this requires that
|
|
|
|
|
<strong>TestingTorNetwork</strong> is set. (Default: 5 minutes)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TestingV3AuthInitialDistDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Like TestingV3AuthInitialDistDelay, but for initial voting interval before
|
|
|
|
|
the first consensus has been created. Changing this requires that
|
|
|
|
|
<strong>TestingTorNetwork</strong> is set. (Default: 5 minutes)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TestingAuthDirTimeToLearnReachability</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
After starting as an authority, do not make claims about whether routers
|
|
|
|
|
are Running until this much time has passed. Changing this requires
|
|
|
|
|
that <strong>TestingTorNetwork</strong> is set. (Default: 30 minutes)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>TestingEstimatedDescriptorPropagationTime</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Clients try downloading router descriptors from directory caches after this
|
|
|
|
|
time. Changing this requires that <strong>TestingTorNetwork</strong> is set. (Default:
|
|
|
|
|
10 minutes)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_signals">SIGNALS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>Tor catches the following signals:</p></div>
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGTERM</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tor will catch this, clean up and sync to disk if necessary, and exit.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGINT</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tor clients behave as with SIGTERM; but Tor servers will do a controlled
|
|
|
|
|
slow shutdown, closing listeners and waiting 30 seconds before exiting.
|
|
|
|
|
(The delay can be configured with the ShutdownWaitLength config option.)
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGHUP</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The signal instructs Tor to reload its configuration (including closing and
|
|
|
|
|
reopening logs), and kill and restart its helper processes if applicable.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGUSR1</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Log statistics about current connections, past connections, and throughput.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGUSR2</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Switch all logs to loglevel debug. You can go back to the old loglevels by
|
|
|
|
|
sending a SIGHUP.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGCHLD</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tor receives this signal when one of its helper processes has exited, so it
|
|
|
|
|
can clean up.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGPIPE</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Tor catches this signal and ignores it.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>SIGXFSZ</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
If this signal exists on your platform, Tor catches and ignores it.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_files">FILES</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="dlist"><dl>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>@CONFDIR@/torrc</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The configuration file, which contains "option value" pairs.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<strong>@LOCALSTATEDIR@/lib/tor/</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The tor process stores keys and other data here.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/cached-status/</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The most recently downloaded network status document for each authority.
|
|
|
|
|
Each file holds one such document; the filenames are the hexadecimal
|
|
|
|
|
identity key fingerprints of the directory authorities.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/cached-descriptors</strong> and <strong>cached-descriptors.new</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
These files hold downloaded router statuses. Some routers may appear more
|
|
|
|
|
than once; if so, the most recently published descriptor is used. Lines
|
|
|
|
|
beginning with @-signs are annotations that contain more information about
|
|
|
|
|
a given router. The ".new" file is an append-only journal; when it gets
|
|
|
|
|
too large, all entries are merged into a new cached-descriptors file.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/cached-routers</strong> and <strong>cached-routers.new</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Obsolete versions of cached-descriptors and cached-descriptors.new. When
|
|
|
|
|
Tor can’t find the newer files, it looks here instead.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/state</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
A set of persistent key-value mappings. These are documented in
|
|
|
|
|
the file. These include:
|
|
|
|
|
</p>
|
|
|
|
|
<div class="ulist"><ul>
|
|
|
|
|
<li>
|
|
|
|
|
<p>
|
|
|
|
|
The current entry guards and their status.
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<p>
|
|
|
|
|
The current bandwidth accounting values (unused so far; see
|
|
|
|
|
below).
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<p>
|
|
|
|
|
When the file was last written
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<p>
|
|
|
|
|
What version of Tor generated the state file
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
<li>
|
|
|
|
|
<p>
|
|
|
|
|
A short history of bandwidth usage, as produced in the router
|
|
|
|
|
descriptors.
|
|
|
|
|
</p>
|
|
|
|
|
</li>
|
|
|
|
|
</ul></div>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/bw_accounting</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Used to track bandwidth accounting values (when the current period starts
|
|
|
|
|
and ends; how much has been read and written so far this period). This file
|
|
|
|
|
is obsolete, and the data is now stored in the 'state' file as well. Only
|
|
|
|
|
used when bandwidth accounting is enabled.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/control_auth_cookie</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Used for cookie authentication with the controller. Location can be
|
|
|
|
|
overridden by the CookieAuthFile config option. Regenerated on startup. See
|
|
|
|
|
control-spec.txt for details. Only used when cookie authentication is
|
|
|
|
|
enabled.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/keys/</strong>*
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Only used by servers. Holds identity keys and onion keys.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/fingerprint</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Only used by servers. Holds the fingerprint of the server’s identity key.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/approved-routers</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Only for naming authoritative directory servers (see
|
|
|
|
|
<strong>NamingAuthoritativeDirectory</strong>). This file lists nickname to identity
|
|
|
|
|
bindings. Each line lists a nickname and a fingerprint separated by
|
|
|
|
|
whitespace. See your <strong>fingerprint</strong> file in the <em>DataDirectory</em> for an
|
|
|
|
|
example line. If the nickname is <strong>!reject</strong> then descriptors from the
|
|
|
|
|
given identity (fingerprint) are rejected by this server. If it is
|
|
|
|
|
<strong>!invalid</strong> then descriptors are accepted but marked in the directory as
|
|
|
|
|
not valid, that is, not recommended.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>DataDirectory</em><strong>/router-stability</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Only used by authoritative directory servers. Tracks measurements for
|
|
|
|
|
router mean-time-between-failures so that authorities have a good idea of
|
|
|
|
|
how to set their Stable flags.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>HiddenServiceDirectory</em><strong>/hostname</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The <base32-encoded-fingerprint>.onion domain name for this hidden service.
|
|
|
|
|
If the hidden service is restricted to authorized clients only, this file
|
|
|
|
|
also contains authorization data for all clients.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>HiddenServiceDirectory</em><strong>/private_key</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
The private key for this hidden service.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
<dt class="hdlist1">
|
|
|
|
|
<em>HiddenServiceDirectory</em><strong>/client_keys</strong>
|
|
|
|
|
</dt>
|
|
|
|
|
<dd>
|
|
|
|
|
<p>
|
|
|
|
|
Authorization data for a hidden service that is only accessible by
|
|
|
|
|
authorized clients.
|
|
|
|
|
</p>
|
|
|
|
|
</dd>
|
|
|
|
|
</dl></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_see_also">SEE ALSO</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p><strong>privoxy</strong>(1), <strong>tsocks</strong>(1), <strong>torify</strong>(1)<br /></p></div>
|
|
|
|
|
<div class="paragraph"><p><strong>https://www.torproject.org/</strong></p></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_bugs">BUGS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>Plenty, probably. Tor is still in development. Please report them.</p></div>
|
|
|
|
|
</div>
|
|
|
|
|
<h2 id="_authors">AUTHORS</h2>
|
|
|
|
|
<div class="sectionbody">
|
|
|
|
|
<div class="paragraph"><p>Roger Dingledine [arma at mit.edu], Nick Mathewson [nickm at alum.mit.edu].</p></div>
|
|
|
|
|
</div>
|
|
|
|
|
</div>
|
2010-07-09 01:55:22 +00:00
|
|
|
<!-- END MAINCOL -->
|
2011-03-25 13:08:28 +00:00
|
|
|
<div id = "sidecol">
|
2010-07-09 01:55:22 +00:00
|
|
|
#include "side.wmi"
|
|
|
|
|
#include "info.wmi"
|
2011-03-25 13:08:28 +00:00
|
|
|
</div>
|
|
|
|
|
<!-- END SIDECOL -->
|
2010-07-09 01:55:22 +00:00
|
|
|
</div>
|
|
|
|
|
<!-- END CONTENT -->
|
2011-03-25 13:08:28 +00:00
|
|
|
#include <foot.wmi>
|
