include stable man page fro...
Runa A. Sandvik authored 13 years ago
|
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) </dt>
1352) <dd>
1353) <p>
1354) Bind to this IP address to listen for connections from Tor clients and
1355) servers. If you specify a port, bind to this port rather than the one
1356) specified in ORPort. (Default: 0.0.0.0) This directive can be specified
1357) multiple times to bind to multiple addresses/ports.
1358) </p>
1359) </dd>
1360) <dt class="hdlist1">
1361) <strong>PublishServerDescriptor</strong> <strong>0</strong>|<strong>1</strong>|<strong>v1</strong>|<strong>v2</strong>|<strong>v3</strong>|<strong>bridge</strong>,<strong>…</strong>
1362) </dt>
1363) <dd>
1364) <p>
1365) This option specifies which descriptors Tor will publish when acting as
1366) a relay. You can
1367) choose multiple arguments, separated by commas.
1368) <br />
1369) If this option is set to 0, Tor will not publish its
1370) descriptors to any directories. (This is useful if you’re testing
1371) out your server, or if you’re using a Tor controller that handles directory
1372) publishing for you.) Otherwise, Tor will publish its descriptors of all
1373) type(s) specified. The default is "1",
1374) which means "if running as a server, publish the
1375) appropriate descriptors to the authorities".
1376) </p>
1377) </dd>
1378) <dt class="hdlist1">
1379) <strong>ShutdownWaitLength</strong> <em>NUM</em>
1380) </dt>
1381) <dd>
1382) <p>
1383) When we get a SIGINT and we’re a server, we begin shutting down:
1384) we close listeners and start refusing new circuits. After <strong>NUM</strong>
1385) seconds, we exit. If we get a second SIGINT, we exit immedi-
1386) ately. (Default: 30 seconds)
1387) </p>
1388) </dd>
1389) <dt class="hdlist1">
1390) <strong>AccountingMax</strong> <em>N</em> <strong>bytes</strong>|<strong>KB</strong>|<strong>MB</strong>|<strong>GB</strong>|<strong>TB</strong>
1391) </dt>
1392) <dd>
1393) <p>
1394) Never send more than the specified number of bytes in a given accounting
1395) period, or receive more than that number in the period. For example, with
1396) AccountingMax set to 1 GB, a server could send 900 MB and receive 800 MB
1397) and continue running. It will only hibernate once one of the two reaches 1
1398) GB. When the number of bytes gets low, Tor will stop accepting new
1399) connections and circuits. When the number of bytes
1400) is exhausted, Tor will hibernate until some
1401) time in the next accounting period. To prevent all servers from waking at
1402) the same time, Tor will also wait until a random point in each period
1403) before waking up. If you have bandwidth cost issues, enabling hibernation
1404) is preferable to setting a low bandwidth, since it provides users with a
1405) collection of fast servers that are up some of the time, which is more
1406) useful than a set of slow servers that are always "available".
1407) </p>
1408) </dd>
1409) <dt class="hdlist1">
1410) <strong>AccountingStart</strong> <strong>day</strong>|<strong>week</strong>|<strong>month</strong> [<em>day</em>] <em>HH:MM</em>
1411) </dt>
1412) <dd>
1413) <p>
1414) Specify how long accounting periods last. If <strong>month</strong> is given, each
1415) accounting period runs from the time <em>HH:MM</em> on the <em>dayth</em> day of one
1416) month to the same day and time of the next. (The day must be between 1 and
1417) 28.) If <strong>week</strong> is given, each accounting period runs from the time <em>HH:MM</em>
1418) of the <em>dayth</em> day of one week to the same day and time of the next week,
1419) with Monday as day 1 and Sunday as day 7. If <strong>day</strong> is given, each
1420) accounting period runs from the time <em>HH:MM</em> each day to the same time on
1421) the next day. All times are local, and given in 24-hour time. (Defaults to
1422) "month 1 0:00".)
1423) </p>
1424) </dd>
1425) <dt class="hdlist1">
1426) <strong>ServerDNSResolvConfFile</strong> <em>filename</em>
1427) </dt>
1428) <dd>
1429) <p>
1430) Overrides the default DNS configuration with the configuration in
1431) <em>filename</em>. The file format is the same as the standard Unix
1432) "<strong>resolv.conf</strong>" file (7). This option, like all other ServerDNS options,
1433) only affects name lookups that your server does on behalf of clients.
1434) (Defaults to use the system DNS configuration.)
1435) </p>
1436) </dd>
1437) <dt class="hdlist1">
1438) <strong>ServerDNSAllowBrokenConfig</strong> <strong>0</strong>|<strong>1</strong>
1439) </dt>
1440) <dd>
1441) <p>
1442) If this option is false, Tor exits immediately if there are problems
1443) parsing the system DNS configuration or connecting to nameservers.
1444) Otherwise, Tor continues to periodically retry the system nameservers until
1445) it eventually succeeds. (Defaults to "1".)
1446) </p>
1447) </dd>
1448) <dt class="hdlist1">
1449) <strong>ServerDNSSearchDomains</strong> <strong>0</strong>|<strong>1</strong>
1450) </dt>
1451) <dd>
1452) <p>
1453) If set to 1, then we will search for addresses in the local search domain.
1454) For example, if this system is configured to believe it is in
1455) "example.com", and a client tries to connect to "www", the client will be
1456) connected to "www.example.com". This option only affects name lookups that
1457) your server does on behalf of clients. (Defaults to "0".)
1458) </p>
1459) </dd>
1460) <dt class="hdlist1">
1461) <strong>ServerDNSDetectHijacking</strong> <strong>0</strong>|<strong>1</strong>
1462) </dt>
1463) <dd>
1464) <p>
1465) When this option is set to 1, we will test periodically to determine
1466) whether our local nameservers have been configured to hijack failing DNS
1467) requests (usually to an advertising site). If they are, we will attempt to
1468) correct this. This option only affects name lookups that your server does
1469) on behalf of clients. (Defaults to "1".)
1470) </p>
1471) </dd>
1472) <dt class="hdlist1">
1473) <strong>ServerDNSTestAddresses</strong> <em>address</em>,<em>address</em>,<em>…</em>
1474) </dt>
1475) <dd>
1476) <p>
1477) When we’re detecting DNS hijacking, make sure that these <em>valid</em> addresses
1478) aren’t getting redirected. If they are, then our DNS is completely useless,
1479) and we’ll reset our exit policy to "reject <strong>:</strong>". This option only affects
1480) name lookups that your server does on behalf of clients. (Defaults to
1481) "www.google.com, www.mit.edu, www.yahoo.com, www.slashdot.org".)
1482) </p>
1483) </dd>
1484) <dt class="hdlist1">
1485) <strong>ServerDNSAllowNonRFC953Hostnames</strong> <strong>0</strong>|<strong>1</strong>
1486) </dt>
1487) <dd>
1488) <p>
1489) When this option is disabled, Tor does not try to resolve hostnames
1490) containing illegal characters (like @ and :) rather than sending them to an
1491) exit node to be resolved. This helps trap accidental attempts to resolve
1492) URLs and so on. This option only affects name lookups that your server does
1493) on behalf of clients. (Default: 0)
1494) </p>
1495) </dd>
1496) <dt class="hdlist1">
1497) <strong>BridgeRecordUsageByCountry</strong> <strong>0</strong>|<strong>1</strong>
1498) </dt>
1499) <dd>
1500) <p>
1501) When this option is enabled and BridgeRelay is also enabled, and we have
1502) GeoIP data, Tor keeps a keep a per-country count of how many client
1503) addresses have contacted it so that it can help the bridge authority guess
1504) which countries have blocked access to it. (Default: 1)
1505) </p>
1506) </dd>
1507) <dt class="hdlist1">
1508) <strong>ServerDNSRandomizeCase</strong> <strong>0</strong>|<strong>1</strong>
1509) </dt>
1510) <dd>
1511) <p>
1512) When this option is set, Tor sets the case of each character randomly in
1513) outgoing DNS requests, and makes sure that the case matches in DNS replies.
1514) This so-called "0x20 hack" helps resist some types of DNS poisoning attack.
1515) For more information, see "Increased DNS Forgery Resistance through
1516) 0x20-Bit Encoding". This option only affects name lookups that your server
1517) does on behalf of clients. (Default: 1)
1518) </p>
1519) </dd>
1520) <dt class="hdlist1">
1521) <strong>GeoIPFile</strong> <em>filename</em>
1522) </dt>
1523) <dd>
1524) <p>
1525) A filename containing GeoIP data, for use with BridgeRecordUsageByCountry.
1526) </p>
1527) </dd>
1528) </dl></div>
1529) </div>
1530) <h2 id="_directory_server_options">DIRECTORY SERVER OPTIONS</h2>
1531) <div class="sectionbody">
1532) <div class="paragraph"><p>The following options are useful only for directory servers (that is,
1533) if DirPort is non-zero):</p></div>
1534) <div class="dlist"><dl>
1535) <dt class="hdlist1">
1536) <strong>AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
1537) </dt>
1538) <dd>
1539) <p>
1540) When this option is set to 1, Tor operates as an authoritative directory
1541) server. Instead of caching the directory, it generates its own list of
1542) good servers, signs it, and sends that to the clients. Unless the clients
1543) already have you listed as a trusted directory, you probably do not want
1544) to set this option. Please coordinate with the other admins at
1545) <a href="mailto:tor-ops@torproject.org">tor-ops@torproject.org</a> if you think you should be a directory.
1546) </p>
1547) </dd>
1548) <dt class="hdlist1">
1549) <strong>DirPortFrontPage</strong> <em>FILENAME</em>
1550) </dt>
1551) <dd>
1552) <p>
1553) When this option is set, it takes an HTML file and publishes it as "/" on
1554) the DirPort. Now relay operators can provide a disclaimer without needing
1555) to set up a separate webserver. There’s a sample disclaimer in
1556) contrib/tor-exit-notice.html.
1557) </p>
1558) </dd>
1559) <dt class="hdlist1">
1560) <strong>V1AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
1561) </dt>
1562) <dd>
1563) <p>
1564) When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
1565) generates version 1 directory and running-routers documents (for legacy
1566) Tor clients up to 0.1.0.x).
1567) </p>
1568) </dd>
1569) <dt class="hdlist1">
1570) <strong>V2AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
1571) </dt>
1572) <dd>
1573) <p>
1574) When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
1575) generates version 2 network statuses and serves descriptors, etc as
1576) described in doc/spec/dir-spec-v2.txt (for Tor clients and servers running
1577) 0.1.1.x and 0.1.2.x).
1578) </p>
1579) </dd>
1580) <dt class="hdlist1">
1581) <strong>V3AuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
1582) </dt>
1583) <dd>
1584) <p>
1585) When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
1586) generates version 3 network statuses and serves descriptors, etc as
1587) described in doc/spec/dir-spec.txt (for Tor clients and servers running at
1588) least 0.2.0.x).
1589) </p>
1590) </dd>
1591) <dt class="hdlist1">
1592) <strong>VersioningAuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
1593) </dt>
1594) <dd>
1595) <p>
1596) When this option is set to 1, Tor adds information on which versions of
1597) Tor are still believed safe for use to the published directory. Each
1598) version 1 authority is automatically a versioning authority; version 2
1599) authorities provide this service optionally. See <strong>RecommendedVersions</strong>,
1600) <strong>RecommendedClientVersions</strong>, and <strong>RecommendedServerVersions</strong>.
1601) </p>
1602) </dd>
1603) <dt class="hdlist1">
1604) <strong>NamingAuthoritativeDirectory</strong> <strong>0</strong>|<strong>1</strong>
1605) </dt>
1606) <dd>
1607) <p>
1608) When this option is set to 1, then the server advertises that it has
1609) opinions about nickname-to-fingerprint bindings. It will include these
1610) opinions in its published network-status pages, by listing servers with
1611) the flag "Named" if a correct binding between that nickname and fingerprint
1612) has been registered with the dirserver. Naming dirservers will refuse to
1613) accept or publish descriptors that contradict a registered binding. See
1614) <strong>approved-routers</strong> in the <strong>FILES</strong> section below.
1615) </p>
1616) </dd>
1617) <dt class="hdlist1">
1618) <strong>HSAuthoritativeDir</strong> <strong>0</strong>|<strong>1</strong>
1619) </dt>
1620) <dd>
1621) <p>
1622) When this option is set in addition to
1623) <strong>AuthoritativeDirectory</strong>, Tor also accepts and serves hidden
1624) service descriptors. (Default: 0)
1625) </p>
1626) </dd>
1627) <dt class="hdlist1">
1628) <strong>HSAuthorityRecordStats</strong> <strong>0</strong>|<strong>1</strong>
1629) </dt>
1630) <dd>
1631) <p>
1632) When this option is set in addition to <strong>HSAuthoritativeDir</strong>,
1633) Tor periodically (every 15 minutes) writes statistics about hidden service
1634) usage to a file <strong>hsusage</strong> in its data directory. (Default:
1635) 0)
1636) </p>
1637) </dd>
1638) <dt class="hdlist1">
1639) <strong>HidServDirectoryV2</strong> <strong>0</strong>|<strong>1</strong>
1640) </dt>
1641) <dd>
1642) <p>
1643) When this option is set, Tor accepts and serves v2 hidden service
1644) descriptors. Setting DirPort is not required for this, because clients
1645) connect via the ORPort by default. (Default: 1)
1646) </p>
1647) </dd>
1648) <dt class="hdlist1">
1649) <strong>BridgeAuthoritativeDir</strong> <strong>0</strong>|<strong>1</strong>
1650) </dt>
1651) <dd>
1652) <p>
1653) When this option is set in addition to <strong>AuthoritativeDirectory</strong>, Tor
1654) accepts and serves router descriptors, but it caches and serves the main
1655) networkstatus documents rather than generating its own. (Default: 0)
1656) </p>
1657) </dd>
1658) <dt class="hdlist1">
1659) <strong>MinUptimeHidServDirectoryV2</strong> <em>N</em> <strong>seconds</strong>|<strong>minutes</strong>|<strong>hours</strong>|<strong>days</strong>|<strong>weeks</strong>
1660) </dt>
1661) <dd>
1662) <p>
1663) Minimum uptime of a v2 hidden service directory to be accepted as such by
1664) authoritative directories. (Default: 24 hours)
1665) </p>
1666) </dd>
1667) <dt class="hdlist1">
1668) <strong>DirPort</strong> <em>PORT</em>
1669) </dt>
1670) <dd>
1671) <p>
1672) Advertise the directory service on this port.
1673) </p>
1674) </dd>
1675) <dt class="hdlist1">
1676) <strong>DirListenAddress</strong> <em>IP</em>[:<em>PORT</em>]
1677) </dt>
1678) <dd>
1679) <p>
1680) Bind the directory service to this address. If you specify a port, bind to
1681) this port rather than the one specified in DirPort. (Default: 0.0.0.0)
1682) This directive can be specified multiple times to bind to multiple
1683) addresses/ports.
1684) </p>
1685) </dd>
1686) <dt class="hdlist1">
1687) <strong>DirPolicy</strong> <em>policy</em>,<em>policy</em>,<em>…</em>
1688) </dt>
1689) <dd>
1690) <p>
1691) Set an entrance policy for this server, to limit who can connect to the
1692) directory ports. The policies have the same form as exit policies above.
1693) </p>
1694) </dd>
1695) </dl></div>
1696) </div>
1697) <h2 id="_directory_authority_server_options">DIRECTORY AUTHORITY SERVER OPTIONS</h2>
1698) <div class="sectionbody">
1699) <div class="dlist"><dl>
1700) <dt class="hdlist1">
1701) <strong>RecommendedVersions</strong> <em>STRING</em>
1702) </dt>
1703) <dd>
1704) <p>
1705) STRING is a comma-separated list of Tor versions currently believed to be
1706) safe. The list is included in each directory, and nodes which pull down the
1707) directory learn whether they need to upgrade. This option can appear
1708) multiple times: the values from multiple lines are spliced together. When
1709) this is set then <strong>VersioningAuthoritativeDirectory</strong> should be set too.
1710) </p>
1711) </dd>
1712) <dt class="hdlist1">
1713) <strong>RecommendedClientVersions</strong> <em>STRING</em>
1714) </dt>
1715) <dd>
1716) <p>
1717) STRING is a comma-separated list of Tor versions currently believed to be
1718) safe for clients to use. This information is included in version 2
1719) directories. If this is not set then the value of <strong>RecommendedVersions</strong>
1720) is used. When this is set then <strong>VersioningAuthoritativeDirectory</strong> should
1721) be set too.
1722) </p>
1723) </dd>
1724) <dt class="hdlist1">
1725) <strong>RecommendedServerVersions</strong> <em>STRING</em>
1726) </dt>
1727) <dd>
1728) <p>
1729) STRING is a comma-separated list of Tor versions currently believed to be
1730) safe for servers to use. This information is included in version 2
1731) directories. If this is not set then the value of <strong>RecommendedVersions</strong>
1732) is used. When this is set then <strong>VersioningAuthoritativeDirectory</strong> should
1733) be set too.
1734) </p>
1735) </dd>
1736) <dt class="hdlist1">
1737) <strong>DirAllowPrivateAddresses</strong> <strong>0</strong>|<strong>1</strong>
1738) </dt>
1739) <dd>
1740) <p>
1741) If set to 1, Tor will accept router descriptors with arbitrary "Address"
1742) elements. Otherwise, if the address is not an IP address or is a private IP
1743) address, it will reject the router descriptor. Defaults to 0.
1744) </p>
1745) </dd>
1746) <dt class="hdlist1">
1747) <strong>AuthDirBadDir</strong> <em>AddressPattern…</em>
1748) </dt>
1749) <dd>
1750) <p>
1751) Authoritative directories only. A set of address patterns for servers that
1752) will be listed as bad directories in any network status document this
1753) authority publishes, if <strong>AuthDirListBadDirs</strong> is set.
1754) </p>
1755) </dd>
1756) <dt class="hdlist1">
1757) <strong>AuthDirBadExit</strong> <em>AddressPattern…</em>
1758) </dt>
1759) <dd>
1760) <p>
1761) Authoritative directories only. A set of address patterns for servers that
1762) will be listed as bad exits in any network status document this authority
1763) publishes, if <strong>AuthDirListBadExits</strong> is set.
1764) </p>
1765) </dd>
1766) <dt class="hdlist1">
1767) <strong>AuthDirInvalid</strong> <em>AddressPattern…</em>
1768) </dt>
1769) <dd>
1770) <p>
1771) Authoritative directories only. A set of address patterns for servers that
1772) will never be listed as "valid" in any network status document that this
1773) authority publishes.
1774) </p>
1775) </dd>
1776) <dt class="hdlist1">
1777) <strong>AuthDirReject</strong> <em>AddressPattern</em>…
1778) </dt>
1779) <dd>
1780) <p>
1781) Authoritative directories only. A set of address patterns for servers that
1782) will never be listed at all in any network status document that this
1783) authority publishes, or accepted as an OR address in any descriptor
1784) submitted for publication by this authority.
1785) </p>
1786) </dd>
1787) <dt class="hdlist1">
1788) <strong>AuthDirListBadDirs</strong> <strong>0</strong>|<strong>1</strong>
1789) </dt>
1790) <dd>
1791) <p>
1792) Authoritative directories only. If set to 1, this directory has some
1793) opinion about which nodes are unsuitable as directory caches. (Do not set
1794) this to 1 unless you plan to list non-functioning directories as bad;
1795) otherwise, you are effectively voting in favor of every declared
1796) directory.)
1797) </p>
1798) </dd>
1799) <dt class="hdlist1">
1800) <strong>AuthDirListBadExits</strong> <strong>0</strong>|<strong>1</strong>
1801) </dt>
1802) <dd>
1803) <p>
1804) Authoritative directories only. If set to 1, this directory has some
1805) opinion about which nodes are unsuitable as exit nodes. (Do not set this to
1806) 1 unless you plan to list non-functioning exits as bad; otherwise, you are
1807) effectively voting in favor of every declared exit as an exit.)
1808) </p>
1809) </dd>
1810) <dt class="hdlist1">
1811) <strong>AuthDirRejectUnlisted</strong> <strong>0</strong>|<strong>1</strong>
1812) </dt>
1813) <dd>
1814) <p>
1815) Authoritative directories only. If set to 1, the directory server rejects
1816) all uploaded server descriptors that aren’t explicitly listed in the
1817) fingerprints file. This acts as a "panic button" if we get hit with a Sybil
1818) attack. (Default: 0)
1819) </p>
1820) </dd>
1821) <dt class="hdlist1">
1822) <strong>AuthDirMaxServersPerAddr</strong> <em>NUM</em>
1823) </dt>
1824) <dd>
1825) <p>
1826) Authoritative directories only. The maximum number of servers that we will
1827) list as acceptable on a single IP address. Set this to "0" for "no limit".
1828) (Default: 2)
1829) </p>
1830) </dd>
1831) <dt class="hdlist1">
1832) <strong>AuthDirMaxServersPerAuthAddr</strong> <em>NUM</em>
1833) </dt>
1834) <dd>
1835) <p>
1836) Authoritative directories only. Like AuthDirMaxServersPerAddr, but applies
1837) to addresses shared with directory authorities. (Default: 5)
1838) </p>
1839) </dd>
1840) <dt class="hdlist1">
1841) <strong>V3AuthVotingInterval</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
1842) </dt>
1843) <dd>
1844) <p>
1845) V3 authoritative directories only. Configures the server’s preferred voting
1846) interval. Note that voting will <em>actually</em> happen at an interval chosen
1847) by consensus from all the authorities' preferred intervals. This time
1848) SHOULD divide evenly into a day. (Default: 1 hour)
1849) </p>
1850) </dd>
1851) <dt class="hdlist1">
1852) <strong>V3AuthVoteDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
1853) </dt>
1854) <dd>
1855) <p>
1856) V3 authoritative directories only. Configures the server’s preferred delay
1857) between publishing its vote and assuming it has all the votes from all the
1858) other authorities. Note that the actual time used is not the server’s
1859) preferred time, but the consensus of all preferences. (Default: 5 minutes.)
1860) </p>
1861) </dd>
1862) <dt class="hdlist1">
1863) <strong>V3AuthDistDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
1864) </dt>
1865) <dd>
1866) <p>
1867) V3 authoritative directories only. Configures the server’s preferred delay
1868) between publishing its consensus and signature and assuming it has all the
1869) signatures from all the other authorities. Note that the actual time used
1870) is not the server’s preferred time, but the consensus of all preferences.
1871) (Default: 5 minutes.)
1872) </p>
1873) </dd>
1874) <dt class="hdlist1">
1875) <strong>V3AuthNIntervalsValid</strong> <em>NUM</em>
1876) </dt>
1877) <dd>
1878) <p>
1879) V3 authoritative directories only. Configures the number of VotingIntervals
1880) for which each consensus should be valid for. Choosing high numbers
1881) increases network partitioning risks; choosing low numbers increases
1882) directory traffic. Note that the actual number of intervals used is not the
1883) server’s preferred number, but the consensus of all preferences. Must be at
1884) least 2. (Default: 3.)
1885) </p>
1886) </dd>
1887) </dl></div>
1888) </div>
1889) <h2 id="_hidden_service_options">HIDDEN SERVICE OPTIONS</h2>
1890) <div class="sectionbody">
1891) <div class="paragraph"><p>The following options are used to configure a hidden service.</p></div>
1892) <div class="dlist"><dl>
1893) <dt class="hdlist1">
1894) <strong>HiddenServiceDir</strong> <em>DIRECTORY</em>
1895) </dt>
1896) <dd>
1897) <p>
1898) Store data files for a hidden service in DIRECTORY. Every hidden service
1899) must have a separate directory. You may use this option multiple times to
1900) specify multiple services.
1901) </p>
1902) </dd>
1903) <dt class="hdlist1">
1904) <strong>HiddenServicePort</strong> <em>VIRTPORT</em> [<em>TARGET</em>]
1905) </dt>
1906) <dd>
1907) <p>
1908) Configure a virtual port VIRTPORT for a hidden service. You may use this
1909) option multiple times; each time applies to the service using the most
1910) recent hiddenservicedir. By default, this option maps the virtual port to
1911) the same port on 127.0.0.1. You may override the target port, address, or
1912) both by specifying a target of addr, port, or addr:port. You may also have
1913) multiple lines with the same VIRTPORT: when a user connects to that
1914) VIRTPORT, one of the TARGETs from those lines will be chosen at random.
1915) </p>
1916) </dd>
1917) <dt class="hdlist1">
1918) <strong>PublishHidServDescriptors</strong> <strong>0</strong>|<strong>1</strong>
1919) </dt>
1920) <dd>
1921) <p>
1922) If set to 0, Tor will run any hidden services you configure, but it won’t
1923) advertise them to the rendezvous directory. This option is only useful if
1924) you’re using a Tor controller that handles hidserv publishing for you.
1925) (Default: 1)
1926) </p>
1927) </dd>
1928) <dt class="hdlist1">
1929) <strong>HiddenServiceVersion</strong> <em>version</em>,<em>version</em>,<em>…</em>
1930) </dt>
1931) <dd>
1932) <p>
1933) A list of rendezvous service descriptor versions to publish for the hidden
1934) service. Currently, only version 2 is supported. (Default: 2)
1935) </p>
1936) </dd>
1937) <dt class="hdlist1">
1938) <strong>HiddenServiceAuthorizeClient</strong> <em>auth-type</em> <em>client-name</em>,<em>client-name</em>,<em>…</em>
1939) </dt>
1940) <dd>
1941) <p>
1942) If configured, the hidden service is accessible for authorized clients
1943) only. The auth-type can either be 'basic' for a general-purpose
1944) authorization protocol or 'stealth' for a less scalable protocol that also
1945) hides service activity from unauthorized clients. Only clients that are
1946) listed here are authorized to access the hidden service. Valid client names
1947) are 1 to 19 characters long and only use characters in A-Za-z0-9+-_ (no
1948) spaces). If this option is set, the hidden service is not accessible for
1949) clients without authorization any more. Generated authorization data can be
1950) found in the hostname file. Clients need to put this authorization data in
1951) their configuration file using <strong>HidServAuth</strong>.
1952) </p>
1953) </dd>
1954) <dt class="hdlist1">
1955) <strong>RendPostPeriod</strong> <em>N</em> <strong>seconds</strong>|<strong>minutes</strong>|<strong>hours</strong>|<strong>days</strong>|<strong>weeks</strong>
1956) </dt>
1957) <dd>
1958) <p>
1959) Every time the specified period elapses, Tor uploads any rendezvous
1960) service descriptors to the directory servers. This information is also
1961) uploaded whenever it changes. (Default: 1 hour)
1962) </p>
1963) </dd>
1964) </dl></div>
1965) </div>
1966) <h2 id="_testing_network_options">TESTING NETWORK OPTIONS</h2>
1967) <div class="sectionbody">
1968) <div class="paragraph"><p>The following options are used for running a testing Tor network.</p></div>
1969) <div class="dlist"><dl>
1970) <dt class="hdlist1">
1971) <strong>TestingTorNetwork</strong> <strong>0</strong>|<strong>1</strong>
1972) </dt>
1973) <dd>
1974) <p>
1975) If set to 1, Tor adjusts default values of the configuration options below,
1976) so that it is easier to set up a testing Tor network. May only be set if
1977) non-default set of DirServers is set. Cannot be unset while Tor is running.
1978) (Default: 0)<br />
1979) </p>
1980) <div class="literalblock">
1981) <div class="content">
1982) <pre><tt>ServerDNSAllowBrokenConfig 1^M
1983) DirAllowPrivateAddresses 1^M
1984) EnforceDistinctSubnets 0^M
1985) AssumeReachable 1^M
1986) AuthDirMaxServersPerAddr 0^M
1987) AuthDirMaxServersPerAuthAddr 0^M
1988) ClientDNSRejectInternalAddresses 0^M
1989) ExitPolicyRejectPrivate 0^M
1990) V3AuthVotingInterval 5 minutes^M
1991) V3AuthVoteDelay 20 seconds^M
1992) V3AuthDistDelay 20 seconds^M
1993) TestingV3AuthInitialVotingInterval 5 minutes^M
1994) TestingV3AuthInitialVoteDelay 20 seconds^M
1995) TestingV3AuthInitialDistDelay 20 seconds^M
1996) TestingAuthDirTimeToLearnReachability 0 minutes^M
1997) TestingEstimatedDescriptorPropagationTime 0 minutes</tt></pre>
1998) </div></div>
1999) </dd>
2000) <dt class="hdlist1">
2001) <strong>TestingV3AuthInitialVotingInterval</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
2002) </dt>
2003) <dd>
2004) <p>
2005) Like V3AuthVotingInterval, but for initial voting interval before the first
2006) consensus has been created. Changing this requires that
2007) <strong>TestingTorNetwork</strong> is set. (Default: 30 minutes)
2008) </p>
2009) </dd>
2010) <dt class="hdlist1">
2011) <strong>TestingV3AuthInitialVoteDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
2012) </dt>
2013) <dd>
2014) <p>
2015) Like TestingV3AuthInitialVoteDelay, but for initial voting interval before
2016) the first consensus has been created. Changing this requires that
2017) <strong>TestingTorNetwork</strong> is set. (Default: 5 minutes)
2018) </p>
2019) </dd>
2020) <dt class="hdlist1">
2021) <strong>TestingV3AuthInitialDistDelay</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
2022) </dt>
2023) <dd>
2024) <p>
2025) Like TestingV3AuthInitialDistDelay, but for initial voting interval before
2026) the first consensus has been created. Changing this requires that
2027) <strong>TestingTorNetwork</strong> is set. (Default: 5 minutes)
2028) </p>
2029) </dd>
2030) <dt class="hdlist1">
2031) <strong>TestingAuthDirTimeToLearnReachability</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
2032) </dt>
2033) <dd>
2034) <p>
2035) After starting as an authority, do not make claims about whether routers
2036) are Running until this much time has passed. Changing this requires
2037) that <strong>TestingTorNetwork</strong> is set. (Default: 30 minutes)
2038) </p>
2039) </dd>
2040) <dt class="hdlist1">
2041) <strong>TestingEstimatedDescriptorPropagationTime</strong> <em>N</em> <strong>minutes</strong>|<strong>hours</strong>
2042) </dt>
2043) <dd>
2044) <p>
2045) Clients try downloading router descriptors from directory caches after this
2046) time. Changing this requires that <strong>TestingTorNetwork</strong> is set. (Default:
2047) 10 minutes)
2048) </p>
2049) </dd>
2050) </dl></div>
2051) </div>
2052) <h2 id="_signals">SIGNALS</h2>
2053) <div class="sectionbody">
2054) <div class="paragraph"><p>Tor catches the following signals:</p></div>
2055) <div class="dlist"><dl>
2056) <dt class="hdlist1">
2057) <strong>SIGTERM</strong>
2058) </dt>
2059) <dd>
2060) <p>
2061) Tor will catch this, clean up and sync to disk if necessary, and exit.
2062) </p>
2063) </dd>
2064) <dt class="hdlist1">
2065) <strong>SIGINT</strong>
2066) </dt>
2067) <dd>
2068) <p>
2069) Tor clients behave as with SIGTERM; but Tor servers will do a controlled
2070) slow shutdown, closing listeners and waiting 30 seconds before exiting.
2071) (The delay can be configured with the ShutdownWaitLength config option.)
2072) </p>
2073) </dd>
2074) <dt class="hdlist1">
2075) <strong>SIGHUP</strong>
2076) </dt>
2077) <dd>
2078) <p>
2079) The signal instructs Tor to reload its configuration (including closing and
2080) reopening logs), and kill and restart its helper processes if applicable.
2081) </p>
2082) </dd>
2083) <dt class="hdlist1">
2084) <strong>SIGUSR1</strong>
2085) </dt>
2086) <dd>
2087) <p>
2088) Log statistics about current connections, past connections, and throughput.
2089) </p>
2090) </dd>
2091) <dt class="hdlist1">
2092) <strong>SIGUSR2</strong>
2093) </dt>
2094) <dd>
2095) <p>
2096) Switch all logs to loglevel debug. You can go back to the old loglevels by
2097) sending a SIGHUP.
2098) </p>
2099) </dd>
2100) <dt class="hdlist1">
2101) <strong>SIGCHLD</strong>
2102) </dt>
2103) <dd>
2104) <p>
2105) Tor receives this signal when one of its helper processes has exited, so it
2106) can clean up.
2107) </p>
2108) </dd>
2109) <dt class="hdlist1">
2110) <strong>SIGPIPE</strong>
2111) </dt>
2112) <dd>
2113) <p>
2114) Tor catches this signal and ignores it.
2115) </p>
2116) </dd>
2117) <dt class="hdlist1">
2118) <strong>SIGXFSZ</strong>
2119) </dt>
2120) <dd>
2121) <p>
2122) If this signal exists on your platform, Tor catches and ignores it.
2123) </p>
2124) </dd>
2125) </dl></div>
2126) </div>
2127) <h2 id="_files">FILES</h2>
2128) <div class="sectionbody">
2129) <div class="dlist"><dl>
2130) <dt class="hdlist1">
2131) <strong>@CONFDIR@/torrc</strong>
2132) </dt>
2133) <dd>
2134) <p>
2135) The configuration file, which contains "option value" pairs.
2136) </p>
2137) </dd>
2138) <dt class="hdlist1">
2139) <strong>@LOCALSTATEDIR@/lib/tor/</strong>
2140) </dt>
2141) <dd>
2142) <p>
2143) The tor process stores keys and other data here.
2144) </p>
2145) </dd>
2146) <dt class="hdlist1">
2147) <em>DataDirectory</em><strong>/cached-status/</strong>
2148) </dt>
2149) <dd>
2150) <p>
2151) The most recently downloaded network status document for each authority.
2152) Each file holds one such document; the filenames are the hexadecimal
2153) identity key fingerprints of the directory authorities.
2154) </p>
2155) </dd>
2156) <dt class="hdlist1">
2157) <em>DataDirectory</em><strong>/cached-descriptors</strong> and <strong>cached-descriptors.new</strong>
2158) </dt>
2159) <dd>
2160) <p>
2161) These files hold downloaded router statuses. Some routers may appear more
2162) than once; if so, the most recently published descriptor is used. Lines
2163) beginning with @-signs are annotations that contain more information about
2164) a given router. The ".new" file is an append-only journal; when it gets
2165) too large, all entries are merged into a new cached-descriptors file.
2166) </p>
2167) </dd>
2168) <dt class="hdlist1">
2169) <em>DataDirectory</em><strong>/cached-routers</strong> and <strong>cached-routers.new</strong>
2170) </dt>
2171) <dd>
2172) <p>
2173) Obsolete versions of cached-descriptors and cached-descriptors.new. When
2174) Tor can’t find the newer files, it looks here instead.
2175) </p>
2176) </dd>
2177) <dt class="hdlist1">
2178) <em>DataDirectory</em><strong>/state</strong>
2179) </dt>
2180) <dd>
2181) <p>
2182) A set of persistent key-value mappings. These are documented in
2183) the file. These include:
2184) </p>
2185) <div class="ulist"><ul>
2186) <li>
2187) <p>
2188) The current entry guards and their status.
2189) </p>
2190) </li>
2191) <li>
2192) <p>
2193) The current bandwidth accounting values (unused so far; see
2194) below).
2195) </p>
2196) </li>
2197) <li>
2198) <p>
2199) When the file was last written
2200) </p>
2201) </li>
2202) <li>
2203) <p>
2204) What version of Tor generated the state file
2205) </p>
2206) </li>
2207) <li>
2208) <p>
2209) A short history of bandwidth usage, as produced in the router
2210) descriptors.
2211) </p>
2212) </li>
2213) </ul></div>
2214) </dd>
2215) <dt class="hdlist1">
2216) <em>DataDirectory</em><strong>/bw_accounting</strong>
2217) </dt>
2218) <dd>
2219) <p>
2220) Used to track bandwidth accounting values (when the current period starts
2221) and ends; how much has been read and written so far this period). This file
2222) is obsolete, and the data is now stored in the 'state' file as well. Only
2223) used when bandwidth accounting is enabled.
2224) </p>
2225) </dd>
2226) <dt class="hdlist1">
2227) <em>DataDirectory</em><strong>/control_auth_cookie</strong>
2228) </dt>
2229) <dd>
2230) <p>
2231) Used for cookie authentication with the controller. Location can be
2232) overridden by the CookieAuthFile config option. Regenerated on startup. See
2233) control-spec.txt for details. Only used when cookie authentication is
2234) enabled.
2235) </p>
2236) </dd>
2237) <dt class="hdlist1">
2238) <em>DataDirectory</em><strong>/keys/</strong>*
2239) </dt>
2240) <dd>
2241) <p>
2242) Only used by servers. Holds identity keys and onion keys.
2243) </p>
2244) </dd>
2245) <dt class="hdlist1">
2246) <em>DataDirectory</em><strong>/fingerprint</strong>
2247) </dt>
2248) <dd>
2249) <p>
2250) Only used by servers. Holds the fingerprint of the server’s identity key.
2251) </p>
2252) </dd>
2253) <dt class="hdlist1">
2254) <em>DataDirectory</em><strong>/approved-routers</strong>
2255) </dt>
2256) <dd>
2257) <p>
2258) Only for naming authoritative directory servers (see
2259) <strong>NamingAuthoritativeDirectory</strong>). This file lists nickname to identity
2260) bindings. Each line lists a nickname and a fingerprint separated by
2261) whitespace. See your <strong>fingerprint</strong> file in the <em>DataDirectory</em> for an
2262) example line. If the nickname is <strong>!reject</strong> then descriptors from the
2263) given identity (fingerprint) are rejected by this server. If it is
2264) <strong>!invalid</strong> then descriptors are accepted but marked in the directory as
2265) not valid, that is, not recommended.
2266) </p>
2267) </dd>
2268) <dt class="hdlist1">
2269) <em>DataDirectory</em><strong>/router-stability</strong>
2270) </dt>
2271) <dd>
2272) <p>
2273) Only used by authoritative directory servers. Tracks measurements for
2274) router mean-time-between-failures so that authorities have a good idea of
2275) how to set their Stable flags.
2276) </p>
2277) </dd>
2278) <dt class="hdlist1">
2279) <em>HiddenServiceDirectory</em><strong>/hostname</strong>
2280) </dt>
2281) <dd>
2282) <p>
2283) The <base32-encoded-fingerprint>.onion domain name for this hidden service.
2284) If the hidden service is restricted to authorized clients only, this file
2285) also contains authorization data for all clients.
2286) </p>
2287) </dd>
2288) <dt class="hdlist1">
2289) <em>HiddenServiceDirectory</em><strong>/private_key</strong>
2290) </dt>
2291) <dd>
2292) <p>
2293) The private key for this hidden service.
2294) </p>
2295) </dd>
2296) <dt class="hdlist1">
2297) <em>HiddenServiceDirectory</em><strong>/client_keys</strong>
2298) </dt>
2299) <dd>
2300) <p>
2301) Authorization data for a hidden service that is only accessible by
2302) authorized clients.
2303) </p>
2304) </dd>
2305) </dl></div>
2306) </div>
2307) <h2 id="_see_also">SEE ALSO</h2>
2308) <div class="sectionbody">
2309) <div class="paragraph"><p><strong>privoxy</strong>(1), <strong>tsocks</strong>(1), <strong>torify</strong>(1)<br /></p></div>
2310) <div class="paragraph"><p><strong>https://www.torproject.org/</strong></p></div>
2311) </div>
2312) <h2 id="_bugs">BUGS</h2>
2313) <div class="sectionbody">
2314) <div class="paragraph"><p>Plenty, probably. Tor is still in development. Please report them.</p></div>
2315) </div>
2316) <h2 id="_authors">AUTHORS</h2>
2317) <div class="sectionbody">
2318) <div class="paragraph"><p>Roger Dingledine [arma at mit.edu], Nick Mathewson [nickm at alum.mit.edu].</p></div>
2319) </div>
2320) </div>
|
first cut of the new, shiny...
looks like we never set the...
include stable man page fro...
Update wiki links