...
|
...
|
@@ -9,22 +9,2321 @@
|
9
|
9
|
<div id="breadcrumbs">
|
10
|
10
|
<a href="<page index>">Home » </a>
|
11
|
11
|
<a href="<page docs/documentation>">Documentation » </a>
|
12
|
|
- <a href="<page docs/tor-doc-osx>">Tor Dev Manual</a>
|
13
|
|
- </div>
|
14
|
|
- <div id="maincol">
|
15
|
|
- <:
|
16
|
|
- die "Missing git clone at $(TORGIT)" unless -d "$(TORGIT)";
|
17
|
|
- my $man = `GIT_DIR=$(TORGIT) git show $(STABLETAG):doc/tor.1.txt | asciidoc -d manpage -s -o - -`;
|
18
|
|
- die "No manpage because of asciidoc error or file not available from git" unless $man;
|
19
|
|
- print $man;
|
20
|
|
- :>
|
|
12
|
+ <a href="<page docs/tor-doc-osx>">Tor Manual</a>
|
21
|
13
|
</div>
|
|
14
|
+ <div id="maincol">
|
|
15
|
+ <h2 id="_synopsis">SYNOPSIS</h2>
|
|
16
|
+ <div class="sectionbody">
|
|
17
|
+ <div class="paragraph"><p><strong>tor</strong> [<em>OPTION</em> <em>value</em>]…</p>
|
|
18
|
+ </div>
|
|
19
|
+ </div>
|
|
20
|
+ <h2 id="_description">DESCRIPTION</h2>
|
|
21
|
+ <div class="sectionbody">
|
|
22
|
+ <div class="paragraph"><p><em>tor</em> is a connection-oriented anonymizing communication
|
|
23
|
+ service. Users choose a source-routed path through a set of nodes, and
|
|
24
|
+ negotiate a "virtual circuit" through the network, in which each node
|
|
25
|
+ knows its predecessor and successor, but no others. Traffic flowing down
|
|
26
|
+ the circuit is unwrapped by a symmetric key at each node, which reveals
|
|
27
|
+ the downstream node.<br /></p></div>
|
|
28
|
+
|
|
29
|
+ <div class="paragraph"><p>Basically <em>tor</em> provides a distributed network of servers ("onion routers").
|
|
30
|
+ Users bounce their TCP streams — web traffic, ftp, ssh, etc — around the
|
|
31
|
+ routers, and recipients, observers, and even the routers themselves have
|
|
32
|
+ difficulty tracking the source of the stream.</p></div>
|
|
33
|
+ </div>
|
|
34
|
+ <h2 id="_options">OPTIONS</h2>
|
|
35
|
+ <div class="sectionbody">
|
|
36
|
+ <div class="dlist"><dl>
|
|
37
|
+ <dt class="hdlist1">
|
|
38
|
+ <strong>-h</strong>, <strong>-help</strong>
|
|
39
|
+ </dt>
|
|
40
|
+ <dd>
|
|
41
|
+ <p>
|
|
42
|
+ Display a short help message and exit.
|
|
43
|
+ </p>
|
|
44
|
+ </dd>
|
|
45
|
+ <dt class="hdlist1">
|
|
46
|
+ <strong>-f</strong> <em>FILE</em>
|
|
47
|
+ </dt>
|
|
48
|
+ <dd>
|
|
49
|
+ <p>
|
|
50
|
+ FILE contains further "option value" pairs. (Default: @CONFDIR@/torrc)
|
|
51
|
+ </p>
|
|
52
|
+ </dd>
|
|
53
|
+ <dt class="hdlist1">
|
|
54
|
+ <strong>--hash-password</strong>
|
|
55
|
+ </dt>
|
|
56
|
+ <dd>
|
|
57
|
+ <p>
|
|
58
|
+ Generates a hashed password for control port access.
|
|
59
|
+ </p>
|
|
60
|
+ </dd>
|
|
61
|
+ <dt class="hdlist1">
|
|
62
|
+ <strong>--list-fingerprint</strong>
|
|
63
|
+ </dt>
|
|
64
|
+ <dd>
|
|
65
|
+ <p>
|
|
66
|
+ Generate your keys and output your nickname and fingerprint.
|
|
67
|
+ </p>
|
|
68
|
+ </dd>
|
|
69
|
+ <dt class="hdlist1">
|
|
70
|
+ <strong>--verify-config</strong>
|
|
71
|
+ </dt>
|
|
72
|
+ <dd>
|
|
73
|
+ <p>
|
|
74
|
+ Verify the configuration file is valid.
|
|
75
|
+ </p>
|
|
76
|
+ </dd>
|
|
77
|
+ <dt class="hdlist1">
|
|
78
|
+ <strong>--nt-service</strong>
|
|
79
|
+ </dt>
|
|
80
|
+ <dd>
|
|
81
|
+ <p>
|
|
82
|
+ <strong>--service [install|remove|start|stop]</strong> Manage the Tor Windows
|
|
83
|
+ NT/2000/XP service. Current instructions can be found at
|
|
84
|
+ <a href="https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#WinNTService">https://wiki.torproject.org/noreply/TheOnionRouter/TorFAQ#WinNTService</a>
|
|
85
|
+ </p>
|
|
86
|
+ </dd>
|
|
87
|
+ <dt class="hdlist1">
|
|
88
|
+ <strong>--list-torrc-options</strong>
|
|
89
|
+ </dt>
|
|
90
|
+ <dd>
|
|
91
|
+ <p>
|
|
92
|
+ List all valid options.
|
|
93
|
+ </p>
|
|
94
|
+ </dd>
|
|
95
|
+ <dt class="hdlist1">
|
|
96
|
+ <strong>--version</strong>
|
|
97
|
+ </dt>
|
|
98
|
+ <dd>
|
|
99
|
+ <p>
|
|
100
|
+ Display Tor version and exit.
|
|
101
|
+ </p>
|
|
102
|
+ </dd>
|
|
103
|
+ <dt class="hdlist1">
|
|
104
|
+ <strong>--quiet</strong>
|
|
105
|
+ </dt>
|
|
106
|
+ <dd>
|
|
107
|
+ <p>
|
|
108
|
+ Do not start Tor with a console log unless explicitly requested to do so.
|
|
109
|
+ (By default, Tor starts out logging messages at level "notice" or higher to
|
|
110
|
+ the console, until it has parsed its configuration.)
|
|
111
|
+ </p>
|
|
112
|
+ </dd>
|
|
113
|
+ </dl>
|
|
114
|
+ </div>
|
|
115
|
+ <div class="paragraph">
|
|
116
|
+ <p>Other options can be specified either on the command-line (--option
|
|
117
|
+ value), or in the configuration file (option value or option "value").
|
|
118
|
+ Options are case-insensitive. C-style escaped characters are allowed inside
|
|
119
|
+ quoted values. Options on the command line take precedence over
|
|
120
|
+ options found in the configuration file, except indicated otherwise. To
|
|
121
|
+ split one configuration entry into multiple lines, use a single \ before
|
|
122
|
+ the end of the line. Comments can be used in such multiline entries, but
|
|
123
|
+ they must start at the beginning of a line.</p>
|
|
124
|
+ </div>
|
|
125
|
+ <div class="dlist"><dl>
|
|
126
|
+ <dt class="hdlist1">
|
|
127
|
+ <strong>BandwidthRate</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
128
|
+ </dt>
|
|
129
|
+ <dd>
|
|
130
|
+ <p>
|
|
131
|
+ A token bucket limits the average incoming bandwidth usage on this node to
|
|
132
|
+ the specified number of bytes per second, and the average outgoing
|
|
133
|
+ bandwidth usage to that same value. If you want to run a relay in the
|
|
134
|
+ public network, this needs to be <em>at the very least</em> 20 KB (that is,
|
|
135
|
+ 20480 bytes). (Default: 5 MB)
|
|
136
|
+ </p>
|
|
137
|
+ </dd>
|
|
138
|
+ <dt class="hdlist1">
|
|
139
|
+ <strong>BandwidthBurst</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
140
|
+ </dt>
|
|
141
|
+ <dd>
|
|
142
|
+ <p>
|
|
143
|
+ Limit the maximum token bucket size (also known as the burst) to the given
|
|
144
|
+ number of bytes in each direction. (Default: 10 MB)
|
|
145
|
+ </p>
|
|
146
|
+ </dd>
|
|
147
|
+ <dt class="hdlist1">
|
|
148
|
+ <strong>MaxAdvertisedBandwidth</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
149
|
+ </dt>
|
|
150
|
+ <dd>
|
|
151
|
+ <p>
|
|
152
|
+ If set, we will not advertise more than this amount of bandwidth for our
|
|
153
|
+ BandwidthRate. Server operators who want to reduce the number of clients
|
|
154
|
+ who ask to build circuits through them (since this is proportional to
|
|
155
|
+ advertised bandwidth rate) can thus reduce the CPU demands on their server
|
|
156
|
+ without impacting network performance.
|
|
157
|
+ </p>
|
|
158
|
+ </dd>
|
|
159
|
+ <dt class="hdlist1">
|
|
160
|
+ <strong>RelayBandwidthRate</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
161
|
+ </dt>
|
|
162
|
+ <dd>
|
|
163
|
+ <p>
|
|
164
|
+ If not 0, a separate token bucket limits the average incoming bandwidth
|
|
165
|
+ usage for _relayed traffic_ on this node to the specified number of bytes
|
|
166
|
+ per second, and the average outgoing bandwidth usage to that same value.
|
|
167
|
+ Relayed traffic currently is calculated to include answers to directory
|
|
168
|
+ requests, but that may change in future versions. (Default: 0)
|
|
169
|
+ </p>
|
|
170
|
+ </dd>
|
|
171
|
+ <dt class="hdlist1">
|
|
172
|
+ <strong>RelayBandwidthBurst</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>
|
|
173
|
+ </dt>
|
|
174
|
+ <dd>
|
|
175
|
+ <p>
|
|
176
|
+ If not 0, limit the maximum token bucket size (also known as the burst) for
|
|
177
|
+ _relayed traffic_ to the given number of bytes in each direction.
|
|
178
|
+ (Default: 0)
|
|
179
|
+ </p>
|
|
180
|
+ </dd>
|
|
181
|
+ <dt class="hdlist1">
|
|
182
|
+ <strong>ConnLimit</strong> <em>NUM</em>
|
|
183
|
+ </dt>
|
|
184
|
+ <dd>
|
|
185
|
+ <p>
|
|
186
|
+ The minimum number of file descriptors that must be available to the Tor
|
|
187
|
+ process before it will start. Tor will ask the OS for as many file
|
|
188
|
+ descriptors as the OS will allow (you can find this by "ulimit -H -n").
|
|
189
|
+ If this number is less than ConnLimit, then Tor will refuse to start.<br />
|
|
190
|
+ <br />
|
|
191
|
+ You probably don’t need to adjust this. It has no effect on Windows
|
|
192
|
+ since that platform lacks getrlimit(). (Default: 1000)
|
|
193
|
+ </p>
|
|
194
|
+ </dd>
|
|
195
|
+ <dt class="hdlist1">
|
|
196
|
+ <strong>ConstrainedSockets</strong> <strong>0</strong>|<strong>1</strong>
|
|
197
|
+ </dt>
|
|
198
|
+ <dd>
|
|
199
|
+ <p>
|
|
200
|
+ If set, Tor will tell the kernel to attempt to shrink the buffers for all
|
|
201
|
+ sockets to the size specified in <strong>ConstrainedSockSize</strong>. This is useful for
|
|
202
|
+ virtual servers and other environments where system level TCP buffers may
|
|
203
|
+ be limited. If you’re on a virtual server, and you encounter the "Error
|
|
204
|
+ creating network socket: No buffer space available" message, you are
|
|
205
|
+ likely experiencing this problem.<br />
|
|
206
|
+ <br />
|
|
207
|
+ The preferred solution is to have the admin increase the buffer pool for
|
|
208
|
+ the host itself via /proc/sys/net/ipv4/tcp_mem or equivalent facility;
|
|
209
|
+ this configuration option is a second-resort.<br />
|
|
210
|
+ <br />
|
|
211
|
+ The DirPort option should also not be used if TCP buffers are scarce. The
|
|
212
|
+ cached directory requests consume additional sockets which exacerbates
|
|
213
|
+ the problem.<br />
|
|
214
|
+ <br />
|
|
215
|
+ You should <strong>not</strong> enable this feature unless you encounter the "no buffer
|
|
216
|
+ space available" issue. Reducing the TCP buffers affects window size for
|
|
217
|
+ the TCP stream and will reduce throughput in proportion to round trip
|
|
218
|
+ time on long paths. (Default: 0.)
|
|
219
|
+ </p>
|
|
220
|
+ </dd>
|
|
221
|
+ <dt class="hdlist1">
|
|
222
|
+ <strong>ConstrainedSockSize</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>
|
|
223
|
+ </dt>
|
|
224
|
+ <dd>
|
|
225
|
+ <p>
|
|
226
|
+ When <strong>ConstrainedSockets</strong> is enabled the receive and transmit buffers for
|
|
227
|
+ all sockets will be set to this limit. Must be a value between 2048 and
|
|
228
|
+ 262144, in 1024 byte increments. Default of 8192 is recommended.
|
|
229
|
+ </p>
|
|
230
|
+ </dd>
|
|
231
|
+ <dt class="hdlist1">
|
|
232
|
+ <strong>ControlPort</strong> <em>Port</em>
|
|
233
|
+ </dt>
|
|
234
|
+ <dd>
|
|
235
|
+ <p>
|
|
236
|
+ If set, Tor will accept connections on this port and allow those
|
|
237
|
+ connections to control the Tor process using the Tor Control Protocol
|
|
238
|
+ (described in control-spec.txt). Note: unless you also specify one of
|
|
239
|
+ <strong>HashedControlPassword</strong> or <strong>CookieAuthentication</strong>, setting this option will
|
|
240
|
+ cause Tor to allow any process on the local host to control it. This
|
|
241
|
+ option is required for many Tor controllers; most use the value of 9051.
|
|
242
|
+ </p>
|
|
243
|
+ </dd>
|
|
244
|
+ <dt class="hdlist1">
|
|
245
|
+ <strong>ControlListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
246
|
+ </dt>
|
|
247
|
+ <dd>
|
|
248
|
+ <p>
|
|
249
|
+ Bind the controller listener to this address. If you specify a port, bind
|
|
250
|
+ to this port rather than the one specified in ControlPort. We strongly
|
|
251
|
+ recommend that you leave this alone unless you know what you’re doing,
|
|
252
|
+ since giving attackers access to your control listener is really
|
|
253
|
+ dangerous. (Default: 127.0.0.1) This directive can be specified multiple
|
|
254
|
+ times to bind to multiple addresses/ports.
|
|
255
|
+ </p>
|
|
256
|
+ </dd>
|
|
257
|
+ <dt class="hdlist1">
|
|
258
|
+ <strong>ControlSocket</strong> <em>Path</em>
|
|
259
|
+ </dt>
|
|
260
|
+ <dd>
|
|
261
|
+ <p>
|
|
262
|
+ Like ControlPort, but listens on a Unix domain socket, rather than a TCP
|
|
263
|
+ socket. (Unix and Unix-like systems only.)
|
|
264
|
+ </p>
|
|
265
|
+ </dd>
|
|
266
|
+ <dt class="hdlist1">
|
|
267
|
+ <strong>HashedControlPassword</strong> <em>hashed_password</em>
|
|
268
|
+ </dt>
|
|
269
|
+ <dd>
|
|
270
|
+ <p>
|
|
271
|
+ Don’t allow any connections on the control port except when the other
|
|
272
|
+ process knows the password whose one-way hash is <em>hashed_password</em>. You
|
|
273
|
+ can compute the hash of a password by running "tor --hash-password
|
|
274
|
+ <em>password</em>". You can provide several acceptable passwords by using more
|
|
275
|
+ than one HashedControlPassword line.
|
|
276
|
+ </p>
|
|
277
|
+ </dd>
|
|
278
|
+ <dt class="hdlist1">
|
|
279
|
+ <strong>CookieAuthentication</strong> <strong>0</strong>|<strong>1</strong>
|
|
280
|
+ </dt>
|
|
281
|
+ <dd>
|
|
282
|
+ <p>
|
|
283
|
+ If this option is set to 1, don’t allow any connections on the control port
|
|
284
|
+ except when the connecting process knows the contents of a file named
|
|
285
|
+ "control_auth_cookie", which Tor will create in its data directory. This
|
|
286
|
+ authentication method should only be used on systems with good filesystem
|
|
287
|
+ security. (Default: 0)
|
|
288
|
+ </p>
|
|
289
|
+ </dd>
|
|
290
|
+ <dt class="hdlist1">
|
|
291
|
+ <strong>CookieAuthFile</strong> <em>Path</em>
|
|
292
|
+ </dt>
|
|
293
|
+ <dd>
|
|
294
|
+ <p>
|
|
295
|
+ If set, this option overrides the default location and file name
|
|
296
|
+ for Tor’s cookie file. (See CookieAuthentication above.)
|
|
297
|
+ </p>
|
|
298
|
+ </dd>
|
|
299
|
+ <dt class="hdlist1">
|
|
300
|
+<strong>CookieAuthFileGroupReadable</strong> <strong>0</strong>|<strong>1</strong>|<em>Groupname</em>
|
|
301
|
+</dt>
|
|
302
|
+<dd>
|
|
303
|
+<p>
|
|
304
|
+ If this option is set to 0, don’t allow the filesystem group to read the
|
|
305
|
+ cookie file. If the option is set to 1, make the cookie file readable by
|
|
306
|
+ the default GID. [Making the file readable by other groups is not yet
|
|
307
|
+ implemented; let us know if you need this for some reason.] (Default: 0).
|
|
308
|
+</p>
|
|
309
|
+</dd>
|
|
310
|
+<dt class="hdlist1">
|
|
311
|
+<strong>DataDirectory</strong> <em>DIR</em>
|
|
312
|
+</dt>
|
|
313
|
+<dd>
|
|
314
|
+<p>
|
|
315
|
+ Store working data in DIR (Default: @LOCALSTATEDIR@/lib/tor)
|
|
316
|
+</p>
|
|
317
|
+</dd>
|
|
318
|
+<dt class="hdlist1">
|
|
319
|
+<strong>DirServer</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em>fingerprint</em>
|
|
320
|
+</dt>
|
|
321
|
+<dd>
|
|
322
|
+<p>
|
|
323
|
+ Use a nonstandard authoritative directory server at the provided address
|
|
324
|
+ and port, with the specified key fingerprint. This option can be repeated
|
|
325
|
+ many times, for multiple authoritative directory servers. Flags are
|
|
326
|
+ separated by spaces, and determine what kind of an authority this directory
|
|
327
|
+ is. By default, every authority is authoritative for current ("v2")-style
|
|
328
|
+ directories, unless the "no-v2" flag is given. If the "v1" flags is
|
|
329
|
+ provided, Tor will use this server as an authority for old-style (v1)
|
|
330
|
+ directories as well. (Only directory mirrors care about this.) Tor will
|
|
331
|
+ use this server as an authority for hidden service information if the "hs"
|
|
332
|
+ flag is set, or if the "v1" flag is set and the "no-hs" flag is <strong>not</strong> set.
|
|
333
|
+ Tor will use this authority as a bridge authoritative directory if the
|
|
334
|
+ "bridge" flag is set. If a flag "orport=<strong>port</strong>" is given, Tor will use the
|
|
335
|
+ given port when opening encrypted tunnels to the dirserver. Lastly, if a
|
|
336
|
+ flag "v3ident=<strong>fp</strong>" is given, the dirserver is a v3 directory authority
|
|
337
|
+ whose v3 long-term signing key has the fingerprint <strong>fp</strong>.<br />
|
|
338
|
+<br />
|
|
339
|
+ If no <strong>dirserver</strong> line is given, Tor will use the default directory
|
|
340
|
+ servers. NOTE: this option is intended for setting up a private Tor
|
|
341
|
+ network with its own directory authorities. If you use it, you will be
|
|
342
|
+ distinguishable from other users, because you won’t believe the same
|
|
343
|
+ authorities they do.
|
|
344
|
+</p>
|
|
345
|
+</dd>
|
|
346
|
+</dl></div>
|
|
347
|
+<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>
|
|
348
|
+<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>
|
|
349
|
+<div class="dlist"><dl>
|
|
350
|
+<dt class="hdlist1">
|
|
351
|
+<strong>AlternateBridgeAuthority</strong> [<em>nickname</em>] [<strong>flags</strong>] <em>address</em>:<em>port</em> <em> fingerprint</em>
|
|
352
|
+</dt>
|
|
353
|
+<dd>
|
|
354
|
+<p>
|
|
355
|
+ As DirServer, but replaces less of the default directory authorities. Using
|
|
356
|
+ AlternateDirAuthority replaces the default Tor directory authorities, but
|
|
357
|
+ leaves the hidden service authorities and bridge authorities in place.
|
|
358
|
+ Similarly, Using AlternateHSAuthority replaces the default hidden service
|
|
359
|
+ authorities, but not the directory or bridge authorities.
|
|
360
|
+</p>
|
|
361
|
+</dd>
|
|
362
|
+<dt class="hdlist1">
|
|
363
|
+<strong>FetchDirInfoEarly</strong> <strong>0</strong>|<strong>1</strong>
|
|
364
|
+</dt>
|
|
365
|
+<dd>
|
|
366
|
+<p>
|
|
367
|
+ If set to 1, Tor will always fetch directory information like other
|
|
368
|
+ directory caches, even if you don’t meet the normal criteria for fetching
|
|
369
|
+ early. Normal users should leave it off. (Default: 0)
|
|
370
|
+</p>
|
|
371
|
+</dd>
|
|
372
|
+<dt class="hdlist1">
|
|
373
|
+<strong>FetchHidServDescriptors</strong> <strong>0</strong>|<strong>1</strong>
|
|
374
|
+</dt>
|
|
375
|
+<dd>
|
|
376
|
+<p>
|
|
377
|
+ If set to 0, Tor will never fetch any hidden service descriptors from the
|
|
378
|
+ rendezvous directories. This option is only useful if you’re using a Tor
|
|
379
|
+ controller that handles hidden service fetches for you. (Default: 1)
|
|
380
|
+</p>
|
|
381
|
+</dd>
|
|
382
|
+<dt class="hdlist1">
|
|
383
|
+<strong>FetchServerDescriptors</strong> <strong>0</strong>|<strong>1</strong>
|
|
384
|
+</dt>
|
|
385
|
+<dd>
|
|
386
|
+<p>
|
|
387
|
+ If set to 0, Tor will never fetch any network status summaries or server
|
|
388
|
+ descriptors from the directory servers. This option is only useful if
|
|
389
|
+ you’re using a Tor controller that handles directory fetches for you.
|
|
390
|
+ (Default: 1)
|
|
391
|
+</p>
|
|
392
|
+</dd>
|
|
393
|
+<dt class="hdlist1">
|
|
394
|
+<strong>FetchUselessDescriptors</strong> <strong>0</strong>|<strong>1</strong>
|
|
395
|
+</dt>
|
|
396
|
+<dd>
|
|
397
|
+<p>
|
|
398
|
+ If set to 1, Tor will fetch every non-obsolete descriptor from the
|
|
399
|
+ authorities that it hears about. Otherwise, it will avoid fetching useless
|
|
400
|
+ descriptors, for example for routers that are not running. This option is
|
|
401
|
+ useful if you’re using the contributed "exitlist" script to enumerate Tor
|
|
402
|
+ nodes that exit to certain addresses. (Default: 0)
|
|
403
|
+</p>
|
|
404
|
+</dd>
|
|
405
|
+<dt class="hdlist1">
|
|
406
|
+<strong>HTTPProxy</strong> <em>host</em>[:<em>port</em>]
|
|
407
|
+</dt>
|
|
408
|
+<dd>
|
|
409
|
+<p>
|
|
410
|
+ Tor will make all its directory requests through this host:port (or host:80
|
|
411
|
+ if port is not specified), rather than connecting directly to any directory
|
|
412
|
+ servers.
|
|
413
|
+</p>
|
|
414
|
+</dd>
|
|
415
|
+<dt class="hdlist1">
|
|
416
|
+<strong>HTTPProxyAuthenticator</strong> <em>username:password</em>
|
|
417
|
+</dt>
|
|
418
|
+<dd>
|
|
419
|
+<p>
|
|
420
|
+ If defined, Tor will use this username:password for Basic HTTP proxy
|
|
421
|
+ authentication, as in RFC 2617. This is currently the only form of HTTP
|
|
422
|
+ proxy authentication that Tor supports; feel free to submit a patch if you
|
|
423
|
+ want it to support others.
|
|
424
|
+</p>
|
|
425
|
+</dd>
|
|
426
|
+<dt class="hdlist1">
|
|
427
|
+<strong>HTTPSProxy</strong> <em>host</em>[:<em>port</em>]
|
|
428
|
+</dt>
|
|
429
|
+<dd>
|
|
430
|
+<p>
|
|
431
|
+ Tor will make all its OR (SSL) connections through this host:port (or
|
|
432
|
+ host:443 if port is not specified), via HTTP CONNECT rather than connecting
|
|
433
|
+ directly to servers. You may want to set <strong>FascistFirewall</strong> to restrict
|
|
434
|
+ the set of ports you might try to connect to, if your HTTPS proxy only
|
|
435
|
+ allows connecting to certain ports.
|
|
436
|
+</p>
|
|
437
|
+</dd>
|
|
438
|
+<dt class="hdlist1">
|
|
439
|
+<strong>HTTPSProxyAuthenticator</strong> <em>username:password</em>
|
|
440
|
+</dt>
|
|
441
|
+<dd>
|
|
442
|
+<p>
|
|
443
|
+ If defined, Tor will use this username:password for Basic HTTPS proxy
|
|
444
|
+ authentication, as in RFC 2617. This is currently the only form of HTTPS
|
|
445
|
+ proxy authentication that Tor supports; feel free to submit a patch if you
|
|
446
|
+ want it to support others.
|
|
447
|
+</p>
|
|
448
|
+</dd>
|
|
449
|
+<dt class="hdlist1">
|
|
450
|
+<strong>KeepalivePeriod</strong> <em>NUM</em>
|
|
451
|
+</dt>
|
|
452
|
+<dd>
|
|
453
|
+<p>
|
|
454
|
+ To keep firewalls from expiring connections, send a padding keepalive cell
|
|
455
|
+ every NUM seconds on open connections that are in use. If the connection
|
|
456
|
+ has no open circuits, it will instead be closed after NUM seconds of
|
|
457
|
+ idleness. (Default: 5 minutes)
|
|
458
|
+</p>
|
|
459
|
+</dd>
|
|
460
|
+<dt class="hdlist1">
|
|
461
|
+<strong>Log</strong> <em>minSeverity</em>[-<em>maxSeverity</em>] <strong>stderr</strong>|<strong>stdout</strong>|<strong>syslog</strong>
|
|
462
|
+</dt>
|
|
463
|
+<dd>
|
|
464
|
+<p>
|
|
465
|
+ Send all messages between <em>minSeverity</em> and <em>maxSeverity</em> to the standard
|
|
466
|
+ output stream, the standard error stream, or to the system log. (The
|
|
467
|
+ "syslog" value is only supported on Unix.) Recognized severity levels are
|
|
468
|
+ debug, info, notice, warn, and err. We advise using "notice" in most cases,
|
|
469
|
+ since anything more verbose may provide sensitive information to an
|
|
470
|
+ attacker who obtains the logs. If only one severity level is given, all
|
|
471
|
+ messages of that level or higher will be sent to the listed destination.
|
|
472
|
+</p>
|
|
473
|
+</dd>
|
|
474
|
+<dt class="hdlist1">
|
|
475
|
+<strong>Log</strong> <em>minSeverity</em>[-<em>maxSeverity</em>] <strong>file</strong> <em>FILENAME</em>
|
|
476
|
+</dt>
|
|
477
|
+<dd>
|
|
478
|
+<p>
|
|
479
|
+ As above, but send log messages to the listed filename. The
|
|
480
|
+ "Log" option may appear more than once in a configuration file.
|
|
481
|
+ Messages are sent to all the logs that match their severity
|
|
482
|
+ level.
|
|
483
|
+</p>
|
|
484
|
+</dd>
|
|
485
|
+<dt class="hdlist1">
|
|
486
|
+<strong>OutboundBindAddress</strong> <em>IP</em>
|
|
487
|
+</dt>
|
|
488
|
+<dd>
|
|
489
|
+<p>
|
|
490
|
+ Make all outbound connections originate from the IP address specified. This
|
|
491
|
+ is only useful when you have multiple network interfaces, and you want all
|
|
492
|
+ of Tor’s outgoing connections to use a single one. This setting will be
|
|
493
|
+ ignored for connections to the loopback addresses (127.0.0.0/8 and ::1).
|
|
494
|
+</p>
|
|
495
|
+</dd>
|
|
496
|
+<dt class="hdlist1">
|
|
497
|
+<strong>PidFile</strong> <em>FILE</em>
|
|
498
|
+</dt>
|
|
499
|
+<dd>
|
|
500
|
+<p>
|
|
501
|
+ On startup, write our PID to FILE. On clean shutdown, remove
|
|
502
|
+ FILE.
|
|
503
|
+</p>
|
|
504
|
+</dd>
|
|
505
|
+<dt class="hdlist1">
|
|
506
|
+<strong>ProtocolWarnings</strong> <strong>0</strong>|<strong>1</strong>
|
|
507
|
+</dt>
|
|
508
|
+<dd>
|
|
509
|
+<p>
|
|
510
|
+ If 1, Tor will log with severity 'warn' various cases of other parties not
|
|
511
|
+ following the Tor specification. Otherwise, they are logged with severity
|
|
512
|
+ 'info'. (Default: 0)
|
|
513
|
+</p>
|
|
514
|
+</dd>
|
|
515
|
+<dt class="hdlist1">
|
|
516
|
+<strong>RunAsDaemon</strong> <strong>0</strong>|<strong>1</strong>
|
|
517
|
+</dt>
|
|
518
|
+<dd>
|
|
519
|
+<p>
|
|
520
|
+ If 1, Tor forks and daemonizes to the background. This option has no effect
|
|
521
|
+ on Windows; instead you should use the --service command-line option.
|
|
522
|
+ (Default: 0)
|
|
523
|
+</p>
|
|
524
|
+</dd>
|
|
525
|
+<dt class="hdlist1">
|
|
526
|
+<strong>SafeLogging</strong> <strong>0</strong>|<strong>1</strong>
|
|
527
|
+</dt>
|
|
528
|
+<dd>
|
|
529
|
+<p>
|
|
530
|
+ Tor can scrub potentially sensitive strings from log messages (e.g.
|
|
531
|
+ addresses) by replacing them with the string [scrubbed]. This way logs can
|
|
532
|
+ still be useful, but they don’t leave behind personally identifying
|
|
533
|
+ information about what sites a user might have visited.<br />
|
|
534
|
+<br />
|
|
535
|
+ If this option is set to 0, Tor will not perform any scrubbing, if it is
|
|
536
|
+ set to 1, all potentially sensitive strings are replaced. (Default: 1)
|
|
537
|
+</p>
|
|
538
|
+</dd>
|
|
539
|
+<dt class="hdlist1">
|
|
540
|
+<strong>User</strong> <em>UID</em>
|
|
541
|
+</dt>
|
|
542
|
+<dd>
|
|
543
|
+<p>
|
|
544
|
+ On startup, setuid to this user and setgid to their primary group.
|
|
545
|
+</p>
|
|
546
|
+</dd>
|
|
547
|
+<dt class="hdlist1">
|
|
548
|
+<strong>HardwareAccel</strong> <strong>0</strong>|<strong>1</strong>
|
|
549
|
+</dt>
|
|
550
|
+<dd>
|
|
551
|
+<p>
|
|
552
|
+ If non-zero, try to use built-in (static) crypto hardware acceleration when
|
|
553
|
+ available. This is untested and probably buggy. (Default: 0)
|
|
554
|
+</p>
|
|
555
|
+</dd>
|
|
556
|
+<dt class="hdlist1">
|
|
557
|
+<strong>AvoidDiskWrites</strong> <strong>0</strong>|<strong>1</strong>
|
|
558
|
+</dt>
|
|
559
|
+<dd>
|
|
560
|
+<p>
|
|
561
|
+ If non-zero, try to write to disk less frequently than we would otherwise.
|
|
562
|
+ This is useful when running on flash memory or other media that support
|
|
563
|
+ only a limited number of writes. (Default: 0)
|
|
564
|
+</p>
|
|
565
|
+</dd>
|
|
566
|
+<dt class="hdlist1">
|
|
567
|
+<strong>TunnelDirConns</strong> <strong>0</strong>|<strong>1</strong>
|
|
568
|
+</dt>
|
|
569
|
+<dd>
|
|
570
|
+<p>
|
|
571
|
+ If non-zero, when a directory server we contact supports it, we will build
|
|
572
|
+ a one-hop circuit and make an encrypted connection via its ORPort.
|
|
573
|
+ (Default: 1)
|
|
574
|
+</p>
|
|
575
|
+</dd>
|
|
576
|
+<dt class="hdlist1">
|
|
577
|
+<strong>PreferTunneledDirConns</strong> <strong>0</strong>|<strong>1</strong>
|
|
578
|
+</dt>
|
|
579
|
+<dd>
|
|
580
|
+<p>
|
|
581
|
+ If non-zero, we will avoid directory servers that don’t support tunneled
|
|
582
|
+ directory connections, when possible. (Default: 1)
|
|
583
|
+</p>
|
|
584
|
+</dd>
|
|
585
|
+</dl></div>
|
|
586
|
+</div>
|
|
587
|
+<h2 id="_client_options">CLIENT OPTIONS</h2>
|
|
588
|
+<div class="sectionbody">
|
|
589
|
+<div class="paragraph"><p>The following options are useful only for clients (that is, if
|
|
590
|
+<strong>SocksPort</strong> is non-zero):</p></div>
|
|
591
|
+<div class="dlist"><dl>
|
|
592
|
+<dt class="hdlist1">
|
|
593
|
+<strong>AllowInvalidNodes</strong> <strong>entry</strong>|<strong>exit</strong>|<strong>middle</strong>|<strong>introduction</strong>|<strong>rendezvous</strong>|<strong>…</strong>
|
|
594
|
+</dt>
|
|
595
|
+<dd>
|
|
596
|
+<p>
|
|
597
|
+ If some Tor servers are obviously not working right, the directory
|
|
598
|
+ authorities can manually mark them as invalid, meaning that it’s not
|
|
599
|
+ recommended you use them for entry or exit positions in your circuits. You
|
|
600
|
+ can opt to use them in some circuit positions, though. The default is
|
|
601
|
+ "middle,rendezvous", and other choices are not advised.
|
|
602
|
+</p>
|
|
603
|
+</dd>
|
|
604
|
+<dt class="hdlist1">
|
|
605
|
+<strong>ExcludeSingleHopRelays</strong> <strong>0</strong>|<strong>1</strong>
|
|
606
|
+</dt>
|
|
607
|
+<dd>
|
|
608
|
+<p>
|
|
609
|
+ This option controls whether circuits built by Tor will include relays with
|
|
610
|
+ the AllowSingleHopExits flag set to true. If ExcludeSingleHopRelays is set
|
|
611
|
+ to 0, these relays will be included. Note that these relays might be at
|
|
612
|
+ higher risk of being seized or observed, so they are not normally
|
|
613
|
+ included. Also note that relatively few clients turn off this option,
|
|
614
|
+ so using these relays might make your client stand out.
|
|
615
|
+ (Default: 1)
|
|
616
|
+</p>
|
|
617
|
+</dd>
|
|
618
|
+<dt class="hdlist1">
|
|
619
|
+<strong>Bridge</strong> <em>IP</em>:<em>ORPort</em> [fingerprint]
|
|
620
|
+</dt>
|
|
621
|
+<dd>
|
|
622
|
+<p>
|
|
623
|
+ When set along with UseBridges, instructs Tor to use the relay at
|
|
624
|
+ "IP:ORPort" as a "bridge" relaying into the Tor network. If "fingerprint"
|
|
625
|
+ is provided (using the same format as for DirServer), we will verify that
|
|
626
|
+ the relay running at that location has the right fingerprint. We also use
|
|
627
|
+ fingerprint to look up the bridge descriptor at the bridge authority, if
|
|
628
|
+ it’s provided and if UpdateBridgesFromAuthority is set too.
|
|
629
|
+</p>
|
|
630
|
+</dd>
|
|
631
|
+<dt class="hdlist1">
|
|
632
|
+<strong>CircuitBuildTimeout</strong> <em>NUM</em>
|
|
633
|
+</dt>
|
|
634
|
+<dd>
|
|
635
|
+<p>
|
|
636
|
+ Try for at most NUM seconds when building circuits. If the circuit isn't
|
|
637
|
+ open in that time, give up on it. (Default: 1 minute.)
|
|
638
|
+</p>
|
|
639
|
+</dd>
|
|
640
|
+<dt class="hdlist1">
|
|
641
|
+<strong>CircuitIdleTimeout</strong> <em>NUM</em>
|
|
642
|
+</dt>
|
|
643
|
+<dd>
|
|
644
|
+<p>
|
|
645
|
+ If we have kept a clean (never used) circuit around for NUM seconds, then
|
|
646
|
+ close it. This way when the Tor client is entirely idle, it can expire all
|
|
647
|
+ of its circuits, and then expire its TLS connections. Also, if we end up
|
|
648
|
+ making a circuit that is not useful for exiting any of the requests we’re
|
|
649
|
+ receiving, it won’t forever take up a slot in the circuit list. (Default: 1
|
|
650
|
+ hour.)
|
|
651
|
+</p>
|
|
652
|
+</dd>
|
|
653
|
+<dt class="hdlist1">
|
|
654
|
+<strong>ClientOnly</strong> <strong>0</strong>|<strong>1</strong>
|
|
655
|
+</dt>
|
|
656
|
+<dd>
|
|
657
|
+<p>
|
|
658
|
+ If set to 1, Tor will under no circumstances run as a server or serve
|
|
659
|
+ directory requests. The default is to run as a client unless ORPort is
|
|
660
|
+ configured. (Usually, you don’t need to set this; Tor is pretty smart at
|
|
661
|
+ figuring out whether you are reliable and high-bandwidth enough to be a
|
|
662
|
+ useful server.) (Default: 0)
|
|
663
|
+</p>
|
|
664
|
+</dd>
|
|
665
|
+<dt class="hdlist1">
|
|
666
|
+<strong>ExcludeNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
667
|
+</dt>
|
|
668
|
+<dd>
|
|
669
|
+<p>
|
|
670
|
+ A list of identity fingerprints, nicknames, country codes and address
|
|
671
|
+ patterns of nodes to never use when building a circuit. (Example:
|
|
672
|
+ ExcludeNodes SlowServer, $ EFFFFFFFFFFFFFFF, {cc}, 255.254.0.0/8)
|
|
673
|
+</p>
|
|
674
|
+</dd>
|
|
675
|
+<dt class="hdlist1">
|
|
676
|
+<strong>ExcludeExitNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
677
|
+</dt>
|
|
678
|
+<dd>
|
|
679
|
+<p>
|
|
680
|
+ A list of identity fingerprints, nicknames, country codes and address
|
|
681
|
+ patterns of nodes to never use when picking an exit node. Note that any
|
|
682
|
+ node listed in ExcludeNodes is automatically considered to be part of this
|
|
683
|
+ list.
|
|
684
|
+</p>
|
|
685
|
+</dd>
|
|
686
|
+<dt class="hdlist1">
|
|
687
|
+<strong>EntryNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
688
|
+</dt>
|
|
689
|
+<dd>
|
|
690
|
+<p>
|
|
691
|
+ A list of identity fingerprints, nicknames and address
|
|
692
|
+ patterns of nodes to use for the first hop in normal circuits. These are
|
|
693
|
+ treated only as preferences unless StrictNodes (see below) is also set.
|
|
694
|
+</p>
|
|
695
|
+</dd>
|
|
696
|
+<dt class="hdlist1">
|
|
697
|
+<strong>ExitNodes</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
698
|
+</dt>
|
|
699
|
+<dd>
|
|
700
|
+<p>
|
|
701
|
+ A list of identity fingerprints, nicknames, country codes and address
|
|
702
|
+ patterns of nodes to use for the last hop in normal exit circuits. These
|
|
703
|
+ are treated only as preferences unless StrictNodes (see below) is also set.
|
|
704
|
+</p>
|
|
705
|
+</dd>
|
|
706
|
+<dt class="hdlist1">
|
|
707
|
+<strong>StrictEntryNodes</strong> <strong>0</strong>|<strong>1</strong>
|
|
708
|
+</dt>
|
|
709
|
+<dd>
|
|
710
|
+<p>
|
|
711
|
+ If 1, Tor will never use any nodes besides those listed in "EntryNodes" for
|
|
712
|
+ the first hop of a circuit.
|
|
713
|
+</p>
|
|
714
|
+</dd>
|
|
715
|
+<dt class="hdlist1">
|
|
716
|
+<strong>StrictExitNodes</strong> <strong>0</strong>|<strong>1</strong>
|
|
717
|
+</dt>
|
|
718
|
+<dd>
|
|
719
|
+<p>
|
|
720
|
+ If 1, Tor will never use any nodes besides those listed in "ExitNodes" for
|
|
721
|
+ the last hop of a circuit.
|
|
722
|
+</p>
|
|
723
|
+</dd>
|
|
724
|
+<dt class="hdlist1">
|
|
725
|
+<strong>FascistFirewall</strong> <strong>0</strong>|<strong>1</strong>
|
|
726
|
+</dt>
|
|
727
|
+<dd>
|
|
728
|
+<p>
|
|
729
|
+ If 1, Tor will only create outgoing connections to ORs running on ports
|
|
730
|
+ that your firewall allows (defaults to 80 and 443; see <strong>FirewallPorts</strong>).
|
|
731
|
+ This will allow you to run Tor as a client behind a firewall with
|
|
732
|
+ restrictive policies, but will not allow you to run as a server behind such
|
|
733
|
+ a firewall. If you prefer more fine-grained control, use
|
|
734
|
+ ReachableAddresses instead.
|
|
735
|
+</p>
|
|
736
|
+</dd>
|
|
737
|
+<dt class="hdlist1">
|
|
738
|
+<strong>FirewallPorts</strong> <em>PORTS</em>
|
|
739
|
+</dt>
|
|
740
|
+<dd>
|
|
741
|
+<p>
|
|
742
|
+ A list of ports that your firewall allows you to connect to. Only used when
|
|
743
|
+ <strong>FascistFirewall</strong> is set. This option is deprecated; use ReachableAddresses
|
|
744
|
+ instead. (Default: 80, 443)
|
|
745
|
+</p>
|
|
746
|
+</dd>
|
|
747
|
+<dt class="hdlist1">
|
|
748
|
+<strong>HidServAuth</strong> <em>onion-address</em> <em>auth-cookie</em> [<em>service-name</em>]
|
|
749
|
+</dt>
|
|
750
|
+<dd>
|
|
751
|
+<p>
|
|
752
|
+ Client authorization for a hidden service. Valid onion addresses contain 16
|
|
753
|
+ characters in a-z2-7 plus ".onion", and valid auth cookies contain 22
|
|
754
|
+ characters in A-Za-z0-9+/. The service name is only used for internal
|
|
755
|
+ purposes, e.g., for Tor controllers. This option may be used multiple times
|
|
756
|
+ for different hidden services. If a hidden service uses authorization and
|
|
757
|
+ this option is not set, the hidden service is not accessible. Hidden
|
|
758
|
+ services can be configured to require authorization using the
|
|
759
|
+ <strong>HiddenServiceAuthorizeClient</strong> option.
|
|
760
|
+</p>
|
|
761
|
+</dd>
|
|
762
|
+<dt class="hdlist1">
|
|
763
|
+<strong>ReachableAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]…
|
|
764
|
+</dt>
|
|
765
|
+<dd>
|
|
766
|
+<p>
|
|
767
|
+ A comma-separated list of IP addresses and ports that your firewall allows
|
|
768
|
+ you to connect to. The format is as for the addresses in ExitPolicy, except
|
|
769
|
+ that "accept" is understood unless "reject" is explicitly provided. For
|
|
770
|
+ example, 'ReachableAddresses 99.0.0.0/8, reject 18.0.0.0/8:80, accept
|
|
771
|
+ *:80' means that your firewall allows connections to everything inside net
|
|
772
|
+ 99, rejects port 80 connections to net 18, and accepts connections to port
|
|
773
|
+ 80 otherwise. (Default: 'accept *:*'.)
|
|
774
|
+</p>
|
|
775
|
+</dd>
|
|
776
|
+<dt class="hdlist1">
|
|
777
|
+<strong>ReachableDirAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]…
|
|
778
|
+</dt>
|
|
779
|
+<dd>
|
|
780
|
+<p>
|
|
781
|
+ Like <strong>ReachableAddresses</strong>, a list of addresses and ports. Tor will obey
|
|
782
|
+ these restrictions when fetching directory information, using standard HTTP
|
|
783
|
+ GET requests. If not set explicitly then the value of
|
|
784
|
+ <strong>ReachableAddresses</strong> is used. If <strong>HTTPProxy</strong> is set then these
|
|
785
|
+ connections will go through that proxy.
|
|
786
|
+</p>
|
|
787
|
+</dd>
|
|
788
|
+<dt class="hdlist1">
|
|
789
|
+<strong>ReachableORAddresses</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]…
|
|
790
|
+</dt>
|
|
791
|
+<dd>
|
|
792
|
+<p>
|
|
793
|
+ Like <strong>ReachableAddresses</strong>, a list of addresses and ports. Tor will obey
|
|
794
|
+ these restrictions when connecting to Onion Routers, using TLS/SSL. If not
|
|
795
|
+ set explicitly then the value of <strong>ReachableAddresses</strong> is used. If
|
|
796
|
+ <strong>HTTPSProxy</strong> is set then these connections will go through that proxy.<br />
|
|
797
|
+<br />
|
|
798
|
+ The separation between <strong>ReachableORAddresses</strong> and
|
|
799
|
+ <strong>ReachableDirAddresses</strong> is only interesting when you are connecting
|
|
800
|
+ through proxies (see <strong>HTTPProxy</strong> and <strong>HTTPSProxy</strong>). Most proxies limit
|
|
801
|
+ TLS connections (which Tor uses to connect to Onion Routers) to port 443,
|
|
802
|
+ and some limit HTTP GET requests (which Tor uses for fetching directory
|
|
803
|
+ information) to port 80.
|
|
804
|
+</p>
|
|
805
|
+</dd>
|
|
806
|
+<dt class="hdlist1">
|
|
807
|
+<strong>LongLivedPorts</strong> <em>PORTS</em>
|
|
808
|
+</dt>
|
|
809
|
+<dd>
|
|
810
|
+<p>
|
|
811
|
+ A list of ports for services that tend to have long-running connections
|
|
812
|
+ (e.g. chat and interactive shells). Circuits for streams that use these
|
|
813
|
+ ports will contain only high-uptime nodes, to reduce the chance that a node
|
|
814
|
+ will go down before the stream is finished. (Default: 21, 22, 706, 1863,
|
|
815
|
+ 5050, 5190, 5222, 5223, 6667, 6697, 8300)
|
|
816
|
+</p>
|
|
817
|
+</dd>
|
|
818
|
+<dt class="hdlist1">
|
|
819
|
+<strong>MapAddress</strong> <em>address</em> <em>newaddress</em>
|
|
820
|
+</dt>
|
|
821
|
+<dd>
|
|
822
|
+<p>
|
|
823
|
+ When a request for address arrives to Tor, it will rewrite it to newaddress
|
|
824
|
+ before processing it. For example, if you always want connections to
|
|
825
|
+ www.indymedia.org to exit via <em>torserver</em> (where <em>torserver</em> is the
|
|
826
|
+ nickname of the server), use "MapAddress www.indymedia.org
|
|
827
|
+ www.indymedia.org.torserver.exit".
|
|
828
|
+</p>
|
|
829
|
+</dd>
|
|
830
|
+<dt class="hdlist1">
|
|
831
|
+<strong>NewCircuitPeriod</strong> <em>NUM</em>
|
|
832
|
+</dt>
|
|
833
|
+<dd>
|
|
834
|
+<p>
|
|
835
|
+ Every NUM seconds consider whether to build a new circuit. (Default: 30
|
|
836
|
+ seconds)
|
|
837
|
+</p>
|
|
838
|
+</dd>
|
|
839
|
+<dt class="hdlist1">
|
|
840
|
+<strong>MaxCircuitDirtiness</strong> <em>NUM</em>
|
|
841
|
+</dt>
|
|
842
|
+<dd>
|
|
843
|
+<p>
|
|
844
|
+ Feel free to reuse a circuit that was first used at most NUM seconds ago,
|
|
845
|
+ but never attach a new stream to a circuit that is too old. (Default: 10
|
|
846
|
+ minutes)
|
|
847
|
+</p>
|
|
848
|
+</dd>
|
|
849
|
+<dt class="hdlist1">
|
|
850
|
+<strong>NodeFamily</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
851
|
+</dt>
|
|
852
|
+<dd>
|
|
853
|
+<p>
|
|
854
|
+ The Tor servers, defined by their identity fingerprints or nicknames,
|
|
855
|
+ constitute a "family" of similar or co-administered servers, so never use
|
|
856
|
+ any two of them in the same circuit. Defining a NodeFamily is only needed
|
|
857
|
+ when a server doesn’t list the family itself (with MyFamily). This option
|
|
858
|
+ can be used multiple times.
|
|
859
|
+</p>
|
|
860
|
+</dd>
|
|
861
|
+<dt class="hdlist1">
|
|
862
|
+<strong>EnforceDistinctSubnets</strong> <strong>0</strong>|<strong>1</strong>
|
|
863
|
+</dt>
|
|
864
|
+<dd>
|
|
865
|
+<p>
|
|
866
|
+ If 1, Tor will not put two servers whose IP addresses are "too close" on
|
|
867
|
+ the same circuit. Currently, two addresses are "too close" if they lie in
|
|
868
|
+ the same /16 range. (Default: 1)
|
|
869
|
+</p>
|
|
870
|
+</dd>
|
|
871
|
+<dt class="hdlist1">
|
|
872
|
+<strong>SocksPort</strong> <em>PORT</em>
|
|
873
|
+</dt>
|
|
874
|
+<dd>
|
|
875
|
+<p>
|
|
876
|
+ Advertise this port to listen for connections from Socks-speaking
|
|
877
|
+ applications. Set this to 0 if you don’t want to allow application
|
|
878
|
+ connections. (Default: 9050)
|
|
879
|
+</p>
|
|
880
|
+</dd>
|
|
881
|
+<dt class="hdlist1">
|
|
882
|
+<strong>SocksListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
883
|
+</dt>
|
|
884
|
+<dd>
|
|
885
|
+<p>
|
|
886
|
+ Bind to this address to listen for connections from Socks-speaking
|
|
887
|
+ applications. (Default: 127.0.0.1) You can also specify a port (e.g.
|
|
888
|
+ 192.168.0.1:9100). This directive can be specified multiple times to bind
|
|
889
|
+ to multiple addresses/ports.
|
|
890
|
+</p>
|
|
891
|
+</dd>
|
|
892
|
+<dt class="hdlist1">
|
|
893
|
+<strong>SocksPolicy</strong> <em>policy</em>,<em>policy</em>,<em>…</em>
|
|
894
|
+</dt>
|
|
895
|
+<dd>
|
|
896
|
+<p>
|
|
897
|
+ Set an entrance policy for this server, to limit who can connect to the
|
|
898
|
+ SocksPort and DNSPort ports. The policies have the same form as exit
|
|
899
|
+ policies below.
|
|
900
|
+</p>
|
|
901
|
+</dd>
|
|
902
|
+<dt class="hdlist1">
|
|
903
|
+<strong>SocksTimeout</strong> <em>NUM</em>
|
|
904
|
+</dt>
|
|
905
|
+<dd>
|
|
906
|
+<p>
|
|
907
|
+ Let a socks connection wait NUM seconds handshaking, and NUM seconds
|
|
908
|
+ unattached waiting for an appropriate circuit, before we fail it. (Default:
|
|
909
|
+ 2 minutes.)
|
|
910
|
+</p>
|
|
911
|
+</dd>
|
|
912
|
+<dt class="hdlist1">
|
|
913
|
+<strong>TrackHostExits</strong> <em>host</em>,<em>.domain</em>,<em>…</em>
|
|
914
|
+</dt>
|
|
915
|
+<dd>
|
|
916
|
+<p>
|
|
917
|
+ For each value in the comma separated list, Tor will track recent
|
|
918
|
+ connections to hosts that match this value and attempt to reuse the same
|
|
919
|
+ exit node for each. If the value is prepended with a '.', it is treated as
|
|
920
|
+ matching an entire domain. If one of the values is just a '.', it means
|
|
921
|
+ match everything. This option is useful if you frequently connect to sites
|
|
922
|
+ that will expire all your authentication cookies (i.e. log you out) if
|
|
923
|
+ your IP address changes. Note that this option does have the disadvantage
|
|
924
|
+ of making it more clear that a given history is associated with a single
|
|
925
|
+ user. However, most people who would wish to observe this will observe it
|
|
926
|
+ through cookies or other protocol-specific means anyhow.
|
|
927
|
+</p>
|
|
928
|
+</dd>
|
|
929
|
+<dt class="hdlist1">
|
|
930
|
+<strong>TrackHostExitsExpire</strong> <em>NUM</em>
|
|
931
|
+</dt>
|
|
932
|
+<dd>
|
|
933
|
+<p>
|
|
934
|
+ Since exit servers go up and down, it is desirable to expire the
|
|
935
|
+ association between host and exit server after NUM seconds. The default is
|
|
936
|
+ 1800 seconds (30 minutes).
|
|
937
|
+</p>
|
|
938
|
+</dd>
|
|
939
|
+<dt class="hdlist1">
|
|
940
|
+<strong>UpdateBridgesFromAuthority</strong> <strong>0</strong>|<strong>1</strong>
|
|
941
|
+</dt>
|
|
942
|
+<dd>
|
|
943
|
+<p>
|
|
944
|
+ When set (along with UseBridges), Tor will try to fetch bridge descriptors
|
|
945
|
+ from the configured bridge authorities when feasible. It will fall back to
|
|
946
|
+ a direct request if the authority responds with a 404. (Default: 0)
|
|
947
|
+</p>
|
|
948
|
+</dd>
|
|
949
|
+<dt class="hdlist1">
|
|
950
|
+<strong>UseBridges</strong> <strong>0</strong>|<strong>1</strong>
|
|
951
|
+</dt>
|
|
952
|
+<dd>
|
|
953
|
+<p>
|
|
954
|
+ When set, Tor will fetch descriptors for each bridge listed in the "Bridge"
|
|
955
|
+ config lines, and use these relays as both entry guards and directory
|
|
956
|
+ guards. (Default: 0)
|
|
957
|
+</p>
|
|
958
|
+</dd>
|
|
959
|
+<dt class="hdlist1">
|
|
960
|
+<strong>UseEntryGuards</strong> <strong>0</strong>|<strong>1</strong>
|
|
961
|
+</dt>
|
|
962
|
+<dd>
|
|
963
|
+<p>
|
|
964
|
+ If this option is set to 1, we pick a few long-term entry servers, and try
|
|
965
|
+ to stick with them. This is desirable because constantly changing servers
|
|
966
|
+ increases the odds that an adversary who owns some servers will observe a
|
|
967
|
+ fraction of your paths. (Defaults to 1.)
|
|
968
|
+</p>
|
|
969
|
+</dd>
|
|
970
|
+<dt class="hdlist1">
|
|
971
|
+<strong>NumEntryGuards</strong> <em>NUM</em>
|
|
972
|
+</dt>
|
|
973
|
+<dd>
|
|
974
|
+<p>
|
|
975
|
+ If UseEntryGuards is set to 1, we will try to pick a total of NUM routers
|
|
976
|
+ as long-term entries for our circuits. (Defaults to 3.)
|
|
977
|
+</p>
|
|
978
|
+</dd>
|
|
979
|
+<dt class="hdlist1">
|
|
980
|
+<strong>SafeSocks</strong> <strong>0</strong>|<strong>1</strong>
|
|
981
|
+</dt>
|
|
982
|
+<dd>
|
|
983
|
+<p>
|
|
984
|
+ When this option is enabled, Tor will reject application connections that
|
|
985
|
+ use unsafe variants of the socks protocol — ones that only provide an IP
|
|
986
|
+ address, meaning the application is doing a DNS resolve first.
|
|
987
|
+ Specifically, these are socks4 and socks5 when not doing remote DNS.
|
|
988
|
+ (Defaults to 0.)
|
|
989
|
+</p>
|
|
990
|
+</dd>
|
|
991
|
+<dt class="hdlist1">
|
|
992
|
+<strong>TestSocks</strong> <strong>0</strong>|<strong>1</strong>
|
|
993
|
+</dt>
|
|
994
|
+<dd>
|
|
995
|
+<p>
|
|
996
|
+ When this option is enabled, Tor will make a notice-level log entry for
|
|
997
|
+ each connection to the Socks port indicating whether the request used a
|
|
998
|
+ safe socks protocol or an unsafe one (see above entry on SafeSocks). This
|
|
999
|
+ helps to determine whether an application using Tor is possibly leaking
|
|
1000
|
+ DNS requests. (Default: 0)
|
|
1001
|
+</p>
|
|
1002
|
+</dd>
|
|
1003
|
+<dt class="hdlist1">
|
|
1004
|
+<strong>VirtualAddrNetwork</strong> <em>Address</em>/<em>bits</em>
|
|
1005
|
+</dt>
|
|
1006
|
+<dd>
|
|
1007
|
+<p>
|
|
1008
|
+ When Tor needs to assign a virtual (unused) address because of a MAPADDRESS
|
|
1009
|
+ command from the controller or the AutomapHostsOnResolve feature, Tor
|
|
1010
|
+ picks an unassigned address from this range. (Default:
|
|
1011
|
+ 127.192.0.0/10)<br />
|
|
1012
|
+<br />
|
|
1013
|
+ When providing proxy server service to a network of computers using a tool
|
|
1014
|
+ like dns-proxy-tor, change this address to "10.192.0.0/10" or
|
|
1015
|
+ "172.16.0.0/12". The default <strong>VirtualAddrNetwork</strong> address range on a
|
|
1016
|
+ properly configured machine will route to the loopback interface. For
|
|
1017
|
+ local use, no change to the default VirtualAddrNetwork setting is needed.
|
|
1018
|
+</p>
|
|
1019
|
+</dd>
|
|
1020
|
+<dt class="hdlist1">
|
|
1021
|
+<strong>AllowNonRFC953Hostnames</strong> <strong>0</strong>|<strong>1</strong>
|
|
1022
|
+</dt>
|
|
1023
|
+<dd>
|
|
1024
|
+<p>
|
|
1025
|
+ When this option is disabled, Tor blocks hostnames containing illegal
|
|
1026
|
+ characters (like @ and :) rather than sending them to an exit node to be
|
|
1027
|
+ resolved. This helps trap accidental attempts to resolve URLs and so on.
|
|
1028
|
+ (Default: 0)
|
|
1029
|
+</p>
|
|
1030
|
+</dd>
|
|
1031
|
+<dt class="hdlist1">
|
|
1032
|
+<strong>FastFirstHopPK</strong> <strong>0</strong>|<strong>1</strong>
|
|
1033
|
+</dt>
|
|
1034
|
+<dd>
|
|
1035
|
+<p>
|
|
1036
|
+ When this option is disabled, Tor uses the public key step for the first
|
|
1037
|
+ hop of creating circuits. Skipping it is generally safe since we have
|
|
1038
|
+ already used TLS to authenticate the relay and to establish forward-secure
|
|
1039
|
+ keys. Turning this option off makes circuit building slower.<br />
|
|
1040
|
+<br />
|
|
1041
|
+ Note that Tor will always use the public key step for the first hop if it’s
|
|
1042
|
+ operating as a relay, and it will never use the public key step if it
|
|
1043
|
+ doesn’t yet know the onion key of the first hop. (Default: 1)
|
|
1044
|
+</p>
|
|
1045
|
+</dd>
|
|
1046
|
+<dt class="hdlist1">
|
|
1047
|
+<strong>TransPort</strong> <em>PORT</em>
|
|
1048
|
+</dt>
|
|
1049
|
+<dd>
|
|
1050
|
+<p>
|
|
1051
|
+ If non-zero, enables transparent proxy support on <em>PORT</em> (by convention,
|
|
1052
|
+ 9040). Requires OS support for transparent proxies, such as BSDs' pf or
|
|
1053
|
+ Linux’s IPTables. If you’re planning to use Tor as a transparent proxy for
|
|
1054
|
+ a network, you’ll want to examine and change VirtualAddrNetwork from the
|
|
1055
|
+ default setting. You’ll also want to set the TransListenAddress option for
|
|
1056
|
+ the network you’d like to proxy. (Default: 0).
|
|
1057
|
+</p>
|
|
1058
|
+</dd>
|
|
1059
|
+<dt class="hdlist1">
|
|
1060
|
+<strong>TransListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
1061
|
+</dt>
|
|
1062
|
+<dd>
|
|
1063
|
+<p>
|
|
1064
|
+ Bind to this address to listen for transparent proxy connections. (Default:
|
|
1065
|
+ 127.0.0.1). This is useful for exporting a transparent proxy server to an
|
|
1066
|
+ entire network.
|
|
1067
|
+</p>
|
|
1068
|
+</dd>
|
|
1069
|
+<dt class="hdlist1">
|
|
1070
|
+<strong>NATDPort</strong> <em>PORT</em>
|
|
1071
|
+</dt>
|
|
1072
|
+<dd>
|
|
1073
|
+<p>
|
|
1074
|
+ Allow old versions of ipfw (as included in old versions of FreeBSD, etc.)
|
|
1075
|
+ to send connections through Tor using the NATD protocol. This option is
|
|
1076
|
+ only for people who cannot use TransPort.
|
|
1077
|
+</p>
|
|
1078
|
+</dd>
|
|
1079
|
+<dt class="hdlist1">
|
|
1080
|
+<strong>NATDListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
1081
|
+</dt>
|
|
1082
|
+<dd>
|
|
1083
|
+<p>
|
|
1084
|
+ Bind to this address to listen for NATD connections. (Default: 127.0.0.1).
|
|
1085
|
+</p>
|
|
1086
|
+</dd>
|
|
1087
|
+<dt class="hdlist1">
|
|
1088
|
+<strong>AutomapHostsOnResolve</strong> <strong>0</strong>|<strong>1</strong>
|
|
1089
|
+</dt>
|
|
1090
|
+<dd>
|
|
1091
|
+<p>
|
|
1092
|
+ When this option is enabled, and we get a request to resolve an address
|
|
1093
|
+ that ends with one of the suffixes in <strong>AutomapHostsSuffixes</strong>, we map an
|
|
1094
|
+ unused virtual address to that address, and return the new virtual address.
|
|
1095
|
+ This is handy for making ".onion" addresses work with applications that
|
|
1096
|
+ resolve an address and then connect to it. (Default: 0).
|
|
1097
|
+</p>
|
|
1098
|
+</dd>
|
|
1099
|
+<dt class="hdlist1">
|
|
1100
|
+<strong>AutomapHostsSuffixes</strong> <em>SUFFIX</em>,<em>SUFFIX</em>,<em>…</em>
|
|
1101
|
+</dt>
|
|
1102
|
+<dd>
|
|
1103
|
+<p>
|
|
1104
|
+ A comma-separated list of suffixes to use with <strong>AutomapHostsOnResolve</strong>.
|
|
1105
|
+ The "." suffix is equivalent to "all addresses." (Default: .exit,.onion).
|
|
1106
|
+</p>
|
|
1107
|
+</dd>
|
|
1108
|
+<dt class="hdlist1">
|
|
1109
|
+<strong>DNSPort</strong> <em>PORT</em>
|
|
1110
|
+</dt>
|
|
1111
|
+<dd>
|
|
1112
|
+<p>
|
|
1113
|
+ If non-zero, Tor listens for UDP DNS requests on this port and resolves
|
|
1114
|
+ them anonymously. (Default: 0).
|
|
1115
|
+</p>
|
|
1116
|
+</dd>
|
|
1117
|
+<dt class="hdlist1">
|
|
1118
|
+<strong>DNSListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
1119
|
+</dt>
|
|
1120
|
+<dd>
|
|
1121
|
+<p>
|
|
1122
|
+ Bind to this address to listen for DNS connections. (Default: 127.0.0.1).
|
|
1123
|
+</p>
|
|
1124
|
+</dd>
|
|
1125
|
+<dt class="hdlist1">
|
|
1126
|
+<strong>ClientDNSRejectInternalAddresses</strong> <strong>0</strong>|<strong>1</strong>
|
|
1127
|
+</dt>
|
|
1128
|
+<dd>
|
|
1129
|
+<p>
|
|
1130
|
+ If true, Tor does not believe any anonymously retrieved DNS answer that
|
|
1131
|
+ tells it that an address resolves to an internal address (like 127.0.0.1 or
|
|
1132
|
+ 192.168.0.1). This option prevents certain browser-based attacks; don’t
|
|
1133
|
+ turn it off unless you know what you’re doing. (Default: 1).
|
|
1134
|
+</p>
|
|
1135
|
+</dd>
|
|
1136
|
+<dt class="hdlist1">
|
|
1137
|
+<strong>DownloadExtraInfo</strong> <strong>0</strong>|<strong>1</strong>
|
|
1138
|
+</dt>
|
|
1139
|
+<dd>
|
|
1140
|
+<p>
|
|
1141
|
+ If true, Tor downloads and caches "extra-info" documents. These documents
|
|
1142
|
+ contain information about servers other than the information in their
|
|
1143
|
+ regular router descriptors. Tor does not use this information for anything
|
|
1144
|
+ itself; to save bandwidth, leave this option turned off. (Default: 0).
|
|
1145
|
+</p>
|
|
1146
|
+</dd>
|
|
1147
|
+<dt class="hdlist1">
|
|
1148
|
+<strong>FallbackNetworkstatusFile</strong> <em>FILENAME</em>
|
|
1149
|
+</dt>
|
|
1150
|
+<dd>
|
|
1151
|
+<p>
|
|
1152
|
+ If Tor doesn’t have a cached networkstatus file, it starts out using this
|
|
1153
|
+ one instead. Even if this file is out of date, Tor can still use it to
|
|
1154
|
+ learn about directory mirrors, so it doesn’t need to put load on the
|
|
1155
|
+ authorities. (Default: None).
|
|
1156
|
+</p>
|
|
1157
|
+</dd>
|
|
1158
|
+<dt class="hdlist1">
|
|
1159
|
+<strong>WarnPlaintextPorts</strong> <em>port</em>,<em>port</em>,<em>…</em>
|
|
1160
|
+</dt>
|
|
1161
|
+<dd>
|
|
1162
|
+<p>
|
|
1163
|
+ Tells Tor to issue a warnings whenever the user tries to make an anonymous
|
|
1164
|
+ connection to one of these ports. This option is designed to alert users
|
|
1165
|
+ to services that risk sending passwords in the clear. (Default:
|
|
1166
|
+ 23,109,110,143).
|
|
1167
|
+</p>
|
|
1168
|
+</dd>
|
|
1169
|
+<dt class="hdlist1">
|
|
1170
|
+<strong>RejectPlaintextPorts</strong> <em>port</em>,<em>port</em>,<em>…</em>
|
|
1171
|
+</dt>
|
|
1172
|
+<dd>
|
|
1173
|
+<p>
|
|
1174
|
+ Like WarnPlaintextPorts, but instead of warning about risky port uses, Tor
|
|
1175
|
+ will instead refuse to make the connection. (Default: None).
|
|
1176
|
+</p>
|
|
1177
|
+</dd>
|
|
1178
|
+</dl></div>
|
|
1179
|
+</div>
|
|
1180
|
+<h2 id="_server_options">SERVER OPTIONS</h2>
|
|
1181
|
+<div class="sectionbody">
|
|
1182
|
+<div class="paragraph"><p>The following options are useful only for servers (that is, if ORPort
|
|
1183
|
+is non-zero):</p></div>
|
|
1184
|
+<div class="dlist"><dl>
|
|
1185
|
+<dt class="hdlist1">
|
|
1186
|
+<strong>Address</strong> <em>address</em>
|
|
1187
|
+</dt>
|
|
1188
|
+<dd>
|
|
1189
|
+<p>
|
|
1190
|
+ The IP address or fully qualified domain name of this server (e.g.
|
|
1191
|
+ moria.mit.edu). You can leave this unset, and Tor will guess your IP
|
|
1192
|
+ address.
|
|
1193
|
+</p>
|
|
1194
|
+</dd>
|
|
1195
|
+<dt class="hdlist1">
|
|
1196
|
+<strong>AllowSingleHopExits</strong> <strong>0</strong>|<strong>1</strong>
|
|
1197
|
+</dt>
|
|
1198
|
+<dd>
|
|
1199
|
+<p>
|
|
1200
|
+ This option controls whether clients can use this server as a single hop
|
|
1201
|
+ proxy. If set to 1, clients can use this server as an exit even if it is
|
|
1202
|
+ the only hop in the circuit. Note that most clients will refuse to use
|
|
1203
|
+ servers that set this option, since most clients have
|
|
1204
|
+ ExcludeSingleHopRelays set. (Default: 0)
|
|
1205
|
+</p>
|
|
1206
|
+</dd>
|
|
1207
|
+<dt class="hdlist1">
|
|
1208
|
+<strong>AssumeReachable</strong> <strong>0</strong>|<strong>1</strong>
|
|
1209
|
+</dt>
|
|
1210
|
+<dd>
|
|
1211
|
+<p>
|
|
1212
|
+ This option is used when bootstrapping a new Tor network. If set to 1,
|
|
1213
|
+ don’t do self-reachability testing; just upload your server descriptor
|
|
1214
|
+ immediately. If <strong>AuthoritativeDirectory</strong> is also set, this option
|
|
1215
|
+ instructs the dirserver to bypass remote reachability testing too and list
|
|
1216
|
+ all connected servers as running.
|
|
1217
|
+</p>
|
|
1218
|
+</dd>
|
|
1219
|
+<dt class="hdlist1">
|
|
1220
|
+<strong>BridgeRelay</strong> <strong>0</strong>|<strong>1</strong>
|
|
1221
|
+</dt>
|
|
1222
|
+<dd>
|
|
1223
|
+<p>
|
|
1224
|
+ Sets the relay to act as a "bridge" with respect to relaying connections
|
|
1225
|
+ from bridge users to the Tor network. It mainly causes Tor to publish a
|
|
1226
|
+ server descriptor to the bridge database, rather than publishing a relay
|
|
1227
|
+ descriptor to the public directory authorities.
|
|
1228
|
+</p>
|
|
1229
|
+</dd>
|
|
1230
|
+<dt class="hdlist1">
|
|
1231
|
+<strong>ContactInfo</strong> <em>email_address</em>
|
|
1232
|
+</dt>
|
|
1233
|
+<dd>
|
|
1234
|
+<p>
|
|
1235
|
+ Administrative contact information for server. This line might get picked
|
|
1236
|
+ up by spam harvesters, so you may want to obscure the fact that it’s an
|
|
1237
|
+ email address.
|
|
1238
|
+</p>
|
|
1239
|
+</dd>
|
|
1240
|
+<dt class="hdlist1">
|
|
1241
|
+<strong>ExitPolicy</strong> <em>policy</em>,<em>policy</em>,<em>…</em>
|
|
1242
|
+</dt>
|
|
1243
|
+<dd>
|
|
1244
|
+<p>
|
|
1245
|
+ Set an exit policy for this server. Each policy is of the form
|
|
1246
|
+ "<strong>accept</strong>|<strong>reject</strong> <em>ADDR</em>[/<em>MASK</em>][:<em>PORT</em>]". If /<em>MASK</em> is
|
|
1247
|
+ omitted then this policy just applies to the host given. Instead of giving
|
|
1248
|
+ a host or network you can also use "*" to denote the universe (0.0.0.0/0).
|
|
1249
|
+ <em>PORT</em> can be a single port number, an interval of ports
|
|
1250
|
+ "<em>FROM_PORT</em>-<em>TO_PORT</em>", or "*". If <em>PORT</em> is omitted, that means
|
|
1251
|
+ "*".<br />
|
|
1252
|
+<br />
|
|
1253
|
+ For example, "accept 18.7.22.69:*,reject 18.0.0.0/8:*,accept *:*" would
|
|
1254
|
+ reject any traffic destined for MIT except for web.mit.edu, and accept
|
|
1255
|
+ anything else.<br />
|
|
1256
|
+<br />
|
|
1257
|
+ To specify all internal and link-local networks (including 0.0.0.0/8,
|
|
1258
|
+ 169.254.0.0/16, 127.0.0.0/8, 192.168.0.0/16, 10.0.0.0/8, and
|
|
1259
|
+ 172.16.0.0/12), you can use the "private" alias instead of an address.
|
|
1260
|
+ These addresses are rejected by default (at the beginning of your exit
|
|
1261
|
+ policy), along with your public IP address, unless you set the
|
|
1262
|
+ ExitPolicyRejectPrivate config option to 0. For example, once you’ve done
|
|
1263
|
+ that, you could allow HTTP to 127.0.0.1 and block all other connections to
|
|
1264
|
+ internal networks with "accept 127.0.0.1:80,reject private:*", though that
|
|
1265
|
+ may also allow connections to your own computer that are addressed to its
|
|
1266
|
+ public (external) IP address. See RFC 1918 and RFC 3330 for more details
|
|
1267
|
+ about internal and reserved IP address space.<br />
|
|
1268
|
+<br />
|
|
1269
|
+ This directive can be specified multiple times so you don’t have to put it
|
|
1270
|
+ all on one line.<br />
|
|
1271
|
+<br />
|
|
1272
|
+ Policies are considered first to last, and the first match wins. If you
|
|
1273
|
+ want to _replace_ the default exit policy, end your exit policy with
|
|
1274
|
+ either a reject *:* or an accept *:*. Otherwise, you’re _augmenting_
|
|
1275
|
+ (prepending to) the default exit policy. The default exit policy is:<br />
|
|
1276
|
+</p>
|
|
1277
|
+<div class="literalblock">
|
|
1278
|
+<div class="content">
|
|
1279
|
+<pre><tt>reject *:25^M
|
|
1280
|
+reject *:119^M
|
|
1281
|
+reject *:135-139^M
|
|
1282
|
+reject *:445^M
|
|
1283
|
+reject *:563^M
|
|
1284
|
+reject *:1214^M
|
|
1285
|
+reject *:4661-4666^M
|
|
1286
|
+reject *:6346-6429^M
|
|
1287
|
+reject *:6699^M
|
|
1288
|
+reject *:6881-6999^M
|
|
1289
|
+accept *:*</tt></pre>
|
|
1290
|
+</div></div>
|
|
1291
|
+</dd>
|
|
1292
|
+<dt class="hdlist1">
|
|
1293
|
+<strong>ExitPolicyRejectPrivate</strong> <strong>0</strong>|<strong>1</strong>
|
|
1294
|
+</dt>
|
|
1295
|
+<dd>
|
|
1296
|
+<p>
|
|
1297
|
+ Reject all private (local) networks, along with your own public IP address,
|
|
1298
|
+ at the beginning of your exit policy. See above entry on ExitPolicy.
|
|
1299
|
+ (Default: 1)
|
|
1300
|
+</p>
|
|
1301
|
+</dd>
|
|
1302
|
+<dt class="hdlist1">
|
|
1303
|
+<strong>MaxOnionsPending</strong> <em>NUM</em>
|
|
1304
|
+</dt>
|
|
1305
|
+<dd>
|
|
1306
|
+<p>
|
|
1307
|
+ If you have more than this number of onionskins queued for decrypt, reject
|
|
1308
|
+ new ones. (Default: 100)
|
|
1309
|
+</p>
|
|
1310
|
+</dd>
|
|
1311
|
+<dt class="hdlist1">
|
|
1312
|
+<strong>MyFamily</strong> <em>node</em>,<em>node</em>,<em>…</em>
|
|
1313
|
+</dt>
|
|
1314
|
+<dd>
|
|
1315
|
+<p>
|
|
1316
|
+ Declare that this Tor server is controlled or administered by a group or
|
|
1317
|
+ organization identical or similar to that of the other servers, defined by
|
|
1318
|
+ their identity fingerprints or nicknames. When two servers both declare
|
|
1319
|
+ that they are in the same 'family', Tor clients will not use them in the
|
|
1320
|
+ same circuit. (Each server only needs to list the other servers in its
|
|
1321
|
+ family; it doesn’t need to list itself, but it won’t hurt.)
|
|
1322
|
+</p>
|
|
1323
|
+</dd>
|
|
1324
|
+<dt class="hdlist1">
|
|
1325
|
+<strong>Nickname</strong> <em>name</em>
|
|
1326
|
+</dt>
|
|
1327
|
+<dd>
|
|
1328
|
+<p>
|
|
1329
|
+ Set the server’s nickname to 'name'. Nicknames must be between 1 and 19
|
|
1330
|
+ characters inclusive, and must contain only the characters [a-zA-Z0-9].
|
|
1331
|
+</p>
|
|
1332
|
+</dd>
|
|
1333
|
+<dt class="hdlist1">
|
|
1334
|
+<strong>NumCPUs</strong> <em>num</em>
|
|
1335
|
+</dt>
|
|
1336
|
+<dd>
|
|
1337
|
+<p>
|
|
1338
|
+ How many processes to use at once for decrypting onionskins. (Default: 1)
|
|
1339
|
+</p>
|
|
1340
|
+</dd>
|
|
1341
|
+<dt class="hdlist1">
|
|
1342
|
+<strong>ORPort</strong> <em>PORT</em>
|
|
1343
|
+</dt>
|
|
1344
|
+<dd>
|
|
1345
|
+<p>
|
|
1346
|
+ Advertise this port to listen for connections from Tor clients and servers.
|
|
1347
|
+</p>
|
|
1348
|
+</dd>
|
|
1349
|
+<dt class="hdlist1">
|
|
1350
|
+<strong>ORListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
|
|
1351
|
|