A method for extracting a QUIC protocol traffic SNI field for a sub-packet mechanism

Abstract

The application discloses a kind of QUIC protocol flow SNI field extraction methods for subpacket mechanism, first five-tuple group flow is carried out to the internet traffic captured, based on the special field mark of QUIC protocol, extract the Initial packet sent by client in QUIC flow;Second, based on the construction client Initial packet header protection key and client initial key of QUIC protocol, remove the header protection of client Initial packet and decrypt the ciphertext load;In the application subpacket mechanism of QUIC protocol flow, the load part of Initial packet is composed of out-of-order frame, for the out-of-order frame, extract the Length field and Offset field of each frame, finally filter out the TLS record in QUIC flow, extract the SNI field information contained in ClientHello fragment.This scheme can realize the application identification of QUIC flow, fill the network management capability vacancy of QUIC flow.

Description

Technical Field

[0001] This invention relates to a method for extracting the SNI field from QUIC protocol traffic oriented towards packet splitting mechanisms, belonging to the field of computer network security technology. Background Technology

[0002] QUIC (Quick UDP Internet Connections) is a new network transport protocol based on UDP (User Datagram Protocol). In 2012, Google introduced QUIC to meet the internet's demands for high bandwidth, low latency, and strong security. In 2018, the new HTTP / 3 standard implemented QUIC on top of UDP. The IETF standardized QUIC as RFC 9000 in 2021 and released the official standard document for the QUIC Version2 protocol, RFC 9369, in 2023.

[0003] The QUIC protocol implements error detection, packet loss detection, congestion control, flow control, and data encryption on top of the UDP protocol, while possessing the advantages of both UDP and TCP (Transmission Control Protocol). Compared to traditional transport layer protocols, QUIC offers enhanced security, privacy, and flexibility. Due to these characteristics, well-known companies such as Google, Facebook, Amazon, Apple, Bilibili, and Netflix have deployed QUIC-based network services, and an increasing number of enterprises and organizations are also exploring providing QUIC-based network services. According to the latest statistics from September 2024, approximately 8.1% of websites are using the QUIC protocol.

[0004] TCP-based network services typically use the TLS (Transport Layer Security) protocol to provide security protection for users. With the advent of the QUIC protocol, UDP-based network services can also provide secure transmission. However, encrypted traffic transmission also presents new challenges for network management and traffic analysis. The SNI (Server Name Indication) field, as key extended information in encrypted network traffic, enables network administrators to identify the specific domain names accessed by users, thereby facilitating traffic analysis, domain name filtering, load balancing, and management policy enforcement, improving network resource utilization and management efficiency. In recent years, several studies have proposed methods for extracting SNI field information from encrypted traffic, mainly focusing on two directions: SNI field information extraction in TLS-encrypted transmission scenarios and SNI field information extraction in QUIC-encrypted transmission scenarios.

[0005] In TLS-encrypted transmission scenarios, the SNI field information is encapsulated in the TLS handshake data before the client and server negotiate the key. At this stage, the communicating parties do not share a common encryption key; therefore, the SNI field information is transmitted in plaintext. Existing patents for extracting SNI field information from TLS protocols capture the ClientHello data packet sent by the client early in the communication process, parse the byte stream, and extract the extension item with ExtensionType set to server_name to extract the SNI field information. Since both HTTP / 1.1 and HTTP / 2 implement encrypted transmission based on the TLS protocol, methods for extracting SNI field information from TLS protocols can also be applied to network service traffic based on HTTP / 1.1 and HTTP / 2.

[0006] In QUIC protocol encrypted transmission scenarios, the metadata in the encrypted data packet header and payload of the QUIC protocol leaves almost no plaintext information during network transmission. While plaintext TLS data before the key negotiation phase may still leak some user privacy, the QUIC protocol derives header protection keys and initial keys from certain special fields in the Initial packet during the handshake phase, used for the encrypted transmission of the Initial packet. Therefore, QUIC traffic data is transmitted in the network almost entirely as encrypted data. However, there are existing patents for extracting SNI field information from the QUIC protocol. Based on the QUIC protocol and the analysis of QUIC traffic data, the key is calculated to decrypt the ciphertext portion and extract the SNI field information. The HTTP / 3 protocol standard implements encrypted transmission based on the QUIC protocol; therefore, methods for extracting SNI field information from the QUIC protocol can be applied to network service traffic based on HTTP / 3.

