AI-powered method and device for identifying Shadowsocks proxy traffic through traffic replay

Abstract

This invention relates to the field of network security technology, and in particular to an AI-enabled traffic replay-based Shadowsocks proxy traffic identification method and apparatus. This invention introduces a crucial replay test step after performing encryption feature analysis, thereby proactively probing the behavior of initially suspected second-type traffic. By sending raw or specifically processed traffic data packets to the target server and analyzing its network behavior characteristics such as connection establishment, data response, and connection termination, decisive verification evidence is obtained. This not only provides reliable corroboration for preliminary statistical feature judgment, greatly reducing misjudgments caused by encryption protocol obfuscation or random data interference, but also overcomes the deficiency of existing technologies in lacking effective means for final confirmation of suspected traffic, significantly improving the accuracy and reliability of Shadowsocks proxy traffic identification.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an AI-enabled method and apparatus for identifying Shadowsocks proxy traffic through traffic replay. Background Technology

[0002] Shadowsocks is a popular, lightweight encrypted proxy tool in China, based on SOCKS5. This tool encrypts and reconstructs the SOCKS5 protocol to conceal the content transmitted between the client and the proxy server, achieving high security and anonymity.

[0003] Existing Shadowsocks traffic detection methods include extracting corresponding terminal network traffic feature vectors from the network traffic generated by the terminal, extracting user network behavior feature vectors from the network traffic of the terminal's users, and determining whether the terminal's users access external networks through Shadowsocks proxies based on the extracted terminal network traffic feature vectors and user network behavior feature vectors. This method does not require offline training of the detection model and can improve detection efficiency.

[0004] Furthermore, the extracted terminal network traffic feature vector includes the source IP address, destination IP address, source port, destination port, transport layer protocol, and stream encryption features of the terminal network traffic. The extracted user network behavior feature vector includes information on the user name, user IP address, first user feature, and second user feature. These terminal network traffic feature vectors and user network behavior feature vectors can more accurately reflect the characteristics of Shadowsocks proxy traffic, thus improving the accuracy of Shadowsocks proxy network traffic detection.

[0005] However, the existing technologies mentioned above have the following main problems: relying solely on packet entropy as the primary condition for judging Shadowsocks traffic can lead to false positives and misjudgments. Furthermore, they lack more advanced identification and verification methods.

[0006] Therefore, overcoming the shortcomings of the existing technology is an urgent problem to be solved in this technical field. Summary of the Invention

[0007] The technical problem to be solved by this invention is that the invention solves the technical problem of high false positive rate and lack of effective verification methods when relying on a single feature to identify Shadowsocks proxy traffic in the prior art.

[0008] The present invention adopts the following technical solution:

[0009] Firstly, an AI-powered method for identifying Shadowsocks proxy traffic through traffic replay is provided, including:

[0010] Network traffic is input into a pre-trained AI unknown traffic identification model to filter out the first type of unknown traffic that does not match any known protocol;

[0011] The first type of unknown traffic is input into the AI ​​encrypted traffic discrimination model to filter out the second type of suspected traffic that meets the statistical characteristics of encrypted traffic.

[0012] Perform a replay test on the data packets corresponding to the second type of suspected traffic, and determine whether the second type of suspected traffic is suspected Shadowsocks proxy traffic based on the response results of the replay test.

[0013] Preferably, the step of inputting the first type of unknown traffic into the AI ​​encrypted traffic discrimination model to filter out the second type of suspected traffic that meets the statistical characteristics of encrypted traffic specifically includes:

[0014] Extract the payload data of data packets from the first type of unknown traffic;

[0015] Calculate the information entropy value, bit density value, and byte randomness value of the payload data;

[0016] When the information entropy value, bit density value, and byte randomness value fall within the preset encrypted traffic threshold range, the first type of unknown traffic is determined to be the second type of suspected traffic.

[0017] Preferably, the preset encrypted traffic threshold range includes: information entropy value range, bit density value range, and byte randomness value range;

[0018] The information entropy value H1 = -∑pi × log2pi; where pi is the ratio of the number of occurrences of a single value to the total length of the payload data;

[0019] The bit density value H2 = ∑Countbit(data_i) / dlen; where Countbit(data_i) is the number of times a bit 1 appears in each binary value, data_i is a single value in the payload data, and dlen is the total length of the payload data;

[0020] The byte randomness value H3 = count(key) / 255; where H3 is the number of different values ​​that actually appear in the payload data within the range of 0-0xff.

[0021] The information entropy value ranges from 5.0 to 8.0, the bit density value ranges from 3.4 to 4.6, and the byte randomness value ranges from 0.8 to 1.0.

[0022] Preferably, the playback test includes at least a complete load playback, a tampered load playback, and a partial load playback;

[0023] The complete payload replay includes sending the unmodified complete data packet payload to the target server and detecting whether a valid response is received.

[0024] Tampered payload replay involves sending at least one byte of the tampered data packet payload to the target server and detecting whether the connection is immediately terminated.

[0025] Partial payload replay involves sending a payload containing only the first few bytes of the packet payload to the target server, detecting whether the connection enters a waiting state, and eventually closing it after a timeout.

[0026] Preferably, the complete payload replay specifically includes: creating a socket client, establishing communication with the target IP and target port, sending a complete data packet payload, receiving the content returned by the server, and if the size of the returned content is consistent with the actual response content, then the corresponding traffic is confirmed as suspected Shadowsocks proxy traffic;

[0027] The tampered payload replay specifically includes: creating a socket client, establishing communication with the target IP and target port, tampering with the last byte of the data packet payload and sending it; if the server immediately terminates the communication, the corresponding traffic is confirmed as suspected Shadowsock proxy traffic.

[0028] Partial payload replay specifically includes: creating a socket client, establishing communication with the target IP and target port, sending a data packet payload containing the first preset number of bytes of SOCKS5 content, and if the server does not respond and the client actively closes the connection after a preset time, then the corresponding traffic is confirmed to be suspected Shadowsock proxy traffic.

