From 7911a1d89e3c9ac3e706b067194e3ad89e0e3f5f Mon Sep 17 00:00:00 2001 From: Nick Mathewson Date: Thu, 17 Jun 2004 18:11:31 +0000 Subject: document socks extensions and dns lookup code svn:r1976 --- socks-extensions.txt | 60 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 socks-extensions.txt (limited to 'socks-extensions.txt') 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 -- cgit v1.2.3-54-g00ecf