[0007] However, existing methods for extracting SNI field information from the QUIC protocol have become increasingly unsuitable for some scenarios using QUIC transmission as the QUIC protocol has improved. Since its standardization in 2021, the QUIC protocol has been continuously evolving. Early QUIC traffic did not utilize the packet fragmentation mechanism designed in RFC 9000; therefore, a single QUIC data packet contained only a single, complete frame. However, to minimize the bandwidth and computational resources consumed by each data packet, the sender can encapsulate multiple frames within a single data packet before sending an underutilized packet, thus avoiding the transmission of numerous small data packets—this is the QUIC packet fragmentation mechanism. In QUIC protocols using the packet fragmentation mechanism, TLS records may be encapsulated within multiple encrypted frames, and the frame order within the Initial data packet may be scrambled. Therefore, existing patents for extracting SNI field information from QUIC traffic using the packet fragmentation mechanism cannot extract SNI field information from such traffic. Furthermore, with the widespread application of the QUIC protocol, the proportion of QUIC protocol traffic in the Internet is constantly increasing, and existing patents for analyzing QUIC traffic are insufficient to handle the massive amount of Internet traffic.

[0008] The current challenges are: (1) how to extract key derivation material from QUIC protocol data packets based on the packet-splitting mechanism to generate a key for decrypting the ciphertext payload; (2) how to restore the out-of-order frames in QUIC protocol data packets based on the packet-splitting mechanism to form a complete TLS record and extract the SNI field information from the ClientHello fragment. Summary of the Invention

[0009] To extract SNI field information from QUIC protocol traffic using a packet-segmentation mechanism, this invention proposes a method for extracting SNI field information from QUIC protocol traffic oriented towards packet-segmentation. This method extracts SNI field information from captured QUIC streams in internet traffic by analyzing the QUIC protocol and packet-segmentation mechanism. The analysis method in this invention consists of four stages: QUIC stream Initial packet capture, encrypted payload data decryption, complete TLS record restoration, and SNI field information extraction. First, the captured internet traffic is grouped into five-tuples, and the Initial packet sent by the client is extracted based on the special field flags of the QUIC protocol. Second, key derivation material is extracted to construct the header protection key and the client initial key, and the header protection of the client Initial packet is removed and the encrypted payload is decrypted. Next, for out-of-order frames in the QUIC protocol packets, the Length and Offset fields of each frame are extracted, and the out-of-order frames are reordered to restore the complete plaintext payload. Finally, TLS records in the QUIC stream are filtered out, and the SNI field information contained in the ClientHello fragment is extracted. This invention can be used to parse QUIC protocol traffic using application packet splitting mechanisms, providing a foundation for in-depth analysis of QUIC traffic.

[0010] To achieve the objectives of this invention, the technical solution is as follows: A method for extracting the SNI field of QUIC protocol traffic based on a packet-splitting mechanism, the method comprising the following steps:

[0011] Step (1) Capture traffic transmitted over the Internet and filter out non-QUIC traffic. Use the Farm hash function and a custom Bloom Filter structure to group the captured traffic into five-tuples to obtain clean QUIC stream traffic data.

[0012] Step (2) According to the special field flags specified in the QUIC protocol standardization document RFC 9000, traverse each QUIC stream and extract the Initial data packets sent by the client. The number of Initial data packets sent by the client in the QUIC stream with the application of packet splitting mechanism is 1-3.

[0013] Step (3) For the extracted Initial data packet, construct the QUIC packet structure to parse the data packet, construct the data packet header protection key and the client initial key, remove the header protection and decrypt the ciphertext payload to obtain the plaintext payload;