[0029] Preferably, in the tampered payload playback, the tampered bytes are located in the message authentication code portion of the payload data.

[0030] Preferably, the method further includes:

[0031] In the replay test, the first round-trip time from sending a data packet to receiving the first response packet, and the second round-trip time from sending a data packet to receiving a complete response or closing the connection are recorded.

[0032] If the second round-trip time is greater than the first round-trip time, it serves as an auxiliary basis for determining whether the second type of suspected traffic is suspected Shadowsocks proxy traffic.

[0033] Preferably, the step of inputting network traffic into a pre-trained AI unknown traffic identification model to filter out the first type of unknown traffic that does not match any known protocol specifically includes:

[0034] Deep packet inspection technology is used to identify and exclude traffic with known protocols in order to obtain the remaining traffic;

[0035] For the remaining traffic, it is filtered based on the five-tuple information and the geographical location information of the destination IP address, and traffic whose destination is not local is classified as the first type of unknown traffic.

[0036] Secondly, an AI-enabled traffic replay type Shadowsocks proxy traffic identification device is provided, the AI-enabled traffic replay type Shadowsocks proxy traffic identification device includes: a processor and a memory for storing processor-executable instructions;

[0037] The processor is configured to execute the AI-enabled traffic replay Shadowsocks proxy traffic identification method.

[0038] Thirdly, a non-volatile computer storage medium is provided, which stores computer-executable instructions that are executed by one or more processors to perform the AI-enabled traffic replay Shadowsocks proxy traffic identification method described in the first aspect.

[0039] Fourthly, a chip is provided, comprising: a processor and an interface for calling and running a computer program stored in a memory, executing the AI-enabled traffic replay Shadowsocks proxy traffic identification method as described in the first aspect.

[0040] Fifthly, a computer program product containing instructions is provided, which, when executed on a computer or processor, causes the computer or processor to perform the AI-enabled traffic replay Shadowsocks proxy traffic identification method as described in the first to fourth aspects and any one of them.

[0041] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0042] This invention introduces a crucial replay test step after performing encryption feature analysis, thereby proactively probing the behavior of initially suspected second-type traffic. By sending raw or specifically processed traffic data packets to the target server and analyzing its network behavior characteristics such as connection establishment, data response, and connection termination, decisive verification evidence is obtained. This not only provides reliable corroboration for the initial statistical feature judgment, greatly reducing misjudgments caused by encryption protocol confusion or random data interference, but also overcomes the deficiency of existing technologies in lacking effective means to finally confirm suspected traffic, significantly improving the accuracy and reliability of Shadowsocks proxy traffic identification. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 This is a flowchart illustrating an AI-enabled traffic replay-based Shadowsocks proxy traffic identification method provided in an embodiment of the present invention.

[0045] Figure 2 This is a schematic diagram of a process for obtaining first-type location traffic according to an embodiment of the present invention;

[0046] Figure 3 This is a schematic diagram of packet capture between a browser and a Shadowsocks proxy provided in an embodiment of the present invention;

[0047] Figure 4 This is a schematic diagram of packet capture between a Shadowsocks proxy and a Shadowsocks server provided in an embodiment of the present invention;

[0048] Figure 5 This is a schematic diagram of a process for obtaining a second type of suspected traffic according to an embodiment of the present invention;

[0049] Figure 6 This is a schematic diagram of a playback test process provided by an embodiment of the present invention;

[0050] Figure 7 This is a schematic diagram of a complete load playback process provided by an embodiment of the present invention;

[0051] Figure 8 This is a schematic diagram of a tampered payload playback process provided by an embodiment of the present invention;

[0052] Figure 9 This is a schematic diagram of a partial load playback process provided in an embodiment of the present invention;

[0053] Figure 10 This is a schematic diagram of a process for determining suspected Shadowsocks proxy traffic provided by an embodiment of the present invention;

[0054] Figure 11 This is a schematic diagram of a process for determining suspected Shadowsocks proxy traffic based on round-trip latency, provided by an embodiment of the present invention.

[0055] Figure 12 This is a schematic diagram of the structure of an AI-enabled traffic replay type Shadowsocks proxy traffic identification device provided in an embodiment of the present invention. Detailed Implementation

[0056] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0057] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

[0058] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0059] In describing some embodiments, the terms "coupled," "coupled," and "connected," and their derivative expressions, may be used. For example, the term "connected" may be used in describing some embodiments to indicate that two or more components have direct physical or electrical contact with each other. Similarly, the term "coupled" may be used in describing some embodiments to indicate that two or more components have direct physical or electrical contact. However, the terms "connected" or "coupled" may also refer to two or more components that do not have direct contact with each other but still cooperate or interact with each other, such as "optical coupling," "wireless connection," etc. The embodiments disclosed herein are not necessarily limited to the scope of this invention.

[0060] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0061] Example 1:

[0062] To address the problems of existing technologies, this embodiment proposes an AI-enabled traffic replay-based Shadowsocks proxy traffic identification method. In one embodiment, such as... Figure 1 As shown, the method includes:

[0063] Step 101: Input network traffic into the pre-trained AI unknown traffic identification model to filter out the first type of unknown traffic that does not match any known protocol.

[0064] When performing network traffic filtering, the first step is to collect and preliminarily organize the raw network traffic. This can be done through methods such as port mirroring and packet capture to obtain the network traffic being transmitted.

[0065] The pre-processed network traffic feature data is input into the pre-trained AI unknown traffic recognition model, and the inference and computation process of the AI ​​unknown traffic recognition model is initiated. The AI ​​unknown traffic recognition model first uses its own feature extraction network to map the input traffic features to a high-dimensional feature space, generating an embedding vector with semantic representation capabilities. Then, based on the known protocol feature patterns learned in the pre-training stage, it matches and judges the current input traffic.

