SOCKS

Last updated

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]

Contents

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, [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]

Acronym

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.

Usage

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:

Protocol

SOCKS4

A typical SOCKS4 connection request looks like this:

First packet to server
VERCMDDSTPORTDSTIPID
Byte Count1124Variable
VER
SOCKS version number, 0x04 for this version
CMD
command code:
  • 0x01 = establish a TCP/IP stream connection
  • 0x02 = establish a TCP/IP port binding
DSTPORT
2-byte port number (in network byte order)
DESTIP
IPv4 Address, 4 bytes (in network byte order)
ID
the user ID string, variable length, null-terminated.
Response packet from server
VNREPDSTPORTDSTIP
Byte Count1124
VN
reply version, null byte
REP
reply code
ByteMeaning
0x5ARequest granted
0x5BRequest rejected or failed
0x5CRequest failed because client is not running identd (or not reachable from server)
0x5DRequest failed because client's identd could not confirm the user ID in the request
DSTPORT
destination port, meaningful if granted in BIND, otherwise ignore
DSTIP
destination IP, as above the ip:port the client should bind to

For example, this is 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; 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:

First packet to server
SOCKS4_CDOMAIN
Byte Count8+variablevariable
SOCKS4_C
SOCKS4 client handshake packet (above)
DOMAIN
the domain name of the host to contact , null (0x00) terminated

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.

SOCKS5

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:

Client greeting
VERNAUTHAUTH
Byte count11variable
VER
SOCKS version (0x05)
NAUTH
Number of authentication methods supported, uint8
AUTH
Authentication methods, 1 byte per method supported
The authentication methods supported are numbered as follows:
  • 0x00: No authentication
  • 0x01: GSSAPI ( RFC   1961)
  • 0x02: Username/password ( RFC   1929)
  • 0x03–0x7F: methods assigned by IANA [17]
    • 0x03: Challenge–Handshake Authentication Protocol
    • 0x04: Unassigned
    • 0x05: Challenge–Response Authentication Method
    • 0x06: Secure Sockets Layer
    • 0x07: NDS Authentication
    • 0x08: Multi-Authentication Framework
    • 0x09: JSON Parameter Block
    • 0x0A–0x7F: Unassigned
  • 0x80–0xFE: methods reserved for private use
Server choice
VERCAUTH
Byte count11
VER
SOCKS version (0x05)
CAUTH
chosen authentication method, or 0xFF if no acceptable methods were offered

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

Client authentication request, 0x02
VERIDLENIDPWLENPW
Byte count11(1–255)1(1–255)
VER
0x01 for current version of username/password authentication
IDLEN, ID
Username length, uint8; username as bytestring
PWLEN, PW
Password length, uint8; password as bytestring
Server response, 0x02
VERSTATUS
Byte count11
VER
0x01 for current version of username/password authentication
STATUS
0x00 success, otherwise failure, connection must be closed

After authentication the connection can proceed. We first define an address datatype as:

SOCKS5 address
TYPEADDR
Byte Count1variable
TYPE
type of the address. One of:
  • 0x01: IPv4 address
  • 0x03: Domain name
  • 0x04: IPv6 address
ADDR
the address data that follows. Depending on type:
  • 4 bytes for IPv4 address
  • 1 byte of name length followed by 1–255 bytes for the domain name
  • 16 bytes for IPv6 address
Client connection request
VERCMDRSVDSTADDRDSTPORT
Byte Count111Variable2
VER
SOCKS version (0x05)
CMD
command code:
  • 0x01: establish a TCP/IP stream connection
  • 0x02: establish a TCP/IP port binding
  • 0x03: associate a UDP port
RSV
reserved, must be 0x00
DSTADDR
destination address, see the address structure above.
DSTPORT
port number in a network byte order
Response packet from server
VERSTATUSRSVBNDADDRBNDPORT
Byte Count111variable2
VER
SOCKS version (0x05)
STATUS
status code:
  • 0x00: request granted
  • 0x01: general failure
  • 0x02: connection not allowed by ruleset
  • 0x03: network unreachable
  • 0x04: host unreachable
  • 0x05: connection refused by destination host
  • 0x06: TTL expired
  • 0x07: command not supported / protocol error
  • 0x08: address type not supported
RSV
reserved, must be 0x00
BNDADDR
server bound address in the "SOCKS5 address" format specified above
BNDPORT
server bound port number in a network byte order

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]

Software

Servers

SOCKS proxy server implementations

  • Sun Java System Web Proxy Server is a caching proxy server running on Solaris, Linux and Windows servers that support HTTPS, NSAPI I/O filters, dynamic reconfiguration, SOCKSv5 and reverse proxy.
  • WinGate is a multi-protocol proxy server and SOCKS server for Microsoft Windows which supports SOCKS4, SOCKS4a and SOCKS5 (including UDP-ASSOCIATE and GSSAPI auth). It also supports handing over SOCKS connections to the HTTP proxy, so can cache and scan HTTP over SOCKS.
  • Socksgate5 SocksGate5 is an application-SOCKS firewall with inspection feature on Layer 7 of the OSI model, the Application Layer. Because packets are inspected at 7 OSI Level the application-SOCKS firewall may search for protocol non-compliance and blocking specified content.
  • Dante is a circuit-level SOCKS server that can be used to provide convenient and secure network connectivity, requiring only the host Dante runs on to have external network connectivity. [19]