[0014] Step (4) Based on the plaintext payload obtained in step (3), according to the packet splitting mechanism of the QUIC protocol, read the field information and determine the frame boundaries to divide the plaintext payload into different frames;

[0015] Step (5) By reading the data packet header information and the information of each frame, calculate the actual position of each frame in the original payload, restore the position of the out-of-order frames, and obtain the original payload.

[0016] Step (6) Based on the original payload obtained in step (5), filter TLS records. If the first Initial packet does not contain a TLS record, then execute the process from step (3) to step (5) sequentially on the subsequent Initial packets in the QUIC stream, retrieve the ClientHello fragment for the TLS record, and extract the SNI field information contained therein.

[0017] Furthermore, in step (1), the steps for obtaining pure QUIC stream traffic data are as follows:

[0018] (1.1) Capture all network traffic passing through the preset network interface, perform preliminary filtering based on UDP protocol type and destination port (443 or custom port), filter TCP protocol type and other non-QUIC protocol traffic, and retain potential QUIC packets;

[0019] (1.2) Based on the preliminary screening results, check whether the transport layer payload header field contains the QUIC protocol identifier. If it contains the QUIC protocol identifier, it is determined to be a QUIC data packet and retained.

[0020] (1.3) For all confirmed QUIC packets, extract the 5-tuple (source IP address, destination IP address, source port, destination port, transport layer protocol), use the Farm hash function to generate a unique stream identifier, merge packets with the same unique stream identifier, and finally output the complete QUIC stream data.

[0021] Furthermore, in step (2), the SNI field information is included in the ClientHello fragment of the TLS record, and the TLS record is encapsulated in one of the 1-3 Initial packets sent by the client. In the QUIC protocol, the Initial packet is a type of long header packet. To detect the Initial packet sent by the client, it is necessary to traverse the first few packets of the QUIC stream and verify whether the header type field and the long packet type field of the packet are the target fields.

[0022] Furthermore, in step (3), the steps for obtaining the plaintext payload are as follows:

[0023] (3.1) For the Initial data packet obtained in step (2), define the QUIC packet data structure, parse the QUIC layer data according to the QUIC protocol, and extract fields such as version number, connection identifier ID, data packet length, data packet sequence number, encrypted payload and AEAD identifier;

[0024] (3.2) Different versions of the QUIC protocol use different construction materials to generate header protection keys and initial keys. Based on the version number, determine the relevant functions, algorithms and materials for key generation, and construct the header protection key and client initial key.

[0025] (3.3) The QUIC protocol protects QUIC layer data by including header protection and payload encryption. Header protection hides the boundary between the data packet header and payload. The lower 4 bits of the first byte and the data packet sequence number field can be decrypted by using the header protection key.

[0026] (3.4) After determining the boundaries of the header and ciphertext payload in step (3.3), select the corresponding cryptographic algorithm according to the version number, use the initial key and AEAD identifier to decrypt the ciphertext payload and perform integrity verification to obtain the plaintext payload.

[0027] Furthermore, in step (4), the step of dividing the plaintext payload into different frames is as follows:

[0028] (4.1) Read the frame type flag bit of the first byte of the plaintext payload, distinguish frame types such as CRYPTO / ACK / PADDING according to the frame type mapping table (0x00-0x1F) defined by the QUIC protocol, and determine the frame parsing mode;

[0029] (4.2) Read the length field of the frame to determine the start and end positions of the frame and verify whether the length field value exceeds the remaining payload space;

[0030] (4.3) If the length field value does not exceed the length of the remaining payload, then the corresponding length of the byte sequence is cut into independent frame entities according to the start position of the current frame and the length field value;

[0031] (4.4) If the end position of the current frame is not the end position of the data packet, set the start position of the next frame to the end position of the current frame shifted by 1 byte, and repeat steps (4.1), (4.2) and (4.3) until the end position of the data packet is reached.

[0032] Furthermore, in step (5), the steps for obtaining the original load are as follows:

[0033] (5.1) In the QUIC protocol traffic with packet splitting mechanism, the TLS record sent by the client may be encapsulated in multiple out-of-order encrypted frames, and padding frames are inserted between the frames. Therefore, after decryption, it is necessary to restore the out-of-order frames. To restore the order of the frames, it is necessary to first calculate the length of the frame and the offset relative to the first byte. After reading the length field of each frame in step (4), it is also necessary to read the offset field of the frame.

[0034] (5.2) The offset field determines the position of the relative header in the Initial data packet in the frame. The absolute position of each frame can be calculated through the joint length field.

[0035] (5.3) Traverse all non-filled frames, sort each frame by offset field value, and output the restored original payload.

[0036] Furthermore, in step (6), the steps for extracting the SNI field information are as follows:

[0037] (6.1) Based on the original payload restored in step (5), the TLS record fragments are identified by the special identifier field of the TLS protocol, the length information of the TLS record is extracted, and the fragments are merged to obtain the complete TLS record;

[0038] (6.2) The SNI field is contained in the extension of a TLS record of type Handshake and handshake type ClientHello (field value 0x01). Extract the handshake type field of the TLS record and verify whether it is of type ClientHello.

[0039] (6.3) If the handshake type of the TLS record is ClientHello, move the current pointer forward to skip the TLS length field (3 bytes) and the Handshake length field (3 bytes), and locate the starting position of the extension field through the CipherSuites part after the SessionID / Random field;

[0040] (6.4) Recursively search the TLS extension list to find the extension item with ExtensionType as server_name (field value is 0x00), parse the length field value in the NameList structure, determine the start and end positions of the SNI field, and obtain the SNI field value.

[0041] An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the aforementioned method for extracting the SNI field of QUIC protocol traffic oriented towards a packet-splitting mechanism.

[0042] A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, implement the aforementioned method for extracting the SNI field of QUIC protocol traffic oriented towards a packet-splitting mechanism.

[0043] Compared with the prior art, the technical solution of the present invention has the following beneficial technical effects.

[0044] (1) This invention proposes a method for extracting the SNI field of QUIC protocol traffic based on the packet splitting mechanism. By analyzing the QUIC protocol traffic data and standard files that apply the packet splitting mechanism, the method captures the QUIC stream from the Internet traffic and extracts the SNI field information therein.

[0045] (2) The QUIC traffic analysis method for packet splitting mechanism proposed in this invention uses the Farm hash function and a custom Bloom Filter data structure, which can process a large amount of Internet traffic in real time under limited resources.

[0046] (3) The QUIC traffic analysis method for the packet sub-mechanism proposed in this invention realizes the application identification of QUIC traffic by processing the QUIC traffic in real time and extracting SNI field information, thus filling the gap in network management capabilities for QUIC traffic. Attached Figure Description

[0047] Figure 1 This is the overall framework diagram;

[0048] Figure 2 This is a diagram of the decryption process;

[0049] Figure 3 This describes a method for extracting SNI field information. Detailed Implementation

[0050] The technical solutions provided by the present invention will be described in detail below with reference to specific embodiments. It should be understood that the following specific embodiments are only used to illustrate the present invention and are not intended to limit the scope of the present invention.

[0051] Specific Implementation: This invention provides a method for extracting the SNI field from QUIC protocol traffic oriented towards packet splitting mechanisms. Its overall framework is as follows: Figure 1 As shown, it specifically includes the following steps:

[0052] Step (1) Capture traffic transmitted over the Internet and filter out non-QUIC traffic. Use the Farm hash function and a custom Bloom Filter structure to group the captured traffic into five-tuples to obtain clean QUIC stream traffic data.

[0053] In one embodiment of the present invention, the steps for obtaining clean QUIC stream traffic data are as follows:

[0054] (1.1) Capture all network traffic passing through the preset network interface. Here, the Tcpdump tool is used. The network interface is specified by "-i". The initial filtering is based on the UDP protocol type and the target port. The target port includes the default HTTPS port 443 and some custom ports. TCP protocol type and other non-QUIC protocol traffic are filtered out, while potential QUIC packets are retained.

