SOCKS Proxy Protocol

What is SOCKS?

SOCKS (Socket Secure) is a protocol for relaying network connections through a proxy server. Unlike HTTP proxies that understand HTTP semantics, SOCKS operates at the session layer (OSI layer 5) and simply forwards TCP connections without interpreting the traffic. This makes SOCKS protocol-agnostic—it can carry any TCP protocol including HTTP, SSH, SMTP, or any custom application traffic.

The protocol was introduced by David Koblas at Silicon Graphics in 1992. SOCKS v4 provided basic TCP relay without authentication. SOCKS v5 (RFC 1928, March 1996) extended the protocol with UDP relay, authentication methods, and IPv6 support.

SOCKS4 vs SOCKS4a vs SOCKS5

SOCKS4

Supports TCP relay only. The client sends a connection request containing: VER (0x04), CMD (0x01=connect, 0x02=bind), DSTPORT (2 bytes), DSTIP (4 bytes), USERID (variable, null-terminated). The proxy connects to the specified IP address and port. Does not support domain names—the client must resolve the destination address before connecting to the proxy.

SOCKS4a

Extension to SOCKS4 that allows domain name resolution on the proxy side. The client sends DSTIP as 0.0.0.1 (a special sentinel value) followed by a domain name in the USERID field (null-terminated). The proxy resolves the domain name before establishing the connection. This enables name-based virtual hosting scenarios where the client doesn't know the destination IP.

SOCKS5 (RFC 1928)

Full extension with multiple authentication methods and UDP support:

• TCP and UDP relay support
• Authentication: GSSAPI (Kerberos), username/password (RFC 1929), no auth
• IPv6 address support (ATYP 0x04)
• Domain name resolution by proxy even when client knows IP
• Multiple authentication methods negotiated per-connection
• Binding support for protocols that require server-to-client connections (FTP)

SOCKS5 Connection Sequence

The SOCKS5 handshake consists of three phases:

Phase 1: Authentication Negotiation

Client sends greeting with supported authentication methods:

Client → Server: VER=0x05, NMETHODS=2, METHODS=[0x00, 0x02]
Server → Client: VER=0x05, METHOD=0x02  (use username/password)

Phase 2: Authentication

For username/password auth (RFC 1929):

Client → Server: VER=0x01, ULEN=8, UNAME="username", PLEN=8, PASSWD="password"
Server → Client: VER=0x01, STATUS=0x00  (0x00=success, 0x01=failure)

GSSAPI (RFC 1961) uses Kerberos for authentication in enterprise environments. Username/password sends credentials in plaintext—suitable only over TLS.

Phase 3: Connection Request

Client → Server:
  VER=0x05, CMD=0x01 (connect), RSV=0x00, ATYP=0x03 (domain)
  DST.DOMAIN="example.com", DST.PORT=443

Server → Client:
  VER=0x05, REP=0x00 (success), RSV=0x00, ATYP=0x01 (IPv4)
  BND.ADDR=192.168.1.1, BND.PORT=1080

REP values: 0x00=success, 0x01=general failure, 0x02=connection not allowed, 0x03=network unreachable, 0x04=host unreachable, 0x05=connection refused, 0x06=TTL expired, 0x07=command not supported, 0x08=address type not supported.

UDP Relay (SOCKS5)

SOCKS5 supports UDP relay through the UDP ASSOCIATE command. The client establishes a TCP connection to the proxy, requests UDP ASSOCIATE with the expected client address/port for sending datagrams. The proxy assigns a BND.ADDR and BND.PORT for the client to send UDP datagrams. Each UDP datagram is wrapped in a UDP request header:

UDP Request Header (10 bytes + data):
  RSV (2 bytes): Reserved, must be 0x0000
  FRAG (1 byte): Fragment number (0x00 = no fragmentation)
  ATYP (1 byte): Address type (0x01=IPv4, 0x03=domain, 0x04=IPv6)
  DST.ADDR (variable): Destination address
  DST.PORT (2 bytes): Destination port
  DATA (variable): User datagram payload

Fragmentation is optional. When used, the high-order bit indicates end-of-fragment sequence. The reassembly timer must be at least 5 seconds.

Bind Command (for FTP-like Protocols)

The BIND command supports protocols that require the server to initiate a connection back to the client (FTP passive mode). The client sends BIND with the destination address it expects the server to connect from. The proxy listens on a port and reports the bound address/port to the client. A second reply arrives when the remote host connects to that port.

Use Cases

• Firewall traversal: Allow internal clients to reach external services through a SOCKS proxy
• Application isolation: Force specific applications through a proxy chain
• SSH tunneling: OpenSSH supports SOCKS5 proxy via -D flag
• ProxyChains: Uses SOCKS4/5 to chain multiple proxies
• Browser proxying: Firefox, Chrome support SOCKS5 for split tunneling

Security Considerations

SOCKS proxies forward arbitrary TCP/UDP traffic without inspection. A compromised or malicious SOCKS proxy can:

• Read all unencrypted traffic passing through it
• Inject data into connections
• Terminate connections prematurely
• Log source and destination addresses

Username/password authentication (RFC 1929) transmits credentials in plaintext. Always use SOCKS over TLS or within an encrypted tunnel when authentication is required.

Comparison: SOCKS vs HTTP Proxy