socks-extensions.txt 4.1 KB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677787980818283848586878889909192939495969798
  1. Tor's extensions to the SOCKS protocol
  2. 1. Overview
  3. The SOCKS protocol provides a generic interface for TCP proxies. Client
  4. software connects to a SOCKS server via TCP, and requests a TCP connection
  5. to another address and port. The SOCKS server establishes the connection,
  6. and reports success or failure to the client. After the connection has
  7. been established, the client application uses the TCP stream as usual.
  8. Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and
  9. SOCKS5 as defined in [3].
  10. The stickiest issue for Tor in supporting clients, in practice, is forcing
  11. DNS lookups to occur at the OR side: if clients do their own DNS lookup,
  12. the DNS server can learn which addresses the client wants to reach.
  13. SOCKS4 supports addressing by IPv4 address; SOCKS4A is a kludge on top of
  14. SOCKS4 to allow addressing by hostname; SOCKS5 supports IPv4, IPv6, and
  15. hostnames.
  16. 1.1. Extent of support
  17. Tor supports the SOCKS4, SOCKS4A, and SOCKS5 standards, except as follows:
  18. BOTH:
  19. - The BIND command is not supported.
  20. SOCKS4,4A:
  21. - SOCKS4 usernames are used to implement stream isolation.
  22. SOCKS5:
  23. - The (SOCKS5) "UDP ASSOCIATE" command is not supported.
  24. - IPv6 is not supported in CONNECT commands.
  25. - The "NO AUTHENTICATION REQUIRED" (SOCKS5) authentication method [00] is
  26. supported; and as of Tor 0.2.3.2-alpha, the "USERNAME/PASSWORD" (SOCKS5)
  27. authentication method [02] is supported too, and used as a method to
  28. implement stream isolation. As an extension to support some broken clients,
  29. we allow clients to pass "USERNAME/PASSWORD" authentication to us even if
  30. no authentication was selected.
  31. (For more information on stream isolation, see IsolateSOCKSAuth on the Tor
  32. manpage.)
  33. 2. Name lookup
  34. As an extension to SOCKS4A and SOCKS5, Tor implements a new command value,
  35. "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates
  36. a remote lookup of the hostname provided as the target address in the SOCKS
  37. request. The reply is either an error (if the address couldn't be
  38. resolved) or a success response. In the case of success, the address is
  39. stored in the portion of the SOCKS response reserved for remote IP address.
  40. (We support RESOLVE in SOCKS4 too, even though it is unnecessary.)
  41. For SOCKS5 only, we support reverse resolution with a new command value,
  42. "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with
  43. an IPv4 address as its target, Tor attempts to find the canonical
  44. hostname for that IPv4 record, and returns it in the "server bound
  45. address" portion of the reply.
  46. (This command was not supported before Tor 0.1.2.2-alpha.)
  47. 3. Other command extensions.
  48. Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" [F2].
  49. In this case, Tor will open an encrypted direct TCP connection to the
  50. directory port of the Tor server specified by address:port (the port
  51. specified should be the ORPort of the server). It uses a one-hop tunnel
  52. and a "BEGIN_DIR" relay cell to accomplish this secure connection.
  53. The F2 command value was removed in Tor 0.2.0.10-alpha in favor of a
  54. new use_begindir flag in edge_connection_t.
  55. 4. HTTP-resistance
  56. Tor checks the first byte of each SOCKS request to see whether it looks
  57. more like an HTTP request (that is, it starts with a "G", "H", or "P"). If
  58. so, Tor returns a small webpage, telling the user that his/her browser is
  59. misconfigured. This is helpful for the many users who mistakenly try to
  60. use Tor as an HTTP proxy instead of a SOCKS proxy.
  61. 5. Optimistic data
  62. Tor allows SOCKS clients to send connection data before Tor has sent a
  63. SOCKS response. When using an exit node that supports "optimistic data",
  64. Tor will send such data to the server without waiting to see whether the
  65. connection attempt succeeds. This behavior can save a single round-trip
  66. time when starting connections with a protocol where the client speaks
  67. first (like HTTP). Clients that do this must be ready to hear that
  68. their connection has succeeded or failed _after_ they have sent the
  69. data.
  70. References:
  71. [1] http://en.wikipedia.org/wiki/SOCKS#SOCKS4
  72. [2] http://en.wikipedia.org/wiki/SOCKS#SOCKS4a
  73. [3] SOCKS5: RFC1928