[go: up one dir, main page]
Jump to content

SOCKS

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Yoshi24517 (talk | contribs) at 22:21, 2 November 2023 (Reverted edits by 159.0.207.217 (talk): why? (HG) (3.4.12)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

This article is about the internet protocol. For other uses, see Socks (disambiguation).
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.

SOCKS performs at Layer 5 of the OSI model (the session layer, an intermediate layer between the presentation layer and the transport layer). A SOCKS server accepts incoming client connection on TCP port 1080, as defined in RFC 1928.[1]

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:

  • 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.[13] Since SOCKS is very detectable, a common approach is to present a SOCKS interface for more sophisticated protocols:
    • The Tor onion proxy software presents a SOCKS interface to its clients.[14]
  • Providing similar functionality to a virtual private network, allowing connections to be forwarded to a server's "local" network:
    • Some SSH suites, such as OpenSSH, support dynamic port forwarding that allows the user to create a local SOCKS proxy.[15] This can free the user from the limitations of connecting only to a predefined remote port and server.

Protocol

SOCKS4

A typical SOCKS4 connection request looks like this:

First packet to server
VER CMD DSTPORT DSTIP ID
Byte Count 1 1 2 4 Variable
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
VN REP DSTPORT DSTIP
Byte Count 1 1 2 4
VN
reply version, null byte
REP
reply code
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
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":

  • Client: 0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
    • The last field is "Fred" in ASCII, followed by a null byte.
  • Server: 0x00 | 0x5A | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX
    • 0xXX can be any byte value. The SOCKS4 protocol specifies that the values of these bytes should be ignored.

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_C DOMAIN
Byte Count 8+variable variable
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:

  • Client connects and sends a greeting, which includes a list of authentication methods supported.
  • Server chooses one of the methods (or sends a failure response if none of them are acceptable).
  • Several messages may now pass between the client and the server, depending on the authentication method chosen.
  • Client sends a connection request similar to SOCKS4.
  • Server responds similar to SOCKS4.

The initial greeting from the client is:

Client greeting
VER NAUTH AUTH
Byte count 1 1 variable
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
VER CAUTH
Byte count 1 1
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
VER IDLEN ID PWLEN PW
Byte count 1 1 (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
VER STATUS
Byte count 1 1
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
TYPE ADDR
Byte Count 1 variable
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
VER CMD RSV DSTADDR DSTPORT
Byte Count 1 1 1 Variable 2
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
VER STATUS RSV BNDADDR BNDPORT
Byte Count 1 1 1 variable 2
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 (defined in RFC 1928) 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. 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,[21] has a macOS port and reimplementation in Golang.[22]
  • 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.[23]

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.

References

  1. ^ "Service Name and Transport Protocol Port Number Registry". Internet Assigned Numbers Authority. 19 May 2017. Retrieved 23 May 2017.
  2. ^ a b 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. ^ Bizjak, Ambroz (20 January 2020). "ambrop72/badvpn: NCD scripting language, tun2socks proxifier, P2P VPN". GitHub. Retrieved 20 January 2020.
  22. ^ "xjasonlyu/tun2socks: tun2socks - powered by gVisor TCP/IP stack". GitHub.
  23. ^ 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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=SOCKS&oldid=1183215574"