[0066] For each input traffic session, the AI-powered unknown traffic identification model outputs the confidence score of its matching against various known network protocols. Simultaneously, it uses pre-defined judgment rules to filter out the first category of unknown traffic. The core judgment logic is: if the maximum confidence score of a traffic session matching all known protocols is lower than the threshold standard calibrated by the AI ​​unknown traffic identification model, the traffic is determined not to match any known protocol and is classified as first-category unknown traffic. In some scenarios, feature distance methods and out-of-distribution detection methods can be combined to assist in the judgment, further improving the accuracy of the filtering results and reducing false positives and false negatives.

[0067] In one embodiment, the process of screening the first type of unknown traffic further includes: in order to eliminate the interference of known protocols on the identification of Shadowsocks proxy traffic, firstly, based on the identification program deployed in the DPI (Deep Packet Inspection) serial inspection device, performing first packet inspection on all traffic in the network.

[0068] The DPI serial detection device matches and identifies the first packet data of each traffic stream based on a preset known protocol feature library. These known protocols include File Transfer Protocol (FTP), Secure Shell (SSH), Teletype Network (TELNET), MySQL, Simple Mail Transfer Protocol (SMTP), Hypertext Transfer Protocol (HTTP), PostOffice Protocol - Version 3 (POP3), Lightweight Directory Access Protocol (LDAP), Hypertext Transfer Protocol Secure (HTTPS), Remote Desktop Protocol (RDP), Simple Network Management Protocol (SNMP), and Virtual Network Computing (VNC). Computing (VNC), Point-to-Point Tunneling Protocol VPN (PPTP VPN), Layer 2 Tunneling Protocol VPN (L2TP VPN), Internet Protocol Security VPN (IPSEC VPN), Internet Message Access Protocol (IMAP), and H.323 Protocol (H.323).323), SOCKS Protocol Version 4 (SOCKS4), SOCKS Protocol Version 5 (SOCKS5), Remote Authentication Dial-In User Service (RADIUS), Simple Network Time Protocol (SNTP), Real-Time Messaging Protocol (RTMP), Session Initiation Protocol (SIP), Real-time Transport Protocol (RTP), Real-Time Control Protocol (RTCP), Real-Time Streaming Protocol (RTSP), Extensible Messaging and Presence Protocol (XMPP), HTTP Dynamic Streaming (HDS), HTTP Real-Time Streaming (HTTP) Well-known protocols include Live Streaming (HLS), Post Office Protocol version 3 Secure (POP3S), Simple Mail Transfer Protocol Secure (SMTPS), and Transport Layer Security (TLS).

[0069] After the initial packet detection, traffic that does not match any known protocol characteristics is defined as Category I unknown traffic, ensuring that subsequent identification processes are limited to traffic not covered by the existing DPI identification capabilities.

[0070] Step 102: Input the first type of unknown traffic into the AI ​​encrypted traffic discrimination model to filter out the second type of suspected traffic that meets the statistical characteristics of encrypted traffic.

[0071] Specifically, for the first type of unknown traffic obtained in step 101, further encryption feature analysis is conducted to accurately screen out suspected traffic with Shadowsocks proxy traffic encryption characteristics.

[0072] In one embodiment, the AI ​​encrypted traffic discrimination model relies on the statistical characteristics of encrypted traffic learned during the pre-training phase to perform feature matching and attribute determination on each of the first type of unknown traffic. The AI ​​encrypted traffic discrimination model maps the preprocessed traffic features to a dedicated feature space, accurately capturing the core commonalities that distinguish encrypted traffic from plaintext traffic, such as randomized packet length distribution, high load entropy value, fixed interaction frame structure, and key statistical characteristics such as no plaintext feature strings, and quantifies and scores the encryption attributes of each unknown traffic.

[0073] Then, based on the encryption feature matching score output by the AI ​​encrypted traffic discrimination model, and combined with the preset judgment threshold, the second type of suspected traffic is screened. If the encryption feature matching score of a certain first type of unknown traffic reaches the threshold requirement, it is determined that it meets the statistical characteristics of encrypted traffic and is marked as second type of suspected traffic; at the same time, the session identifier, encryption feature score, core statistical characteristics, traffic collection time and other key information of this type of traffic are fully recorded to form an independent list of second type of suspected traffic, so as to effectively distinguish it from unencrypted unknown traffic.

[0074] In one embodiment, the process of filtering out the second type of suspected traffic also includes:

[0075] First, a filtering method based on the five-tuple (protocol type, source IP, source port, destination IP, destination port) is adopted, combined with GeoIP geolocation technology, to prioritize the targeting of session traffic whose destination IP is not located in China. For example, session traffic with the destination IP of 144.34.181.85 in Los Angeles, California, USA, is more likely to be Shadowsocks proxy traffic.

[0076] Subsequently, the locked cross-border unknown traffic is analyzed using three core encryption features: information entropy, bit density, and byte randomness. When the information entropy, bit density, and byte randomness of a traffic stream are all within the empirical range, it is defined as a second-type suspected traffic stream.

[0077] Step 103: Perform a replay test on the data packets corresponding to the second type of suspected traffic, and determine whether the second type of suspected traffic is suspected Shadowsocks proxy traffic based on the response results of the replay test.

[0078] To address the potential for misjudgment based solely on encryption features, a packet replay test was conducted on the second type of suspected traffic identified in step 102. The response results were then used to comprehensively determine whether the traffic was Shadowsocks proxy traffic.

[0079] In one embodiment, a complete data packet replay is first performed. A socket client is created to establish communication with the destination IP (e.g., 144.34.181.85) and destination port (e.g., 443) corresponding to the second type of suspected traffic. A complete data packet payload (e.g., 614 bytes of encrypted data) is sent. If the content returned by the server is the same size as the response content of the real business (e.g., static business returns a 275-byte response), then the proxy characteristics of the traffic are preliminarily verified.

