Introduction
A long time ago, people still wore straw sandals. Although they are comfortable to wear, they are not beautiful enough. Then people discovered that animal skins can also be used to make shoes, so leather shoes appeared. But leather shoes are worn on the feet, so people invented socks, which are put on the feet instead of the heel shoes, which not only improves the comfort, but also reduces the wear and tear.
In the online world, such socks also exist. In order to distinguish them from real-world socks, we use uppercase SOCKS here.
SOCKS is the network proxy protocol we are going to explain today.
The story of SOCKS
Before explaining SOCKS, let's review the OSI network seven-layer protocol.
OSI is the abbreviation of Open System Interconnect, which means open system interconnection.
And SOCKS is also a kind of network protocol, its role is the same as socks, used to replace the connection between the client and the server, which is a proxy protocol.
SOCKS is in the fifth layer of the OSI seven-layer protocol, that is, the session layer. It is in the middle of the presentation layer and the transport layer. From the figure above, we can see that the bottom layer of SOCKS is TCP and UDP protocols.
As a proxy protocol, SOCKS can provide proxy based on TCP and UDP. Compared with HTTP proxy, SOCKS proxy is more low-level, so there will be more application scenarios.
Generally speaking, the standard port of SOCKS is 1080.
The history of SOCKS
Each protocol has its own history of development, and SOCKS is no exception. It will be very interesting to tell the history of all protocols in the form of a story. You can look forward to it. Maybe one day such an article will appear.
Proxy is a basic function in the network. SOCKS proxy was first designed by David Koblas of MIPS Technology Corporation in the United States. MIPS company is famous for developing MIPS architecture and a series of RISC CPU chips based on this architecture. However, after a series of acquisitions, the MIPS architecture was finally abandoned in favor of the RISC-V architecture.
MIPS was acquired by Silicon Graphics in 1992. In that year Koblas published a paper on SOCKS, and SOCKS became famous in one fell swoop.
The most widely used protocol versions of SOCKS are 4 and 5. SOCKS4 was invented by Ying-Da Lee of NEC. Because there is no agreement on security in SOCKS 4, security is becoming more and more important for today's networks, so SOCKS5 appeared. SOCKS5 was originally a security protocol that made firewalls and other security products easier to manage.
The specific content of the SOCKS agreement
The commonly used SOCKS protocols mainly include SOCKS4, SOCKS4a and SOCKS5. This section will discuss in detail the composition of their agreement.
SOCKS4
Let's take a look at what the request data package of SOCKS4 looks like:
meaning | VER | CMD | DSTPORT | DSTIP | ID |
---|---|---|---|---|---|
Number of bytes | 1 | 1 | 2 | 4 | variable |
VER occupies 1 byte and represents the version number of the SOCKS protocol. For SOCKS4, this value is 0x04.
CMD occupies 1 byte, which means the code to execute the command. There are two options, among which 0x01 means to establish a TCP/IP stream connection, and 0x02 means to establish a TCP/IP port binding.
DSTPORT occupies 2 bytes and represents the target port number.
DESTIP occupies 4 bytes and represents an IPv4 address.
ID occupies a variable number of bytes, which means the user ID.
For the request data, the corresponding return data is as follows:
meaning | VN | REP | DSTPORT | DSTIP |
---|---|---|---|---|
Number of bytes | 1 | 1 | 2 | 4 |
VN occupies 1 byte, indicating that it is the version of the returned message.
REP occupies 1 byte, which means the returned code:
byte | meaning |
---|---|
0x5A | Request authorization |
0x5B | Request rejected or failed |
0x5C | Failed because the request does not contain the client ID or the server cannot connect to the client |
0x5D | Failed because the client ID does not match |
DSTPORT occupies two bytes, indicating the port of the destination, if it is not bound, it is empty.
DSTIP occupies 4 bytes and represents the IP address of the destination bound by the client.
For example, if the client wants to use SOCKS4 to connect to 66.102.7.99:80 from Fred, the request is as follows:
0x04 | 0x01 | 0x00 0x50 | 0x42 0x66 0x07 0x63 | 0x46 0x72 0x65 0x64 0x00
The last field is Fred's ASCII code.
If the server returns OK, the corresponding response is as follows:
0x00 | 0x5A | 0xXX 0xXX | 0xXX 0xXX 0xXX 0xXX
Where 0xXX can be any value.
When the connection is established, all requests from the SOCKS client to the SOCKS server will be forwarded to 66.102.7.99.
SOCKS4a
Because SOCKS4 can only specify the IP address of the destination server, this corresponds to severe restrictions when the server has multiple IPs. So SOCK4a extends SOCK4 to support the domain name of the target server.
SOCKS4a was also proposed by Ying-Da Lee, the author of SOCKS4. Let's look at the request format of SOCKS4a:
meaning | VER | CMD | DSTPORT | DSTIP | ID | DOMAIN |
---|---|---|---|---|---|---|
Number of bytes | 1 | 1 | 2 | 4 | variable | variable |
SOCKS4a added the domain at the end of SOCKS4.
DOMAIN represents the domain name of the target server to be connected to. Use null (0x00) to end. The first three bytes of the corresponding DSTIP are set to NULL, and the last byte is set to a non-zero value.
The server response is the same as SOCKS4.
SOCKS5
Although SOCKS5 is the latest version of SOCKS, SOCKS5 and SOCKS4 are not compatible. SOCKS5 supports authentication and provides support for IPv6 and UDP. UDP can be used for DNS lookups. Its interactive process is as follows:
- The client and server connect and send a greeting message, which also contains a list of supported authentication methods.
- The server selects a supported authentication method, and if none is supported, it sends a failure response.
- According to the selected authentication method, the client and the server perform subsequent authentication interactions, and the interaction process is related to the selected authentication method.
- The client sends a connection request in a similar way to SOCKS4.
- The server sends a response similar to SOCKS4.
Let's look at the format of the greeting message:
meaning | VER | NAUTH | AUTH |
---|---|---|---|
Number of bytes | 1 | 1 | Variable byte |
VER occupies 1 byte to represent the version number of SOCKS, here is 0x05.
NAUTH occupies 1 byte, indicating the number of authentication methods supported.
AUTH is a variable byte, indicating the supported authentication method. One byte represents a method, and the supported methods are as follows:
0x00: 没有认证
0x01: GSSAPI
0x02: 用户名/密码 (RFC 1929)
0x03–0x7F: methods assigned by IANA
0x03: Challenge-Handshake Authentication Protocol
0x04: 未分配
0x05: Challenge-Response Authentication Method
0x06: Secure Sockets Layer
0x07: NDS Authentication
0x08: Multi-Authentication Framework
0x09: JSON Parameter Block
0x0A–0x7F: 未分配
0x80–0xFE: 内部使用的保留方法
The corresponding server-side response is as follows:
meaning | VER | CAUTH |
---|---|---|
Number of bytes | 1 | 1 |
VER occupies 1 byte and represents the version number. For SOCKS5, its value is 0x05.
CAUTH occupies 1 byte, indicating the selected authentication method. If it is not selected, it is set to 0xFF.
After selecting the authentication method, the next step is the authentication interaction between the client and the server. Here we choose the most basic user name and password 0x02 authentication as an example.
The client sends an authentication request:
meaning | VER | IDLEN | ID | PWLEN | PW |
---|---|---|---|---|---|
Number of bytes | 1 | 1 | (1-255) | 1 | (1-255) |
VER occupies 1 byte to indicate the version of the current user name and password authentication.
IDLEN occupies 1 byte and represents the length of the user name.
ID occupies 1 to 255 bytes and represents the user name.
PWLEN occupies 1 byte and represents the length of the password.
PW is the password.
The corresponding server-side response is as follows:
meaning | VER | STATUS |
---|---|---|
Number of bytes | 1 | 1 |
VER occupies 1 byte and represents the version number.
STATUS occupies 1 byte and represents the response status of the server.
Next, the client can send a connection establishment message with the server:
meaning | VER | CMD | RSV | DSTADDR | DSTPORT |
---|---|---|---|---|---|
Number of bytes | 1 | 1 | 1 | Variable byte | 2 |
CMD is an optional command for connection. 0x01 means to establish a TCP/IP stream connection, which means to establish a TCP/IP port binding, and 0x03 means to connect to a UDP port.
RSV is a reserved byte and must be 0x00.
DSTADDR is the address of SOCKS5. The definition of the address is like this:
meaning | TYPE | ADDR |
---|---|---|
Number of bytes | 1 | Variable byte |
TYPE indicates the type of address, 0x01 is an IPv4 address, 0x03 is a domain name, and 0x04 is an IPv6 address.
ADDR represents the address. If it is IPv4, 4 bytes are used. If it is a domain name, the first byte represents the length, and the following bytes represent the domain name. If it is an IPv6 address, 16 bytes are used.
The corresponding server-side response is as follows:
meaning | VER | STATUS | RSV | BNDADDR | BNDPORT |
---|---|---|---|---|---|
Number of bytes | 1 | 1 | 1 | Variable byte | 2 |
Summarize
The above is the detailed agreement content of SOCKS4 and SOCKS5. Note that SOCKS must be capitalized!
This article has been included in http://www.flydean.com/09-socks/
The most popular interpretation, the most profound dry goods, the most concise tutorial, and many tips you don't know are waiting for you to discover!
Welcome to pay attention to my official account: "Program those things", know the technology, know you better!
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用
。你还可以使用@
来通知其他用户。