control-spec.txt

$Id: control-spec.txt 18287 2009-01-28 06:50:36Z arma $

                   TC: A Tor control protocol (Version 1)

0. Scope

  This document describes an implementation-specific protocol that is used
  for other programs (such as frontend user-interfaces) to communicate with a
  locally running Tor process.  It is not part of the Tor onion routing
  protocol.

  This protocol replaces version 0 of TC, which is now deprecated.  For
  reference, TC is described in "control-spec-v0.txt".  Implementors are
  recommended to avoid using TC directly, but instead to use a library that
  can easily be updated to use the newer protocol.  (Version 0 is used by Tor
  versions 0.1.0.x; the protocol in this document only works with Tor
  versions in the 0.1.1.x series and later.)

1. Protocol outline

  TC is a bidirectional message-based protocol.  It assumes an underlying
  stream for communication between a controlling process (the "client"
  or "controller") and a Tor process (or "server").  The stream may be
  implemented via TCP, TLS-over-TCP, a Unix-domain socket, or so on,
  but it must provide reliable in-order delivery.  For security, the
  stream should not be accessible by untrusted parties.

  In TC, the client and server send typed messages to each other over the
  underlying stream.  The client sends "commands" and the server sends
  "replies".

  By default, all messages from the server are in response to messages from
  the client.  Some client requests, however, will cause the server to send
  messages to the client indefinitely far into the future.  Such
  "asynchronous" replies are marked as such.

  Servers respond to messages in the order messages are received.

2. Message format

2.1. Description format

  The message formats listed below use ABNF as described in RFC 2234.
  The protocol itself is loosely based on SMTP (see RFC 2821).

  We use the following nonterminals from RFC 2822: atom, qcontent

  We define the following general-use nonterminals:

     String = DQUOTE *qcontent DQUOTE

  There are explicitly no limits on line length.  All 8-bit characters are
  permitted unless explicitly disallowed.

  Wherever CRLF is specified to be accepted from the controller, Tor MAY also
  accept LF.  Tor, however, MUST NOT generate LF instead of CRLF.
  Controllers SHOULD always send CRLF.

2.2. Commands from controller to Tor

    Command = Keyword Arguments CRLF / "+" Keyword Arguments CRLF Data
    Keyword = 1*ALPHA
    Arguments = *(SP / VCHAR)

  Specific commands and their arguments are described below in section 3.

2.3. Replies from Tor to the controller

    Reply = SyncReply / AsyncReply
    SyncReply = *(MidReplyLine / DataReplyLine) EndReplyLine
    AsyncReply = *(MidReplyLine / DataReplyLine) EndReplyLine

    MidReplyLine = StatusCode "-" ReplyLine
    DataReplyLine = StatusCode "+" ReplyLine Data
    EndReplyLine = StatusCode SP ReplyLine
    ReplyLine = [ReplyText] CRLF
    ReplyText = XXXX
    StatusCode = 3DIGIT

  Specific replies are mentioned below in section 3, and described more fully
  in section 4.

  [Compatibility note:  versions of Tor before 0.2.0.3-alpha sometimes
  generate AsyncReplies of the form "*(MidReplyLine / DataReplyLine)".
  This is incorrect, but controllers that need to work with these
  versions of Tor should be prepared to get multi-line AsyncReplies with
  the final line (usually "650 OK") omitted.]

2.4. General-use tokens

  ; Identifiers for servers.
  ServerID = Nickname / Fingerprint

  Nickname = 1*19 NicknameChar
  NicknameChar = "a"-"z" / "A"-"Z" / "0" - "9"
  Fingerprint = "$" 40*HEXDIG

  ; A "=" indicates that the given nickname is canonical; a "~" indicates
  ; that the given nickname is not canonical.
  LongName = Fingerprint [ ( "=" / "~" ) Nickname ]

  ; How a controller tells Tor about a particular OR.  There are four
  ; possible formats:
  ;    $Digest -- The router whose identity key hashes to the given digest.
  ;        This is the preferred way to refer to an OR.
  ;    $Digest~Name -- The router whose identity key hashes to the given
  ;        digest, but only if the router has the given nickname.
  ;    $Digest=Name -- The router whose identity key hashes to the given
  ;        digest, but only if the router is Named and has the given
  ;        nickname.
  ;    Name -- The Named router with the given nickname, or, if no such
  ;        router exists, any router whose nickname matches the one given.
  ;        This is not a safe way to refer to routers, since Named status
  ;        could under some circumstances change over time.
  ServerSpec = LongName / Nickname

  ; Unique identifiers for streams or circuits.  Currently, Tor only
  ; uses digits, but this may change
  StreamID = 1*16 IDChar
  CircuitID = 1*16 IDChar
  IDChar = ALPHA / DIGIT

  Address = ip4-address / ip6-address / hostname   (XXXX Define these)

  ; A "Data" section is a sequence of octets concluded by the terminating
  ; sequence CRLF "." CRLF.  The terminating sequence may not appear in the
  ; body of the data.  Leading periods on lines in the data are escaped with
  ; an additional leading period as in RFC 2821 section 4.5.2.
  Data = *DataLine "." CRLF
  DataLine = CRLF / "." 1*LineItem CRLF / NonDotItem *LineItem CRLF
  LineItem = NonCR / 1*CR NonCRLF
  NonDotItem = NonDotCR / 1*CR NonCRLF