[0080] Then, the tampered data packet is replayed, including modifying the last byte of the data packet payload (changing non-zero bytes to zero or zero bytes to one byte) before sending it. If the server immediately terminates the communication due to HMAC verification failure, it further confirms the attribute of its encrypted proxy.

[0081] Finally, partial packet replay is performed: only the first 41 bytes of the payload containing SOCKS5 content are sent. If the server does not respond due to waiting for complete data, and the client actively closes the connection after a preset time (e.g., 10 seconds), this conforms to the TCP segmentation transmission mechanism of the Shadowsocks proxy. Finally, the round-trip timestamps are analyzed: record the time 1 when the client sends the data packet, the time 2 when the server responds to the TCP handshake, the time 3 when the client sends the first data packet request, and the time 4 when the server responds to the first data packet. Calculate result1 = time 2 - time 1 (TCP handshake time) and result2 = time 4 - time 1 (total data response time). If result2 is much greater than result1, it indicates that the server accessed a third-party target server during the response process, which is consistent with the working principle of the Shadowsocks proxy.

[0082] Based on the response results of the replay test above, it can be accurately determined that the second type of suspected traffic is suspected Shadowsocks proxy traffic. The replay test process will be explained in detail below.

[0083] This embodiment introduces a crucial replay test step after performing encryption feature analysis, thereby actively probing the behavior of the second type of suspected traffic initially identified as suspicious. By sending raw or specifically processed traffic data packets to the target server and analyzing its network behavior characteristics such as connection establishment, data response, and connection termination, decisive verification evidence is obtained. This not only provides reliable corroboration for the initial statistical feature judgment, greatly reducing misjudgments caused by encryption protocol confusion or random data interference, but also overcomes the deficiency of existing technologies in lacking effective means to finally confirm suspected traffic, significantly improving the accuracy and reliability of Shadowsocks proxy traffic identification.

[0084] In one embodiment, such as Figure 2As shown, the step of inputting network traffic into a pre-trained AI unknown traffic identification model to filter out the first type of unknown traffic that does not match any known protocol specifically includes:

[0085] Step 1011: Identify and exclude known protocol traffic based on deep packet inspection technology to obtain the remaining traffic.

[0086] The deep packet inspection (DPI) serial inspection device is deployed in the network transmission link. This device contains a dedicated traffic identification program used to accurately identify and preprocess traffic originating from the PC-based "Shadowsocks" app. DPI technology is used to perform first-packet inspection of all network traffic, matching the first packet data of each traffic stream against a pre-defined database of known protocol characteristics. Particular emphasis is placed on excluding traffic from encrypted protocols such as SSL and SSH, which are prone to interference.

[0087] After the initial packet protocol matching process described above, traffic that does not match any known protocol characteristics is defined as remaining traffic.

[0088] Step 1012: For the remaining traffic, filter it based on the five-tuple information and the geographical location information of the destination IP address, and classify the traffic whose destination is not local as the first type of unknown traffic.

[0089] For the remaining traffic obtained in step 1011, a preliminary screening is performed using a five-tuple-based filtering method. The five-tuple information includes protocol type, such as TCP and UDP, source IP address, source port, destination IP address, and destination port. The transmission characteristics of each remaining traffic path can be accurately located through the five-tuple.

[0090] Simultaneously, the GeoIP geolocation module in the DPI device is invoked to perform geolocation resolution on the destination IP address of the remaining traffic, determining the physical region affiliation of the destination IP. Using China as the local region as the filtering criterion, the remaining traffic whose destination IP address resolution result is outside of China (i.e., the destination is not local) is defined as Category I unknown traffic.

[0091] In one embodiment, for example

[0092] For example, let's take accessing http: / / 112.##.214.75:8080 / 123456.html in a browser:

[0093] Traffic between browser and Shadowsocks proxy, such as Figure 3 As shown (packet capture on this machine).

[0094] Traffic between Shadowsocks proxy and Shadowsocks server, such as Figure 4As shown in the image (packet capture on DPI).

[0095] The packet's 5-tuple information ([tcp,10.8.2.36,49799,144.34.181.85,443]) shows a destination port of 443, but it does not meet the characteristics of the TLS protocol. Therefore, DPI will definitely identify it as an unknown protocol based on the first packet. DPI's GeoIP module detects that the destination IP (144.34.181.85) is not a domestic IP (Los Angeles, California, USA). Therefore, this flow will be further focused on.

[0096] In one embodiment, such as Figure 5 As shown, the step of inputting the first type of unknown traffic into the AI ​​encrypted traffic discrimination model to filter out the second type of suspected traffic that meets the statistical characteristics of encrypted traffic specifically includes:

[0097] Step 1021: Extract the payload data of data packets in the first type of unknown traffic.

[0098] Specifically, for the first type of unknown traffic obtained in step 101, each data packet is parsed one by one, and the protocol header information such as network layer and transport layer in the data packet is stripped off, and only the payload data used to carry the actual business data in the data packet is extracted.

[0099] For example, the overall length of a packet of a certain type of unknown traffic includes the protocol header and payload data. After parsing, the length of the extracted payload data is 614 bytes. Its hexadecimal form contains a continuous byte sequence such as 0x04, 0x02, 0x54, and 0x24. This part of the data is the core object for subsequent encryption feature calculation.

[0100] Step 1022: Calculate the information entropy value, bit density value, and byte randomness value of the payload data.

[0101] In one embodiment, the information entropy value H1 = -∑pi × log2pi; where pi is the ratio of the number of occurrences of a single value to the total length of the payload data.

[0102] The bit density value H2 = ∑Countbit(data_i) / dlen; where Countbit(data_i) is the number of times a bit 1 appears in each binary value, data_i is a single value in the payload data, and dlen is the total length of the payload data.

