SOCKS explained

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 .[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, 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 (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.[4]

Acronym

SOCKS is sometimes defined as an acronym for "socket secure" from at least 2001,[5] [6] [7] [8] [9] although it was not originally defined as such in the SOCKS Protocol Version 5 RFC in 1996[10] 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).[11]

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!!VER!CMD!DSTPORT!DSTIP!ID
Byte Count1124Variable
VER: SOCKS version number, 0x04 for this version
  • CMD: command code:
    • 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 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.[15]

    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 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 . 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!!VER!NAUTH!AUTH
    scope=rowByte count1 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:
    Server choice!!VER!CAUTH
    scope=rowByte count1 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 :

    Client authentication request, 0x02!!VER!IDLEN!ID!PWLEN!PW
    scope=rowByte count1 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
    scope=rowByte count1 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 Count1variable
    TYPE: type of the address. One of:
    ADDR: the address data that follows. Depending on type:
    Client connection request!!VER!CMD!RSV!DSTADDR!DSTPORT
    Byte Count111Variable2
    VER: SOCKS version (0x05)
  • CMD: command code:
    • 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 Count111variable2
    VER: SOCKS version (0x05)
  • STATUS: status code:
    • 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.[17]

    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.

    Browser

    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.

    Translating 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.

    External links

    Notes and References

    1. Web site: Service Name and Transport Protocol Port Number Registry. Internet Assigned Numbers Authority. 19 May 2017. 23 May 2017.
    2. Koblas . David . Koblas . Michelle R. . SOCKS . USENIX UNIX Security Symposium III . https://www.usenix.org/legacy/publications/library/proceedings/sec92/ . 16 November 2019.
    3. Darmohray, Tina. "Firewalls and fairy tales". ;LOGIN:. Vol 30, no. 1.
    4. http://www.cnet.com/tech/tech-industry/cyberspace-from-outer-space/ CNET: Cyberspace from outer space
    5. US. US8984268B2.
    6. US. US20210058367A1.
    7. US. US11190374B2.
    8. JP. JP6761452B2.
    9. US. US11425565B2.
    10. 1928.
    11. Book: Oppliger . Rolf . Security technologies for the World Wide Web . Artech House . 1580533485 . 2nd . 21 January 2020 . Circuit-level gateways. 2003 .
    12. Web site: 2010 Circumvention Tool Usage Report . The Berkman Center for Internet & Society at Harvard University . October 2010.
    13. Web site: Tor FAQ .
    14. Web site: OpenSSH FAQ . https://web.archive.org/web/20020201204826/http://www.openssh.org/faq.html#2.11 . dead . 2002-02-01 .
    15. Web site: SOCKS 4A: A Simple Extension to SOCKS 4 Protocol . OpenSSH . Ying-Da Lee . 2013-04-03.
    16. https://www.iana.org/assignments/socks-methods IANA.org
    17. Web site: CURLOPT_PROXY . curl.se . 20 January 2020.
    18. Web site: Products developed by Inferno Nettverk A/S. 2021-03-20. www.inet.no.
    19. Web site: Easy Net with SOCKS5. https://web.archive.org/web/20180913040145/https://www.shimmercat.com/en/docs/1.5/socks5-swift/. 2018-09-13. shimmercat.com. ShimmerCat. 20 April 2016.
    20. Web site: Configuring a SOCKS proxy server in Chrome . 2024-03-19 . www.chromium.org.
    21. Web site: Bizjak . Ambroz . ambrop72/badvpn: NCD scripting language, tun2socks proxifier, P2P VPN . GitHub . 20 January 2020 . 20 January 2020.
    22. Web site: xjasonlyu/tun2socks: tun2socks - powered by gVisor TCP/IP stack . GitHub.
    23. Web site: heiher/hev-socks5-tunnel: A high-performance tun2socks . GitHub.
    24. Web site: Hamsik . Adam . 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 . 20 January 2020 . 20 January 2020.

    This article is licensed under the GNU Free Documentation License. It uses material from the Wikipedia article "SOCKS".

    Except where otherwise indicated, Everything.Explained.Today is © Copyright 2009-2024, A B Cryer, All Rights Reserved. Cookie policy.