[0055] (1.2) Based on the preliminary screening results, check whether the transport layer payload header field contains the QUIC protocol identifier. The highest bit of the first byte of the transport layer payload of the first data packet in the QUIC stream is generally set to 0b1, indicating the long header data packet type in the QUIC protocol. The third and fourth bits are generally set to 0b00, indicating the initialization data packet type. The others are fixed bits. Therefore, we can check if the first 4 bits of the first byte of the transport layer payload are 0xc. If it contains the QUIC protocol identifier, that is, the first 4 bits of the first byte of the transport layer payload are 0xc, then it is determined to be a QUIC data packet and is retained.

[0056] (1.3) For all confirmed QUIC data packets, extract the quintuple, use the Farm hash function to calculate the hash value of the quintuple as the unique identifier of the stream, merge data packets with the same unique identifier of the stream, and finally output the complete QUIC stream data.

[0057] Step (2) According to the special field flags specified in the QUIC protocol standardization document RFC 9000, traverse each QUIC stream and extract the Initial data packets sent by the client. In the QUIC stream with the application of packet splitting mechanism, the number of Initial data packets sent by the client in each QUIC stream is 1-3.

[0058] In one embodiment of the present invention, the SNI field information is included in the ClientHello fragment of the TLS record, and the TLS record is encapsulated in one of the 1-3 Initial packets sent by the client. In the QUIC stream, the first packet is usually sent by the client. Since the number of Initial packets sent by the client in a QUIC stream with a packet fragmentation mechanism is 1-3, detecting the first 5 packets of the QUIC stream can ensure that no Initial packets sent by the client are missed. This can be achieved by verifying whether the packet header type field and the long packet type field are the target fields.

[0059] Step (3) For the extracted Initial data packet, construct the QUIC packet structure, parse the data packet byte stream, construct the data packet header protection key and client initial key based on the QUIC protocol, remove the header protection and decrypt the ciphertext payload to obtain the plaintext payload; Figure 2 This demonstrates the process of decrypting to obtain the plaintext payload;

[0060] In one embodiment of the present invention, the steps for obtaining the plaintext payload are as follows:

[0061] (3.1) For the Initial data packet obtained in step (2), define the QUIC packet data structure, parse the QUIC layer data according to the QUIC protocol, and extract fields such as version number, connection identifier ID, data packet length, data packet sequence number, encrypted payload and AEAD identifier; Table 1 lists the QUIC data packet header field information in the embodiment;

[0062] Table 1: QUIC Data Packet Header Field Information

[0063] (3.2) Different versions of the QUIC protocol use different construction materials to generate header protection keys and initial keys. The relevant functions, algorithms and materials for key generation are determined based on the version number. Here, the version number is 0x00000001. The materials for constructing the header protection key and the client initial key include a salt value of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and a destination connection ID of 0xf69441a23fb04232 for the original key material. The corresponding key derivation function is the HKDF function. The header protection key and the client initial key are generated through the HKDF-extract function and the HKDF-expand function.

[0064] (3.3) The QUIC protocol protects QUIC layer data by including header protection and payload encryption. Header protection is achieved by calculating a mask of a specific length and encrypting the lower 4 bits of the first byte and the data packet sequence number field using stream cipher encryption, thereby hiding the boundaries of the data packet header and payload. The cryptographic algorithm for generating the mask corresponding to version number 0x00000001 is the 128-bit ECB mode AES cryptographic algorithm. The lower 4 bits of the first byte and the data packet sequence number field can be decrypted using the header protection key according to the stream cipher decryption method.

[0065] (3.4) After determining the boundaries of the header and ciphertext payload in step (3.3), select the corresponding cryptographic algorithm according to the version number. The cryptographic algorithm corresponding to version number 0x00000001 is the 128-bit GCM mode AES cryptographic algorithm. Use the initial key and AEAD identifier to decrypt the ciphertext payload and perform integrity verification to obtain the plaintext payload.