[0103] The byte randomness value H3 = count(key) / 255; where H3 is the number of different values ​​that actually appear in the payload data within the range of 0-0xff.

[0104] In one embodiment, based on the payload data extracted in step 1021, three encryption feature parameters (including information entropy value, bit density value, and byte randomness value) are calculated using the following methods:

[0105] The information entropy value is calculated as follows: First, the frequency of each value in the payload data range of 0-0xff (i.e., 0 to 255) is counted to obtain the distribution statistics of each value. Then, the information entropy is calculated according to the formula H1=-∑pi×log2pi, where pi is the ratio of the frequency of a single value to the total length of the payload data (i.e., the percentage of that value's occurrence). For example, in 614 bytes of payload data, 0x27 appears 6 times, 0xd6 appears 6 times, and 0x1c appears 7 times. The percentage of each value's occurrence varies. The sum of (pi×log2pi) of all values ​​is then taken as a negative value, resulting in an information entropy value of 5.3224.

[0106] Calculate the bit density value: First, convert each value in the payload data into 8-bit binary form, and count the number of occurrences of bit 1 in each binary value (denoted as Countbit(data_i), where data_i is a single value in the payload data); then calculate using the formula H2=∑Countbit(data_i) / dlen, where dlen is the total length of the payload data (in bytes). For example, the value 0xe3 converted to binary 11100011 has a bit 1 count of 5; the value 0x94 converted to binary 10010100 has a bit 1 count of 3; after accumulating the total bit 1 counts for all values, compare it with the total payload data length of 614 to obtain the bit density value of 4.1026.

[0107] Calculate the byte randomness value: Count the number of distinct values ​​actually appearing in the payload data within the range of 0-0xff (denoted as count(key)). Calculate this using the formula H3=count(key) / 255, where 255 is the total number of values ​​in the 0-0xff range. For example, in 614 bytes of payload data, there are 236 distinct values ​​in the 0-0xff range. Substituting these values ​​into the formula yields a byte randomness value of 0.9254.

[0108] Step 1023: When the information entropy value, bit density value and byte randomness value fall within the preset encrypted traffic threshold range, the first type of unknown traffic is determined to be the second type of suspected traffic.

[0109] In one embodiment, the preset encrypted traffic threshold range includes: an information entropy value range, a bit density value range, and a byte randomness value range; wherein the information entropy value range is 5.0~8.0, the bit density value range is 3.4~4.6, and the byte randomness value range is 0.8~1.0.

[0110] Specifically, the information entropy value, bit density value, and byte randomness value of the first type of unknown traffic calculated in step 1022 are compared with their respective preset threshold ranges. When all three feature parameters meet the condition of falling within their respective threshold ranges, the first type of unknown traffic is determined to be second type of suspected traffic. For example, if the information entropy value of a certain first type of unknown traffic is 5.3224, the bit density value is 4.1026, and the byte randomness value is 0.9254, all of which are within the aforementioned preset threshold ranges, it is therefore determined to be second type of suspected traffic.

[0111] In one embodiment, the replay test includes at least full payload replay, tampered payload replay, and partial payload replay; wherein, full payload replay includes sending an untampered full data packet payload to the target server and detecting whether a valid response is received; tampered payload replay includes sending at least one byte of tampered data packet payload to the target server and detecting whether the connection is immediately terminated; partial payload replay includes sending a payload containing only the first few bytes of the data packet payload to the target server and detecting whether the connection enters a waiting state and eventually times out and closes.

[0112] In the tampered payload playback, the tampered bytes are located in the message authentication code portion of the payload data.

[0113] Before detailing the replay test, this embodiment first analyzes the encryption method of Shadowsock proxy traffic. Specifically, it uses the AES-256-GCM (AEAD encryption / signature) encryption method as an example to briefly analyze the Shadowsock data block encryption steps, which forms the basis for subsequent replay tests.

[0114] In one embodiment, Chunk = 32 bytes (iv) + SOCKS5 encrypted content + data 1 encrypted content + data 2 encrypted content + ... + data n encrypted content. AEAD (Authenticated Encryption with Associated Data) is an encryption method that simultaneously provides confidentiality, integrity, and authentication.

[0115] 32-byte IV: Random Initialization Vector, 32 bytes of plaintext, which is essentially a random number;

[0116] SOCKS5 content = 2 bytes length + 16 bytes length_hmac + 7 bytes payload + 16 bytes payload_hmac;

[0117] 7-byte payload: 0x01 (1-byte fixed value) + 4-byte IPv4 address + 2-byte port;

[0118] The data encryption format is: 2 bytes length + 16 bytes length_hmac + n bytes payload + 16 bytes payload_hmac. In the above example, the 614 bytes of content are the encrypted result.

[0119] Based on the encryption method for Shadowsock proxy traffic described above, in one embodiment, such as Figure 6 As shown, the playback test specifically includes:

[0120] Step 1031: Create a socket client, establish communication with the target IP and target port, send a complete data packet payload, and receive the content returned by the server. If the size of the returned content is consistent with the actual response content, then the corresponding traffic is confirmed to be suspected Shadowsocks proxy traffic.

[0121] Based on the five-tuple information of the second type of suspected traffic, the corresponding destination IP address and destination port are extracted (e.g., destination IP is 144.34.181.85, destination port is 443). A socket client is then created, and a TCP connection is established with the aforementioned destination IP and destination port to ensure a smooth communication link. The complete payload data (e.g., a 614-byte encrypted data block containing a 32-byte IV, complete SOCKS5 encrypted content, and encrypted business data segments) is extracted from the second type of suspected traffic packets and sent as is to the destination server.

[0122] After sending, continuously listen for and receive the response content returned by the server, recording the length of the response data. Finally, compare the length of the received response content with the actual response content size in this business scenario (such as the 275-byte response for static webpage access). If they match, it indicates that the server can correctly parse and respond with the complete encrypted payload, which is consistent with the processing logic of the Shadowsock server. Therefore, the corresponding traffic is confirmed to be suspected Shadowsocks proxy traffic.

[0123] Since each part of the Shadowsock encrypted data block is an indispensable whole, and HMAC verification depends on complete field information, only by sending the complete 614 bytes of encrypted data (including a 32-byte IV, complete SOCKS5 encrypted content, and all encrypted business data segments) can the Shadowsock server parse the HMAC checksum and format to identify it as a legitimate proxy connection request, and then return a response corresponding to the actual business (such as 275 bytes of response data). If it is non-Shadowsock traffic, its data format does not meet the above fixed structure, and even if it is fully replayed, a matching response cannot be obtained. Therefore, this test can preliminarily verify the proxy attributes of the traffic.

[0124] In one embodiment, such as Figure 7 As shown, the actual operation verification results of the complete payload replay test verify that after sending the complete payload, the size of the response returned by the server is consistent with the actual business response, which is consistent with the processing characteristics of Shadowsock proxy traffic, thus confirming the conclusion that the traffic is suspected Shadowsocks proxy traffic.

[0125] Step 1032: Create a socket client, establish communication with the target IP and target port, tamper with the last byte of the data packet payload and send it. If the server immediately terminates the communication, the corresponding traffic is confirmed to be suspected Shadowsock proxy traffic.

[0126] This process follows the same logic as step 1031, establishing a TCP connection with the server using the destination IP, destination port, and socket client creation. The complete data packet payload (e.g., 614 bytes of encrypted data) of the second type of suspected traffic is extracted. The last byte of this payload is then modified (if the byte is non-zero, it is changed to 0; if it is zero, it is changed to 1). Essentially, this corrupts the HMAC checksum of the data segment at the end of the packet.

[0127] After the modified payload is sent to the server, the communication link status is monitored in real time. Since the Shadowsock server uses AEAD encryption mode, it verifies data integrity via HMAC. A modified payload will cause verification to fail, and the server will terminate the communication directly according to the encryption rules. Therefore, if the server immediately disconnects after receiving the modified payload, it indicates that the server has a Shadowsock proxy integrity verification mechanism, confirming the corresponding traffic as suspected Shadowsock proxy traffic.

[0128] In one embodiment, the integrity of AEAD and the HMAC verification mechanism determine that as long as any byte in the encrypted data block is modified (choosing to modify the last byte, which essentially corrupts the HMAC checksum of the last data segment), the Shadowsock server will directly determine that the data has been tampered with during HMAC verification and will immediately terminate communication according to its encryption rules (instead of returning a normal response). The verification logic for non-proxy traffic (such as ordinary HTTPS traffic) is different; after tampering, there may still be a response or a different response method. Therefore, this test can further corroborate the Shadowsock proxy properties of the traffic.

[0129] In one embodiment, such as Figure 8 As shown, the tampered payload triggered the HMAC verification failure mechanism of the Shadowsock server, and the server directly terminated the communication. This result meets the criteria for confirming that the corresponding traffic is suspected Shadowsock proxy traffic.

[0130] Step 1033: Create a socket client, establish communication with the target IP and target port, and send a data packet payload containing the first preset number of bytes of SOCKS5 content. If the server does not respond and the client actively closes the connection after a preset time, the corresponding traffic is confirmed to be suspected Shadowsock proxy traffic.

[0131] This involves establishing a TCP connection between the socket client and server based on the five-tuple information of the second type of suspected traffic. The payload contains a predetermined number of bytes of SOCKS5 encrypted content (41 bytes, based on the structure of SOCKS5 encrypted content; this portion contains the core fields of SOCKS5 connection control but lacks the complete HMAC checksum and subsequent encrypted business data segments). Only this 41-byte portion of the payload is sent to the server, and the connection is then maintained while listening for server responses.

[0132] The SOCKS5 encrypted content is the core of the Shadowsock server's identification of proxy connections. Only after receiving the complete 32-byte IV + SOCKS5 encrypted content + subsequent business data will the server initiate the proxy forwarding process. If only the first 41 bytes are replayed (containing only part of the SOCKS5 encrypted content, lacking the complete HMAC checksum and subsequent data), the server will be unable to complete the HMAC check due to the incomplete data format and will remain in a waiting state for complete data, failing to return a response and ultimately causing the client to time out and close the connection. This phenomenon differs from the processing logic of non-proxy traffic (such as ordinary TCP traffic where partial data reception may be directly rejected) and is a crucial basis for distinguishing proxy traffic.

[0133] In one embodiment, since the Shadowsock server needs to receive the complete encrypted data block (including a 32-byte IV, the complete SOCKS5 encrypted content, and subsequent business data) to complete parsing and verification, if only a partial payload is received, the server will remain in a waiting state for complete data due to incomplete data format and inability to pass HMAC verification, and will not return any response. If the server remains unresponsive and the client actively closes the connection after a preset time (e.g., 10 seconds), which conforms to the TCP segmentation transmission and data verification logic of the Shadowsock proxy, the corresponding traffic is confirmed as suspected Shadowsock proxy traffic.

[0134] In one embodiment, such as Figure 9 As shown, only the first 41 bytes are replayed. After waiting for 10 seconds, there is no server response. The client actively closes the socket connection. The Shadowsock server does not respond because the data format is incomplete and cannot complete the verification. In the end, the client times out and disconnects. This result meets the judgment condition in step 1033 to confirm that the corresponding traffic is suspected Shadowsock proxy traffic.

[0135] In one embodiment, such as Figure 10 As shown, the method further includes:

[0136] Step 201: In the replay test, record the first round-trip time from sending the data packet to receiving the first response packet, and the second round-trip time from sending the data packet to receiving the complete response or closing the connection.

[0137] In the process of performing full payload replay, tampered payload replay, and partial payload replay on the second type of suspected traffic, the timestamp recording function is enabled simultaneously to accurately capture two key time nodes and calculate the round-trip latency for the two types of traffic.

[0138] In one embodiment, the recording logic for the first round-trip delay is as follows: the timer starts from the moment the socket client sends a test data packet (full payload, tampered payload, or partial payload) to the target server (e.g., destination IP 144.34.181.85, destination port 443) and stops from the moment the client first receives the first response packet returned by the server (which may be a TCP acknowledgment packet, a business response packet, etc.). This time interval is the first round-trip delay, which essentially reflects the transmission time of the basic network link between the client and the server, and does not include the time consumed by complex business processing or data forwarding.

[0139] The recording logic for the second round-trip delay is as follows: the timing starts from the moment the test data packet is sent, and stops depending on the different scenarios of the replay test. If it is a complete payload replay and the server returns a complete business response, the timing stops when the complete response packet is received. If it is a tampered payload replay or a partial payload replay and the server terminates the connection, the timing stops the moment the connection is detected to be closed. This time interval is the second round-trip delay, which includes the time consumed by the server in the entire process of data packet processing, verification, and forwarding (if it is a proxy service).

[0140] For example, in a full payload replay test, if the time when the 614-byte data packet is sent is T0, the time when the first response packet is received is T1, and the time when the full response packet is received is T2, then the first round-trip delay = T1 - T0, and the second round-trip delay = T2 - T0.

[0141] Step 202: If the second round-trip time is greater than the first round-trip time, it is used as an auxiliary basis for determining whether the second type of suspected traffic is suspected Shadowsocks proxy traffic.

[0142] For regular non-proxy traffic, the server does not need to forward third-party data and only needs to process requests locally. The difference in round-trip latency between the two types is usually small. However, for Shadowsock proxy traffic, after receiving data packets, the server needs to decrypt the data, extract the target IP and port, and then forward the request to the third-party target server. After receiving the third-party response, it encrypts and sends it back to the client. The extra decryption-forwarding-encryption process significantly increases the time consumption.

[0143] Therefore, when the second round-trip latency is greater than the first round-trip latency, and the difference reaches a reasonable threshold (e.g., the first round-trip latency is 50ms and the second round-trip latency is 300ms), it indicates that the server has an additional time-consuming step when processing test data packets, which is highly consistent with the working logic of the Shadowsock proxy server.

[0144] The latency difference result will not be used as a sole criterion for judgment. Instead, it will be combined with the results of matching the response size of the complete payload playback, the immediate disconnection of the tampered payload playback, and the timeout and no response of the partial payload playback to form a multi-dimensional verification, further reducing the probability of misjudgment and providing strong auxiliary support for the final determination that the second type of suspected traffic is suspected Shadowsocks proxy traffic.

[0145] In one embodiment, such as Figure 11 As shown, the first round-trip delay is result1, and the second round-trip delay is result2, where:

[0146] result1 = time 2 – time 1; result2 = time 4 – time 1. The result1 value represents the time distance between the client and the server (TCP three-way handshake, without further access to third-party servers in between). If result2 is significantly greater than result1 (e.g., the difference reaches a reasonable threshold), it indicates that during the time interval of result2, the server may have been a VPN server, accessing a third-party server, thus resulting in a longer processing time.

[0147] In summary, this embodiment addresses the shortcomings of existing Shadowsock VPN traffic identification technologies, which rely solely on packet entropy and are prone to misjudgment, lacking further precise identification methods. It proposes a comprehensive identification method based on traffic filtering, encrypted feature analysis, packet replay testing, and round-trip latency verification. First, DPI technology is used to exclude traffic with known protocols. Then, combining the five-tuple and GeoIP geolocation, a first category of unknown traffic with non-local destinations is identified. Next, the packet payload data of this type of traffic is extracted, and the entropy, bit density, and byte randomness values ​​are calculated to identify a second category of suspected traffic that meets the statistical characteristics of encrypted traffic. Subsequently, precise verification is achieved through three tests: complete payload replay (verifying response size consistency), tampered payload replay (verifying immediate server disconnection), and partial payload replay (verifying server non-response and client timeout). Simultaneously, the first and second round-trip latencies in the replay tests are recorded and compared, using the latency difference as an auxiliary basis. This embodiment, through its multi-dimensional and progressive identification logic, effectively compensates for the shortcomings of single-feature identification, significantly reduces the probability of misjudgment, and achieves accurate and efficient identification of Shadowsock proxy traffic.

[0148] Example 2:

[0149] Example 1 provides an AI-enabled traffic replay-based Shadowsocks proxy traffic identification method. This example proposes an AI-enabled traffic replay-based Shadowsocks proxy traffic identification device, which includes a processor and a memory for storing processor-executable instructions. The processor is configured to execute the AI-enabled traffic replay-based Shadowsocks proxy traffic identification method described in Example 1.

[0150] like Figure 12 As shown, the AI-enabled traffic replay type Shadowsocks proxy traffic identification device includes a processor 21 and a memory 22, wherein the processor 21 and the memory 22 can be connected by a bus or other means.

[0151] Processor 21 can be a Central Processing Unit (CPU). Processor 21 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0152] The memory 22, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the AI-enabled traffic replay type Shadowsocks proxy traffic identification method in Embodiment 1 of this invention. The processor executes various functional applications and training processes by running the non-transitory software programs, instructions, and modules stored in the memory.

