socks4 proxy 50

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, making SOCKS publicly available.[1] The protocol was extended to version 4 by Ying-Da Lee of NEC.

The SOCKS reference architecture and client are owned by Permeo Technologies,[2] a spin-off from NEC. (Blue Coat Systems bought out Permeo Technologies.)

The SOCKS5 protocol was originally a security protocol that made firewalls and other security products easier to administer.[citation needed] It was approved by the IETF in 1996.[3] The protocol was developed in collaboration with Aventail Corporation, which markets the technology outside of Asia.[4]
Usage

SOCKS is a de facto standard for circuit-level gateways[citation needed].

Another use of SOCKS is 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.[5]

Some SSH suites, such as OpenSSH, support dynamic port forwarding that allows the user to create a local SOCKS proxy.[6] This can free the user from the limitations of connecting only to a predefined remote port and server.

The Tor onion proxy software presents a SOCKS interface to its clients.
Comparison to HTTP proxying

SOCKS operates at a lower level than HTTP proxying: SOCKS uses a handshake protocol to inform the proxy software about the connection that the client is trying to make, and then acts as transparently as possible, whereas a regular proxy may interpret and rewrite headers (say, to employ another underlying protocol, such as FTP; however, an HTTP proxy simply forwards an HTTP request to the desired HTTP server). Though HTTP proxying has a different usage model in mind, the CONNECT method allows for forwarding TCP connections; however, SOCKS proxies can also forward UDP traffic and work in reverse, while HTTP proxies cannot. HTTP proxies are traditionally more aware of the HTTP protocol, performing higher-level filtering (though that usually only applies to GET and POST methods, not the CONNECT method).
SOCKS

Bill wishes to communicate with Jane over the internet, but a firewall between them exists on his network, where Bill is not authorized to communicate with Jane directly. So, Bill connects to the SOCKS proxy on his network, informing it about the connection he wishes to make to Jane; the SOCKS proxy opens a connection through the firewall and facilitates the communication between Bill and Jane.

For more information on the technical specifics of the SOCKS protocol, see the sections below.
HTTP

Bill wishes to download a web page from Jane, who runs a web server. Bill cannot directly connect to Jane's server, as a firewall has been put in place on his network. In order to communicate with the server, Bill connects to his network's HTTP proxy. His web browser communicates with the proxy in exactly the same way that it would directly with Jane's server if that was possible; that is, it sends a standard HTTP request header. The HTTP proxy connects to Jane's server, and then transmits back to Bill any data that Jane's server returns.[7]
Protocol
SOCKS4

A typical SOCKS4 connection request looks like this:

SOCKS Client to SOCKS Server:

    field 1: SOCKS version number, 1 byte, must be 0x04 for this version
    field 2: command code, 1 byte:
        0x01 = establish a TCP/IP stream connection
        0x02 = establish a TCP/IP port binding
    field 3: network byte order port number, 2 bytes
    field 4: network byte order IP address, 4 bytes
    field 5: the user ID string, variable length, terminated with a null (0x00)

SOCKS Server to SOCKS client:

    field 1: null byte
    field 2: status, 1 byte:
        0x5a = request granted
        0x5b = request rejected or failed
        0x5c = request failed because client is not running identd (or not reachable from the server)
        0x5d = request failed because client's identd could not confirm the user ID string in the request
    field 3: 2 arbitrary bytes, that should be ignored
    field 4: 4 arbitrary bytes, that should be ignored

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 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;[8] this is useful when the client itself cannot resolve the destination host's domain name to an IP address.

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:

    field 1: SOCKS version number, 1 byte, must be 0x04 for this version
    field 2: command code, 1 byte:
        0x01 = establish a TCP/IP stream connection
        0x02 = establish a TCP/IP port binding
    field 3: network byte order port number, 2 bytes
    field 4: deliberate invalid IP address, 4 bytes, first three must be 0x00 and the last one must not be 0x00
    field 5: the user ID string, variable length, terminated with a null (0x00)
    field 6: the domain name of the host we want to contact, variable length, terminated with a null (0x00)

Server to SOCKS client:

    field 1: null byte
    field 2: status, 1 byte:
        0x5a = request granted
        0x5b = request rejected or failed
        0x5c = request failed because client is not running identd (or not reachable from the server)
        0x5d = request failed because client's identd could not confirm the user ID string in the request
    field 3: network byte order port number, 2 bytes
    field 4: network byte order IP address, 4 bytes

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 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 (or sends a failure response if none of the offered methods 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 authentication methods supported are numbered as follows:

    0x00: No authentication
    0x01: GSSAPI[9]
    0x02: Username/Password[10]
    0x03–0x7F: methods assigned by IANA[11]
    0x80–0xFE: methods reserved for private use

The initial greeting from the client is

    field 1: SOCKS version number (must be 0x05 for this version)
    field 2: number of authentication methods supported, 1 byte
    field 3: authentication methods, variable length, 1 byte per method supported

The server's choice is communicated:

    field 1: SOCKS version, 1 byte (0x05 for this version)
    field 2: chosen authentication method, 1 byte, 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:

For username/password authentication the client's authentication request is

    field 1: version number, 1 byte (must be 0x01)
    field 2: username length, 1 byte
    field 3: username
    field 4: password length, 1 byte
    field 5: password

Server response for username/password authentication:

    field 1: version, 1 byte
    field 2: status code, 1 byte.
        0x00 = success
        any other value = failure, connection must be closed

The client's connection request is

    field 1: SOCKS version number, 1 byte (must be 0x05 for this version)
    field 2: command code, 1 byte:
        0x01 = establish a TCP/IP stream connection
        0x02 = establish a TCP/IP port binding
        0x03 = associate a UDP port
    field 3: reserved, must be 0x00
    field 4: address type, 1 byte:
        0x01 = IPv4 address
        0x03 = Domain name
        0x04 = IPv6 address
    field 5: destination address of
        4 bytes for IPv4 address
        1 byte of name length followed by the name for Domain name
        16 bytes for IPv6 address
    field 6: port number in a network byte order, 2 bytes

Server response:

    field 1: SOCKS protocol version, 1 byte (0x05 for this version)
    field 2: status, 1 byte:
        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
    field 3: reserved, must be 0x00
    field 4: address type, 1 byte:
        0x01 = IPv4 address
        0x03 = Domain name
        0x04 = IPv6 address
    field 5: destination address of
        4 bytes for IPv4 address
        1 byte of name length followed by the name for Domain name
        16 bytes for IPv6 address
    field 6: network byte order port number, 2 bytes