3. Commands

  All commands are case-insensitive, but most keywords are case-sensitive.

3.1. SETCONF

  Change the value of one or more configuration variables.  The syntax is:

    "SETCONF" 1*(SP keyword ["=" value]) CRLF
    value = String / QuotedString

  Tor behaves as though it had just read each of the key-value pairs
  from its configuration file.  Keywords with no corresponding values have
  their configuration values reset to 0 or NULL (use RESETCONF if you want
  to set it back to its default).  SETCONF is all-or-nothing: if there
  is an error in any of the configuration settings, Tor sets none of them.

  Tor responds with a "250 configuration values set" reply on success.
  If some of the listed keywords can't be found, Tor replies with a
  "552 Unrecognized option" message. Otherwise, Tor responds with a
  "513 syntax error in configuration values" reply on syntax error, or a
  "553 impossible configuration setting" reply on a semantic error.

  When a configuration option takes multiple values, or when multiple
  configuration keys form a context-sensitive group (see GETCONF below), then
  setting _any_ of the options in a SETCONF command is taken to reset all of
  the others.  For example, if two ORBindAddress values are configured, and a
  SETCONF command arrives containing a single ORBindAddress value, the new
  command's value replaces the two old values.

  Sometimes it is not possible to change configuration options solely by
  issuing a series of SETCONF commands, because the value of one of the
  configuration options depends on the value of another which has not yet
  been set. Such situations can be overcome by setting multiple configuration
  options with a single SETCONF command (e.g. SETCONF ORPort=443
  ORListenAddress=9001).

3.2. RESETCONF

  Remove all settings for a given configuration option entirely, assign
  its default value (if any), and then assign the String provided.
  Typically the String is left empty, to simply set an option back to
  its default. The syntax is:

    "RESETCONF" 1*(SP keyword ["=" String]) CRLF

  Otherwise it behaves like SETCONF above.

3.3. GETCONF

  Request the value of a configuration variable.  The syntax is:

    "GETCONF" 1*(SP keyword) CRLF

  If all of the listed keywords exist in the Tor configuration, Tor replies
  with a series of reply lines of the form:
      250 keyword=value
  If any option is set to a 'default' value semantically different from an
  empty string, Tor may reply with a reply line of the form:
      250 keyword

  Value may be a raw value or a quoted string.  Tor will try to use
  unquoted values except when the value could be misinterpreted through
  not being quoted.

  If some of the listed keywords can't be found, Tor replies with a
  "552 unknown configuration keyword" message.

  If an option appears multiple times in the configuration, all of its
  key-value pairs are returned in order.

  Some options are context-sensitive, and depend on other options with
  different keywords.  These cannot be fetched directly.  Currently there
  is only one such option: clients should use the "HiddenServiceOptions"
  virtual keyword to get all HiddenServiceDir, HiddenServicePort,
  HiddenServiceNodes, and HiddenServiceExcludeNodes option settings.

3.4. SETEVENTS

  Request the server to inform the client about interesting events.  The
  syntax is:

     "SETEVENTS" [SP "EXTENDED"] *(SP EventCode) CRLF

     EventCode = "CIRC" / "STREAM" / "ORCONN" / "BW" / "DEBUG" /
         "INFO" / "NOTICE" / "WARN" / "ERR" / "NEWDESC" / "ADDRMAP" /
         "AUTHDIR_NEWDESCS" / "DESCCHANGED" / "STATUS_GENERAL" /
         "STATUS_CLIENT" / "STATUS_SERVER" / "GUARD" / "NS" / "STREAM_BW" /
         "CLIENTS_SEEN"

  Any events *not* listed in the SETEVENTS line are turned off; thus, sending
  SETEVENTS with an empty body turns off all event reporting.

  The server responds with a "250 OK" reply on success, and a "552
  Unrecognized event" reply if one of the event codes isn't recognized.  (On
  error, the list of active event codes isn't changed.)

  If the flag string "EXTENDED" is provided, Tor may provide extra
  information with events for this connection; see 4.1 for more information.
  NOTE: All events on a gi...