[0153] The memory 22 may include a program storage area and a training storage area. The program storage area may store the operating system and applications required for at least one function; the training storage area may store training data created by the processor. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory, or other non-transitory solid-state storage device. In some embodiments, the memory 22 may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof. The one or more modules stored in the memory 22, when executed by the processor 21, perform functions such as... Figure 1 The AI-enabled traffic replay-based Shadowsocks proxy traffic identification method shown in Example 1. For specific details of the above AI-enabled traffic replay-based Shadowsocks proxy traffic identification method, please refer to the relevant documentation. Figure 1 , Figure 2 and Figure 3 The relevant descriptions and effects in the embodiments shown are for reference only and will not be repeated here.

[0154] This embodiment also provides a computer storage medium storing a computer program that can be executed by a processor to complete the AI-enabled traffic replay type Shadowsocks proxy traffic identification method described in Embodiment 1.

[0155] The computer storage medium stores computer-executable instructions, which can execute the AI-enabled traffic replay Shadowsocks proxy traffic identification method in any of the above method embodiments. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0156] The specific steps of the AI-enabled traffic replay type Shadowsocks proxy traffic identification method are described in Example 1, and will not be repeated in this example.

[0157] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An AI-enabled method for identifying Shadowsocks proxy traffic through traffic replay, characterized in that, include: Network traffic is input into a pre-trained AI unknown traffic identification model to filter out the first type of unknown traffic that does not match any known protocol; The first type of unknown traffic is input into the AI ​​encrypted traffic discrimination model to filter out the second type of suspected traffic that meets the statistical characteristics of encrypted traffic. Perform a replay test on the data packets corresponding to the second type of suspected traffic, and determine whether the second type of suspected traffic is suspected Shadowsocks proxy traffic based on the response results of the replay test; The replay test includes at least full payload replay, tampered payload replay, and partial payload replay; wherein, full payload replay includes sending an untampered complete data packet payload to the target server and detecting whether a valid response is received; Tampered payload replay involves sending at least one byte of the tampered data packet payload to the target server and detecting whether the connection is immediately terminated. Partial payload replay involves sending a payload containing only the first few bytes of the packet payload to the target server, detecting whether the connection enters a waiting state, and eventually closing it after a timeout.