[0066] Step (4) Based on the plaintext payload obtained in step (3), according to the packet splitting mechanism of the QUIC protocol, read the field information and determine the boundaries of different frames, and divide the plaintext payload into different frames;

[0067] In one embodiment of the present invention, the step of dividing the plaintext payload into different frames is as follows:

[0068] (4.1) Read the frame type flag bit of the first byte of the plaintext payload and distinguish different frames according to the frame type mapping table defined by the QUIC protocol. In this embodiment, the first byte of the payload is 0x06 and the frame type is CRYPTO frame. Table 2 lists the field information of the CRYPTO frame in this embodiment.

[0069] First Byte 0xcd Version 0x00000001 Destination Connection ID Length 0x08 Destination Connection ID 0xf69441a23fb04232 Source Connection ID Length 0x00 Source Connection ID NULL Token Length 0x00 Token NULL Length 0x44d0 Packet Number 0x50 Payload 0xxxx…xxx AEAD 0xf4002ac7d9f77815ba9660062c96373f

[0070] Table 2: Field Information of CRYPTO Frames

[0071] Frame Type 0x06 Offset 0x459c Length 0x03 Crypto Data 0xe40c06

[0072] (4.2) Read the frame length field, which is 0x03 here, to determine the start and end positions of the frame. The start position is the first byte of the payload part, and the end part is the length of the Frame Type field, Offset field, and Length field plus the value of the Length field, totaling 7 bytes, which does not exceed the remaining payload space;

[0073] (4.3) If the length field value does not exceed the length of the remaining payload, the corresponding length of the byte sequence is cut into independent frame entities according to the start position of the current frame and the length field value. Here, the byte stream from the 1st to the 7th byte is taken as the first out-of-order frame.

[0074] (4.4) If the end position of the current frame is not the end position of the data packet, set the start position of the next frame to the end position of the current frame shifted by 1 byte, and repeat steps (4.1), (4.2) and (4.3) until the end position of the data packet is reached. In this embodiment, there are a total of 22 out-of-order frames.

[0075] Step (5) By reading the data packet header information and the information of each frame, calculate the actual position of each frame in the original payload, restore the position of the out-of-order frames, and obtain the original payload.

[0076] In one embodiment of the present invention, the steps for obtaining the original load are as follows:

[0077] (5.1) In the QUIC protocol traffic with packet splitting mechanism, the TLS record sent by the client may be encapsulated in multiple out-of-order encrypted frames, and padding frames are inserted between the frames. Therefore, after decryption, it is necessary to restore the out-of-order frames. To restore the order of the frames, it is necessary to first calculate the length of the frame and the offset relative to the first byte. After reading the length field of each frame in step (4), it is also necessary to read the offset field of the frame. In this embodiment, the length and offset of the first out-of-order frame are 3 and 1436 (0x459c), respectively.

[0078] (5.2) The offset field determines the position of the relative header in the Initial data packet in the frame. The absolute position of each frame can be calculated by the joint length field. In this embodiment, the actual position of the first out-of-order frame should be the portion from byte 1436 to byte 1438 in the payload.

[0079] (5.3) Traverse all non-filled frames, sort each frame by offset field value, and output the restored original payload.

[0080] Step (6) Based on the original payload obtained in step (5), filter TLS records. If the first Initial packet does not contain a TLS record, then execute the process from step (3) to step (5) sequentially on the subsequent Initial packets in the QUIC stream, retrieve the ClientHello fragment for the TLS record, and extract the SNI field information contained therein. Figure 3 Demonstrates the acquisition

[0081] In one embodiment of the present invention, the steps for extracting SNI field information are as follows:

[0082] (6.1) Based on the original payload restored in step (5), the TLS record fragments are identified by the special identifier field of the TLS protocol, and the length information of the TLS record is extracted. In this embodiment, it is 1721 (0x0006b9). The fragments are merged to obtain the complete TLS record.

[0083] (6.2) The SNI field is contained in the extension of the TLS record of type Handshake and handshake type ClientHello. The field value is 0x01. Extract the handshake type field of the TLS record and verify whether it is of type ClientHello.

