Internet protocol suite |
---|
Application layer |
Transport layer |
Internet layer |
Link layer |
SOCKS is an Internet protocol that exchanges network packets between a client and server through a proxy server. SOCKS5 optionally 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. A SOCKS server accepts incoming client connection on TCP port 1080, as defined in RFC 1928. [1]
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, [2] making SOCKS publicly available. [3] The protocol was extended to version 4 by Ying-Da Lee of NEC.
The SOCKS reference architecture and client are owned by Permeo Technologies, [4] a spin-off from NEC. (Blue Coat Systems bought out Permeo Technologies, and were in turn acquired by Symantec.)
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 as RFC 1928 (authored by: M. Leech, M. Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones). The protocol was developed in collaboration with Aventail Corporation, which markets the technology outside of Asia. [5]
SOCKS is sometimes defined as an acronym for "socket secure" from at least 2001, [6] [7] [8] [9] [10] although it was not originally defined as such in the SOCKS Protocol Version 5 RFC in 1996 [11] or the UNIX Security Symposium III paper in 1992 [2] but simply referred to a specific proxy protocol designed to facilitate communication between clients and servers through a firewall.
SOCKS is a de facto standard for circuit-level gateways (level 5 gateways). [12]
The circuit/session level nature of SOCKS make it a versatile tool in forwarding any TCP (or UDP since SOCKS5) traffic, creating an interface for all types of routing tools. It can be used as:
A typical SOCKS4 connection request looks like this:
VER | CMD | DSTPORT | DSTIP | ID | |
---|---|---|---|---|---|
Byte Count | 1 | 1 | 2 | 4 | Variable |
VN | REP | DSTPORT | DSTIP | |
---|---|---|---|---|
Byte Count | 1 | 1 | 2 | 4 |
Byte | Meaning |
---|---|
0x5A | Request granted |
0x5B | Request rejected or failed |
0x5C | Request failed because client is not running identd (or not reachable from server) |
0x5D | Request failed because client's identd could not confirm the user ID in the request |
For example, this is a SOCKS4 request to connect Fred to 66.102.7.99:80, the server replies with an "OK":
0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
0x00 | 0x5A | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX
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 extends the SOCKS4 protocol to allow a client to specify a destination domain name rather than an IP address; this is useful when the client itself cannot resolve the destination host's domain name to an IP address. It was proposed by Ying-Da Lee, the author of SOCKS4. [16]
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:
SOCKS4_C | DOMAIN | |
---|---|---|
Byte Count | 8+variable | variable |
Server to SOCKS client: (Same as SOCKS4)
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.
The SOCKS5 protocol is defined in RFC 1928. It is an incompatible 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 initial greeting from the client is:
VER | NAUTH | AUTH | |
---|---|---|---|
Byte count | 1 | 1 | variable |
VER | CAUTH | |
---|---|---|
Byte count | 1 | 1 |
The subsequent authentication is method-dependent. Username and password authentication (method 0x02) is described in RFC 1929:
VER | IDLEN | ID | PWLEN | PW | |
---|---|---|---|---|---|
Byte count | 1 | 1 | (1–255) | 1 | (1–255) |
VER | STATUS | |
---|---|---|
Byte count | 1 | 1 |
After authentication the connection can proceed. We first define an address datatype as:
TYPE | ADDR | |
---|---|---|
Byte Count | 1 | variable |
VER | CMD | RSV | DSTADDR | DSTPORT | |
---|---|---|---|---|---|
Byte Count | 1 | 1 | 1 | Variable | 2 |
VER | STATUS | RSV | BNDADDR | BNDPORT | |
---|---|---|---|---|---|
Byte Count | 1 | 1 | 1 | variable | 2 |
Since clients are allowed to use either resolved addresses or domain names, a convention from cURL exists to label the domain name variant of SOCKS5 "socks5h", and the other simply "socks5". A similar convention exists between SOCKS4a and SOCKS4. [18]
Client software must have native SOCKS support in order to connect through SOCKS.
There are programs that allow users to circumvent such limitations:
Socksifiers allow applications to access the networks to use a proxy without needing to support any proxy protocols. The most common way is to set up a virtual network adapter and appropriate routing tables to send traffic through the adapter.
Due to lack of request and packets exchange encryption it makes SOCKS practically vulnerable to man-in-the-middle attacks and IP addresses eavesdropping which in consequence clears a way to censorship by governments.
The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.
The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.
Telnet is a client/server application protocol that provides access to virtual terminals of remote systems on local area networks or the Internet. It is a protocol for bidirectional 8-bit communications. Its main goal was to connect terminal devices and terminal-oriented processes.
An email client, email reader or, more formally, message user agent (MUA) or mail user agent is a computer program used to access and manage a user's email.
The File Transfer Protocol (FTP) is a standard communication protocol used for the transfer of computer files from a server to a client on a computer network. FTP is built on a client–server model architecture using separate control and data connections between the client and the server. FTP users may authenticate themselves with a plain-text sign-in protocol, normally in the form of a username and password, but can connect anonymously if the server is configured to allow it. For secure transmission that protects the username and password, and encrypts the content, FTP is often secured with SSL/TLS (FTPS) or replaced with SSH File Transfer Protocol (SFTP).
A virtual private network (VPN) is a mechanism for creating a secure connection between a computing device and a computer network, or between two networks, using an insecure communication medium such as the public Internet.
Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.
OBEX is a communication protocol that facilitates the exchange of binary objects between devices. It is maintained by the Infrared Data Association but has also been adopted by the Bluetooth Special Interest Group and the SyncML wing of the Open Mobile Alliance (OMA). One of OBEX's earliest popular applications was in the Palm III. This PDA and its many successors use OBEX to exchange business cards, data, even applications.
Modbus or MODBUS is a client/server data communications protocol in the application layer. It was originally published by Modicon in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and network.
The Berkeley r-commands are a suite of computer programs designed to enable users of one Unix system to log in or issue commands to another Unix computer via TCP/IP computer network. The r-commands were developed in 1982 by the Computer Systems Research Group at the University of California, Berkeley, based on an early implementation of TCP/IP.
In computer networking, port forwarding or port mapping is an application of network address translation (NAT) that redirects a communication request from one address and port number combination to another while the packets are traversing a network gateway, such as a router or firewall. This technique is most commonly used to make services on a host residing on a protected or masqueraded (internal) network available to hosts on the opposite side of the gateway, by remapping the destination IP address and port number of the communication to an internal host.
Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the Internet protocol suite.
FTPS is an extension to the commonly used File Transfer Protocol (FTP) that adds support for the Transport Layer Security (TLS) and, formerly, the Secure Sockets Layer cryptographic protocols.
In computer networks, a tunneling protocol is a communication protocol which allows for the movement of data from one network to another. It can, for example, allow private network communications to be sent across a public network, or for one network protocol to be carried over an incompatible network, through a process called encapsulation.
Real-Time Messaging Protocol (RTMP) is a communication protocol for streaming audio, video, and data over the Internet. Originally developed as a proprietary protocol by Macromedia for streaming between Flash Player and the Flash Communication Server, Adobe has released an incomplete version of the specification of the protocol for public use.
In a Windows network, NT LAN Manager (NTLM) is a suite of Microsoft security protocols intended to provide authentication, integrity, and confidentiality to users. NTLM is the successor to the authentication protocol in Microsoft LAN Manager (LANMAN), an older Microsoft product. The NTLM protocol suite is implemented in a Security Support Provider, which combines the LAN Manager authentication protocol, NTLMv1, NTLMv2 and NTLM2 Session protocols in a single package. Whether these protocols are used or can be used on a system which is governed by Group Policy settings, for which different versions of Windows have different default settings.
Cisco HDLC (cHDLC) is an extension to the High-Level Data Link Control (HDLC) network protocol, and was created by Cisco Systems, Inc. HDLC is a bit-oriented synchronous data link layer protocol that was originally developed by the International Organization for Standardization (ISO). Often described as being a proprietary extension, the details of cHDLC have been widely distributed and the protocol has been implemented by many network equipment vendors. cHDLC extends HDLC with multi-protocol support.
TaZmen Sniffer Protocol (TZSP) is an encapsulation protocol used to wrap other protocols. It is commonly used to wrap 802.11 wireless packets to support Intrusion Detection Systems (IDS), wireless tracking, or other wireless applications.
Action Message Format (AMF) is a binary format used to serialize object graphs such as ActionScript objects and XML, or send messages between an Adobe Flash client and a remote service, usually a Flash Media Server or third party alternatives. The Actionscript 3 language provides classes for encoding and decoding from the AMF format.
The Ident Protocol, specified in RFC 1413, is an Internet protocol that helps identify the user of a particular TCP connection. One popular daemon program for providing the ident service is identd.