diff options
| -rw-r--r-- | socks-extensions.txt | 60 | ||||
| -rw-r--r-- | tor-spec.txt | 22 |
2 files changed, 82 insertions, 0 deletions
diff --git a/socks-extensions.txt b/socks-extensions.txt new file mode 100644 index 0000000..fabf28f --- /dev/null +++ b/socks-extensions.txt @@ -0,0 +1,60 @@ +$Id$ +Tor's extensions to the SOCKS protocol + +1. Overview + + The SOCKS protocol provides a generic interface for TCP proxies. Client + software connects to a SOCKS server via TCP, and requests a TCP connection + to another address and port. The SOCKS server establishes the connection, + and reports success or failure to the client. After the connection has + been established, the client application uses the TCP stream as usual. + + Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and + SOCKS5 as defined in [3]. + + The stickiest issue for Tor in supporting clients, in practice, is forcing + DNS lookups to occur at the OR side: if clients do their own DNS lookup, + the DNS server can learn which addresses the client wants to reach. + SOCKS4 supports addressing by IPv4 address; SOCKS4A is a kludge on top of + SOCKS4 to allow addressing by hostname; SOCKS5 supports IPv4, IPv6, and + hostnames. + +1.1. Extent of support + + Tor supports the SOCKS4, SOCKS4A, and SOCKS5 standards, except as follows: + + BOTH: + - The BIND command is not supported. + + SOCKS4,4A: + - SOCKS4 usernames are ignored. + + SOCKS5: + - The (SOCKS5) "UDP ASSOCIATE" command is not supported. + - IPv6 is not supported in CONNECT commands. + - Only the "NO AUTHENTICATION" (SOCKS5) authentication method [00] is + supported. + +2. Name lookup + + As an extension to SOCKS4A and SOCKS5, Tor implements a new command value, + "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates + a remote lookup of the hostname provided as the target address in the SOCKS + request. The reply is either an error (if the address couldn't be + resolved) or a success response. In the case of success, the address is + stored in the portion of the SOCKS response reserved for remote IP address. + + (We support RESOLVE in SOCKS4A too, even though it is unnecessary.) + +3. HTTP-resistance + + Tor checks the first byte of each socks request to see whether it looks + more like an HTTP request (that is, it starts with a "G", "H", or "P"). If + so, Tor returns a small webpage, telling the user that his/her browser is + misconfigured. This is helpful for the many users who mistakenly try to + use Tor as an HTTP proxy instead of a SOCKS proxy. + +References: + [1] http://archive.socks.permeo.com/protocol/socks4.protocol + [2] http://archive.socks.permeo.com/protocol/socks4a.protocol + [3] SOCKS5: RFC1928 diff --git a/tor-spec.txt b/tor-spec.txt index 3f909cd..d9940bc 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -360,6 +360,8 @@ TODO: (very soon) 8 -- RELAY_TRUNCATE 9 -- RELAY_TRUNCATED 10 -- RELAY_DROP + 11 -- RELAY_RESOLVE + 12 -- RELAY_RESOLVED The 'Recognized' field in any unencrypted relay payload is always set to zero; the 'digest' field is computed as the first four bytes @@ -465,6 +467,26 @@ TODO: (very soon) If an edge node encounters an error on any stream, it sends a 'RELAY_END' cell (if possible) and closes the stream immediately. +5.4. Remote hostname lookup + + To find the address associated with a hostname, the OP sends a + RELAY_RESOLVE cell containing the hostname to be resolved. The OR + replies with an RELAY_RESOLVED cell containing a status byte, and any + number of answers. Each answer is of the form: + Type (1 octet) + Length (1 octet) + Value (variable-width) + "Length" is the length of the Value field. "Type" is one of: + 0x04 -- IPv4 address + 0x06 -- IPv6 address + 0xF0 -- Error, transient + 0xF1 -- Error, nontransient + + If any answer has a type of 'Error', then no other answer may be given. + + The RELAY_RESOLVE cell must use a nonzero, distinct streamID; the + corresponding RELAY_RESOLVED cell must use the same streamID. No stream + is actually created by the OR when resolving the name. 6. Flow control |