[0084] (6.3) If the handshake type of the TLS record is ClientHello, move the current pointer forward to skip the TLS length field (3 bytes) and the Handshake length field (3 bytes), and locate the starting position of the extension field through the CipherSuites part after the SessionID / Random field. In this embodiment, the starting position of the extension part is 5 bytes after the CipherSuites part.

[0085] (6.4) Recursively search the TLS extension list to find the extension item with ExtensionType set to server_name (field value 0x00). Parse the length field value in the NameList structure to determine the start and end positions of the SNI field and obtain its value. In this embodiment, it is the 7th extension item in the extension list, and the SNI field is bytes 6 to 42 of this extension item. Table 3 lists the SNI field information.

[0086] Table 3: SNI Field Information

[0087] Server Name list length 36 Server Name Type host_name(0) Server Name length 33 Server Name xxxxxxxxx.xxxxxxxxx.com

[0088] It should be noted that the above embodiments are not intended to limit the scope of protection of the present invention. Equivalent transformations or substitutions made based on the above technical solutions all fall within the scope of protection of the claims of the present invention.

Claims

1. A method for extracting the SNI field from QUIC protocol traffic oriented towards packet splitting mechanisms, characterized in that, The method includes the following steps: Step (1) Capture traffic transmitted over the Internet, filter out non-QUIC traffic, use the Farm hash function and a custom Bloom Filter data structure to obtain clean QUIC stream data based on the five-tuple pairs of captured traffic streams; Step (2) Based on the special field flags of the QUIC protocol, extract the Initial data packets sent by the client for each QUIC stream. The number of Initial data packets sent by the client in the QUIC stream with the application of packet splitting mechanism is 1-3. Step (3) For the Initial data packet extracted in step (2), construct the QUIC packet structure to parse the data packet, construct the client Initial data packet header protection key and client initial key based on the QUIC protocol, remove the header protection and perform decryption operation on the ciphertext payload to obtain the plaintext payload; Step (4) Based on the plaintext payload obtained in step (3), according to the packet splitting mechanism of the QUIC protocol, read the special field information, determine the frame boundary, and divide the plaintext payload into different frames; Step (5) By reading the data packet header information and the information of each frame, the actual position of each frame in the original payload is determined, and the disordered frames are reordered to obtain the original payload. Step (6) Extract TLS records based on the original payload obtained in step (5). If the first Initial packet does not contain TLS records, then execute the process from step (3) to step (5) sequentially on the subsequent Initial packets in the QUIC stream, retrieve the ClientHello fragment for the TLS record, and extract the SNI field information contained therein.

2. The method for extracting the SNI field of QUIC protocol traffic based on a packet-splitting mechanism according to claim 1, characterized in that, Step (1) specifically includes the following sub-steps: (1.1) Capture all raw traffic passing through the preset network interface, perform preliminary filtering based on UDP protocol type and target port, filter TCP protocol type and other non-QUIC protocol traffic, and retain potential QUIC packets; (1.2) Based on the preliminary screening results of (1.1), pure QUIC data packets are confirmed and retained by using the QUIC protocol identifier in the transport layer payload header field as the matching rule; (1.3) For all confirmed QUIC data packets, extract the quintuple, use the Farm hash function to generate a unique stream identifier, merge data packets with the same unique stream identifier, and finally output the complete QUIC stream data.

3. The method for extracting the SNI field of QUIC protocol traffic based on a packet-splitting mechanism according to claim 1, characterized in that, In step (2), the SNI field information is contained in the ClientHello fragment of the TLS record. The TLS record is usually one of the 1-3 Initial data packets sent by the client. In the QUIC protocol, the Initial data packet is a type of long header data packet. Therefore, to detect the Initial data packet sent by the client, it is necessary to traverse the first few client data packets in the QUIC stream and verify whether the header type field and long data packet type field of the data packet are the target fields.