2. The AI-enabled traffic replay type Shadowsocks proxy traffic identification method according to claim 1, characterized in that, The step of inputting the first type of unknown traffic into the AI ​​encrypted traffic discrimination model to filter out the second type of suspected traffic that meets the statistical characteristics of encrypted traffic specifically includes: Extract the payload data of data packets from the first type of unknown traffic; Calculate the information entropy value, bit density value, and byte randomness value of the payload data; When the information entropy value, bit density value, and byte randomness value fall within the preset encrypted traffic threshold range, the first type of unknown traffic is determined to be the second type of suspected traffic.

3. The AI-enabled traffic replay type Shadowsocks proxy traffic identification method according to claim 2, characterized in that, The preset encrypted traffic threshold range includes: information entropy value range, bit density value range, and byte randomness value range; information entropy value H1=-∑pi×log2pi; where pi is the ratio of the number of occurrences of a single value to the total length of the payload data; The bit density value H2 = ∑Countbit(data_i) / dlen; where Countbit(data_i) is the number of times a bit 1 appears in each binary value, data_i is a single value in the payload data, and dlen is the total length of the payload data; The byte randomness value H3 = count(key) / 255; where H3 is the number of different values ​​that actually appear in the payload data within the range of 0-0xff. The information entropy value ranges from 5.0 to 8.0, the bit density value ranges from 3.4 to 4.6, and the byte randomness value ranges from 0.8 to 1.