Other programs providing SOCKS server interface

  • OpenSSH allows dynamic creation of tunnels, specified via a subset of the SOCKS protocol, supporting the CONNECT command.
  • PuTTY is a Win32 SSH client that supports local creation of SOCKS (dynamic) tunnels through remote SSH servers.
  • Secure ShellFish is a SSH client for iOS and macOS that includes a SOCKS server.
  • ShimmerCat [20] is a web server that uses SOCKS5 to simulate an internal network, allowing web developers to test their local sites without modifying their /etc/hosts file.
  • Tor is a system intended to enable online anonymity. Tor offers a TCP-only SOCKS server interface to its clients.
  • Shadowsocks is a circumvent censorship tool. It provides a SOCKS5 interface.
  • netcat implementations, as Ncat and socat.

Clients

Client software must have native SOCKS support in order to connect through SOCKS.

Browser

  • Chrome: support SOCKS4, SOCKS4a and SOCKS5. [21]
  • Firefox: support SOCKS4, SOCKS4a and SOCKS5.
  • Internet Explorer and EdgeHTML-based Microsoft Edge: support SOCKS4 only.
  • Chromium-based Microsoft Edge: support SOCKS4, SOCKS4a and SOCKS5.

There are programs that allow users to circumvent such limitations:

Socksifiers

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.

  • Win2Socks, which enables applications to access the network through SOCKS5, HTTPS or Shadowsocks.
  • tun2socks, an open source tool that creates virtual TCP TUN adapters from a SOCKS proxy, capable of UDP if supported on another end. Works on Linux and Windows, [22] has a macOS port and reimplementation in Golang. [23]
  • proxychains, a Unix program that forces TCP traffic through SOCKS or HTTP proxies on (dynamically-linked) programs it launches. Works on various Unix-like systems. [24]

Translating proxies

  • Polipo, a discontinued forwarding and caching HTTP/1.1 proxy server with IPv4 support. Open Source running on Linux, OpenWrt, Windows, Mac OS X, and FreeBSD. Almost any Web browser can use it.
  • Privoxy, a non-caching SOCKS-to-HTTP proxy.
  • Tinyproxy, a light-weight HTTP/HTTPS proxy daemon for POSIX operating systems. Designed from the ground up to be fast and yet small. It presents an http proxy interface and can connect to SOCKS4/5 and http upstream proxies.

Security

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.

Related Research Articles

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

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.

<span class="mw-page-title-main">Email client</span> Computer program used to access and manage a users email

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.

<span class="mw-page-title-main">Port forwarding</span> Computer networking feature

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.

References

  1. "Service Name and Transport Protocol Port Number Registry". Internet Assigned Numbers Authority. 19 May 2017. Retrieved 23 May 2017.
  2. 1 2 Koblas, David; Koblas, Michelle R. SOCKS (PDF). USENIX UNIX Security Symposium III . Retrieved 16 November 2019.
  3. Darmohray, Tina. "Firewalls and fairy tales". ;LOGIN:. Vol 30, no. 1.
  4. Archive index at the Wayback Machine
  5. CNET: Cyberspace from outer space
  6. US US8984268B2
  7. US US20210058367A1
  8. US US11190374B2
  9. JP JP6761452B2
  10. US US11425565B2
  11. RFC 1928. doi: 10.17487/RFC1928 .
  12. Oppliger, Rolf (2003). "Circuit-level gateways". Security technologies for the World Wide Web (2nd ed.). Artech House. ISBN   1580533485 . Retrieved 21 January 2020.
  13. "2010 Circumvention Tool Usage Report" (PDF). The Berkman Center for Internet & Society at Harvard University. October 2010.
  14. "Tor FAQ".
  15. "OpenSSH FAQ". Archived from the original on 2002-02-01.
  16. Ying-Da Lee. "SOCKS 4A: A Simple Extension to SOCKS 4 Protocol". OpenSSH. Retrieved 2013-04-03.
  17. IANA.org
  18. "CURLOPT_PROXY". curl.se. Retrieved 20 January 2020.
  19. "Products developed by Inferno Nettverk A/S". www.inet.no. Retrieved 2021-03-20.
  20. "Easy Net with SOCKS5". shimmercat.com. ShimmerCat. Archived from the original on 2018-09-13. Retrieved 20 April 2016.
  21. "Configuring a SOCKS proxy server in Chrome". www.chromium.org. Retrieved 2024-03-19.
  22. Bizjak, Ambroz (20 January 2020). "ambrop72/badvpn: NCD scripting language, tun2socks proxifier, P2P VPN". GitHub. Retrieved 20 January 2020.
  23. "xjasonlyu/tun2socks: tun2socks - powered by gVisor TCP/IP stack". GitHub.
  24. Hamsik, Adam (20 January 2020). "proxychains: a tool that forces any TCP connection made by any given application to follow through proxy like TOR or any other SOCKS4, SOCKS5 or HTTP(S) proxy". GitHub. Retrieved 20 January 2020.