4. The method for extracting the SNI field of QUIC protocol traffic based on a packet-splitting mechanism according to claim 1, characterized in that, Step (3) specifically includes the following sub-steps: (3.1) For the Initial data packet obtained in step (2), define the QUIC packet data structure, parse the QUIC layer data according to the QUIC protocol, and extract fields such as version number, connection identifier ID, data packet length, data packet sequence number, encrypted payload and AEAD identifier; (3.2) Different versions of the QUIC protocol data packets have different construction materials and algorithms for generating header protection keys and initial keys. The relevant functions, algorithms and materials for key generation are determined by the version number extracted in step (3.1), and the header protection key and client initial key are constructed. (3.3) The QUIC protocol protects QUIC layer data by including header protection and payload encryption. Header protection hides the boundary between the data packet header and payload. The lower 4 bits of the first byte and the data packet sequence number field can be decrypted by using the header protection key. (3.4) After determining the boundaries of the header and ciphertext payload in step (3.3), determine the cryptographic algorithm according to the version number, use the initial key and AEAD identifier to decrypt the ciphertext payload and perform integrity verification to obtain the plaintext payload.

5. The method for extracting the SNI field of QUIC protocol traffic oriented towards packet splitting mechanism according to claim 1, characterized in that, Step (4) specifically includes the following sub-steps: (4.1) Read the frame type flag of the plaintext payload, distinguish the CRYPTO / ACK / PADDING frame type according to the frame type mapping table defined by the QUIC protocol, and determine the frame parsing mode; (4.2) Read the length field of the frame to determine the start and end positions of the frame, and verify whether the length field value exceeds the remaining payload space; (4.3) If the length field value does not exceed the remaining payload space, then the byte sequence of the corresponding length is cut into independent frame entities according to the start position of the current frame and the length field value; (4.4) If the end position of the current frame is not the end position of the data packet, determine the start position of the next frame as the end position of the current frame shifted by 1 byte, and repeat steps (4.1), (4.2) and (4.3) until the end position of the data packet is reached.

6. The method for extracting the SNI field of QUIC protocol traffic oriented towards packet splitting mechanism according to claim 1, characterized in that, In step (5), (5.1) In the QUIC protocol traffic with packet splitting mechanism, the TLS record sent by the client may be encapsulated in multiple encrypted frames. The order of the frames in the Initial data packet is disordered, and padding frames are inserted between the frames. Therefore, after decryption, it is necessary to restore the disordered frames. To restore the order of the frames, it is necessary to first calculate the length and relative offset of the frames. After reading the length field of each frame in step (4), it is also necessary to read the offset field Offset of the frame. (5.2) The offset field determines the relative position of the Initial data packet in the frame, and the joint length field calculates the absolute position of each frame; (5.3) Traverse all non-filled frames, sort each frame by offset field value, and output the restored original payload.

7. The method for extracting the SNI field of QUIC protocol traffic oriented towards packet splitting mechanism according to claim 1, characterized in that, Step (6) specifically includes the following sub-steps: (6.1) Based on the original payload restored in step (5), identify TLS record fragments through the special identifier field of the TLS protocol, extract the length information of the TLS record, and merge the fragments to obtain the complete TLS record; (6.2) The SNI field is contained in the extension of the TLS record of type Handshake and handshake type ClientHello. Extract the handshake type field of the TLS record and verify whether it is 0x01, i.e., ClientHello type; (6.3) If the handshake type of the TLS record is ClientHello, move the current pointer forward to skip the TLS length field and Handshake length field in the header, and locate the starting position of the extension field through the CipherSuites part after the SessionID / Random field; (6.4) Recursively search the TLS extension list, find the extension item with ExtensionType as server_name, parse the length field value in the NameList structure, determine the start and end positions of the SNI field, and obtain the complete SNI field value.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements a method for extracting the SNI field of QUIC protocol traffic oriented towards a packet-splitting mechanism, as described in any one of claims 1 to 7.

9. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, the computer instruction implements a method for extracting the SNI field of QUIC protocol traffic for a packet-splitting mechanism as described in any one of claims 1-7.

Images