0.

4. The AI-enabled traffic replay-based Shadowsocks proxy traffic identification method according to claim 1, characterized in that, The complete payload replay specifically includes: creating a socket client, establishing communication with the target IP and target port, sending a complete data packet payload, receiving the content returned by the server, and if the size of the returned content is consistent with the actual response content, then the corresponding traffic is confirmed to be suspected Shadowsocks proxy traffic; The tampered payload replay specifically includes: creating a socket client, establishing communication with the target IP and target port, tampering with the last byte of the data packet payload and sending it; if the server immediately terminates the communication, the corresponding traffic is confirmed as suspected Shadowsock proxy traffic. Partial payload replay specifically includes: creating a socket client, establishing communication with the target IP and target port, sending a data packet payload containing the first preset number of bytes of SOCKS5 content, and if the server does not respond and the client actively closes the connection after a preset time, then the corresponding traffic is confirmed to be suspected Shadowsock proxy traffic.

5. The AI-enabled traffic replay type Shadowsocks proxy traffic identification method according to claim 1, characterized in that, In the tampered payload playback, the tampered bytes are located in the message authentication code portion of the payload data.

6. The AI-enabled traffic replay-based Shadowsocks proxy traffic identification method according to claim 1, characterized in that, The method further includes: In the replay test, the first round-trip time from sending a data packet to receiving the first response packet, and the second round-trip time from sending a data packet to receiving a complete response or closing the connection are recorded. If the second round-trip time is greater than the first round-trip time, it serves as an auxiliary basis for determining whether the second type of suspected traffic is suspected Shadowsocks proxy traffic.

7. The AI-enabled traffic replay type Shadowsocks proxy traffic identification method according to claim 1, characterized in that, The process of inputting network traffic into a pre-trained AI unknown traffic identification model to filter out the first type of unknown traffic that does not match any known protocol specifically includes: Deep packet inspection technology is used to identify and exclude traffic with known protocols in order to obtain the remaining traffic; For the remaining traffic, it is filtered based on the five-tuple information and the geographical location information of the destination IP address, and traffic whose destination is not local is classified as the first type of unknown traffic.

8. An AI-powered traffic replay type Shadowsocks proxy traffic identification device, characterized in that, The AI-enabled traffic replay type Shadowsocks proxy traffic identification device includes: a processor and a memory for storing processor-executable instructions; The processor is configured to execute the AI-enabled traffic replay Shadowsocks proxy traffic identification method according to any one of claims 1-7.

9. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors to perform the AI-enabled traffic replay Shadowsocks proxy traffic identification method as described in any one of claims 1-7.

Images