SOCKS

This article is about the internet protocol. For other uses, see Socks (disambiguation).

Socket Secure (SOCKS) is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 additionally provides authentication so only authorized users may access a server. Practically, a SOCKS server proxies TCP connections to an arbitrary IP address, and provides a means for UDP packets to be forwarded.

SOCKS performs at Layer 5 of the OSI model (the session layer, an intermediate layer between the presentation layer and the transport layer).

History

The protocol was originally developed/designed by David Koblas, a system administrator of MIPS Computer Systems. After MIPS was taken over by Silicon Graphics in 1992, Koblas presented a paper on SOCKS at that year's Usenix Security Symposium, making SOCKS publicly available.[1] The protocol was extended to version 4 by Ying-Da Lee of NEC.

The SOCKS reference architecture and client are owned by Permeo Technologies,[2] a spin-off from NEC. (Blue Coat Systems bought out Permeo Technologies.)

The SOCKS5 protocol was originally a security protocol that made firewalls and other security products easier to administer. It was approved by the IETF in 1996.[3] The protocol was developed in collaboration with Aventail Corporation, which markets the technology outside of Asia.[4]

Usage

SOCKS is a de facto standard for circuit-level gateways.

Another use of SOCKS is as a circumvention tool, allowing traffic to bypass Internet filtering to access content otherwise blocked, e.g., by governments, workplaces, schools, and country-specific web services.[5]

Some SSH suites, such as OpenSSH, support dynamic port forwarding that allows the user to create a local SOCKS proxy.[6] This can free the user from the limitations of connecting only to a predefined remote port and server.

The Tor onion proxy software presents a SOCKS interface to its clients.

Comparison to HTTP proxying

SOCKS operates at a lower level than HTTP proxying: SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make, and then acts as transparently as possible, whereas a regular proxy may interpret and rewrite headers (say, to employ another underlying protocol, such as FTP; however, an HTTP proxy simply forwards an HTTP request to the desired HTTP server). Though HTTP proxying has a different usage model in mind, the CONNECT method allows for forwarding TCP connections; however, SOCKS proxies can also forward UDP traffic and work in reverse, while HTTP proxies cannot. HTTP proxies are traditionally more aware of the HTTP protocol, performing higher-level filtering (though that usually only applies to GET and POST methods, not the CONNECT method).

SOCKS

Bill wishes to communicate with Jane over the internet, but a firewall between them exists on his network, where Bill is not authorized to communicate with Jane directly. So, Bill connects to the SOCKS proxy on his network, informing it about the connection he wishes to make to Jane; the SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Jane.

For more information on the technical specifics of the SOCKS protocol, see the sections below.

HTTP

Bill wishes to download a web page from Jane, who runs a web server. Bill cannot directly connect to Jane's server, as a firewall has been put in place on his network. In order to communicate with the server, Bill connects to his network's HTTP proxy. His web browser communicates with the proxy in exactly the same way that it would directly with Jane's server if that was possible; that is, it sends a standard HTTP request header. The HTTP proxy connects to Jane's server, and then transmits back to Bill any data that Jane's server returns.[7]

Protocol

SOCKS4

A typical SOCKS4 connection request looks like this:

SOCKS client to SOCKS server:

SOCKS server to SOCKS client:

For example, this a SOCKS4 request to connect Fred to 66.102.7.99:80, the server replies with an "OK":

From this point onwards, any data sent from the SOCKS client to the SOCKS server is relayed to 66.102.7.99, and vice versa.

The command field may be 0x01 for "connect" or 0x02 for "bind"; the "bind" command allows incoming connections for protocols such as active FTP.

SOCKS4a

SOCKS4a extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address;[8] this is useful when the client itself cannot resolve the destination host's domain name to an IP address.

The client should set the first three bytes of DSTIP to NULL and the last byte to a non-zero value. (This corresponds to IP address 0.0.0.x, with x nonzero, an inadmissible destination address and thus should never occur if the client can resolve the domain name.) Following the NULL byte terminating USERID, the client must send the destination domain name and terminate it with another NULL byte. This is used for both "connect" and "bind" requests.

Client to SOCKS server:

Server to SOCKS client:

A server using protocol SOCKS4a must check the DSTIP in the request packet. If it represents address 0.0.0.x with nonzero x, the server must read in the domain name that the client sends in the packet. The server should resolve the domain name and make connection to the destination host if it can.

SOCKS5

The SOCKS5 protocol is defined in RFC 1928. It is an extension of the SOCKS4 protocol; it offers more choices for authentication and adds support for IPv6 and UDP, the latter of which can be used for DNS lookups. The initial handshake consists of the following:

The authentication methods supported are numbered as follows:

The initial greeting from the client is

The server's choice is communicated:

The subsequent authentication is method-dependent. Username and password authentication (method 0x02) is described in RFC 1929:

For username/password authentication the client's authentication request is

Server response for username/password authentication:

The client's connection request is

Server response:

Software

Servers

SOCKS proxy server implementations

Other programs providing SOCKS server interface

Clients

Client software must have native SOCKS support in order to connect through SOCKS. There are programs that allow to circumvent this limitation:

Proxifiers

Translating proxies

References

  1. ↑ Darmohray, Tina. "Firewalls and fairy tales". ;LOGIN:. Vol 30, no. 1.
  2. ↑ Archived index at the Wayback Machine.
  3. ↑ RFC 1928
  4. ↑ CNET: Cyberspace from outer space
  5. ↑ "2010 Circumvention Tool Usage Report" (PDF). The Berkman Center for Internet & Society at Harvard University. October 2010.
  6. ↑ "OpenSSH FAQ".
  7. ↑ "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing". Retrieved 2014-08-01.
  8. ↑ Ying-Da Lee. "SOCKS 4A: A Simple Extension to SOCKS 4 Protocol". OpenSSH. Retrieved 2013-04-03.
  9. ↑ "RFC 1961". Tools.ietf.org. Retrieved 2009-06-19.
  10. ↑ "RFC 1929". Tools.ietf.org. Retrieved 2009-06-19.
  11. ↑ IANA.org
  12. ↑ "Easy Net with SOCKS5". shimmercat.com. ShimmerCat. Retrieved 20 April 2016.

External links

This article is issued from Wikipedia - version of the 11/21/2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.