QuIC protocol flow SNI field extraction method oriented to subpackage mechanism

Abstract

The invention discloses a subpackage mechanism-oriented QUIC protocol flow SNI field extraction method, which comprises the following steps of: firstly, performing quintuple flow formation on captured internet flow, and extracting an Initial data packet sent by a client in a QUIC flow based on a QUIC protocol special field mark; secondly, a client Initial data packet header protection key and a client initial key are constructed based on a QUIC protocol, header protection is removed from a client Initial data packet, and a ciphertext load is decrypted; in the QUIC protocol flow applying a subpackaging mechanism, a load part of an Initial data packet is composed of out-of-order frames, for the out-of-order frames, a Length field and an Offset field of each frame are extracted, finally, a TLS record in a QUIC flow is screened out, and SNI field information contained in a ClientHello fragment is extracted. According to the scheme, application identification of the QUIC flow can be realized, and the vacancy of network management capability of the QUIC flow is filled.

Description

Technical Field

[0001] The present invention relates to a QUIC protocol traffic SNI field extraction method for a subpacketization mechanism, and belongs to the technical field of computer network security. Background Art

[0002] QUIC (Quick UDP Internet Connections) is a new network transmission protocol based on UDP (User Datagram Protocol). In 2012, Google launched QUIC, aiming to meet the internet's demand for high bandwidth, low latency, and strong security. In 2018, the new HTTP standard, HTTP / 3, implemented QUIC on top of UDP. The IETF standardized QUIC as RFC 9000 in 2021 and released the official standard for QUICVersion 2 as 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, combining the advantages of both the UDP protocol and the TCP (Transmission Control Protocol). Compared to traditional transport layer protocols, the QUIC protocol offers enhanced security, privacy, and flexibility. Due to these features, well-known companies such as Google, Facebook, Amazon, Apple, Bilibili, and Netflix have already deployed QUIC-based network services, and a growing number of businesses and organizations are also experimenting with providing QUIC-based network services. According to the latest statistics from September 2024, approximately 8.1% of websites are using the QUIC protocol.

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

[0005] In the TLS protocol encrypted transmission scenario, 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 have a common encryption key, so the SNI field information is transmitted in plain text. The existing patent for extracting SNI field information for the TLS protocol captures the ClientHello data packet sent by the client in the early stage of communication, parses the byte stream, and extracts the extension item with ExtensionType of server_name to extract the SNI field information. The HTTP protocol standards HTTP / 1.1 and HTTP / 2 both implement encrypted transmission based on the TLS protocol. Therefore, the method for extracting SNI field information for the TLS protocol can also be applied to network service traffic based on HTTP / 1.1 and HTTP / 2.

[0006] In the QUIC protocol's encrypted transmission scenario, the metadata in the encrypted packet header and payload leaves virtually no plaintext information during network transmission. Plaintext TLS data before the key negotiation phase may still leak some user privacy. However, the QUIC protocol uses certain special fields in the Initial packet during the handshake phase to derive header protection keys and initial keys for encrypted transmission of the Initial packet. Therefore, QUIC traffic data is transmitted over the network almost entirely as ciphertext data. However, a patent exists for extracting SNI field information from the QUIC protocol. Based on the QUIC protocol and analysis of QUIC traffic data, a key is calculated to decrypt the ciphertext portion and extract the SNI field information. The HTTP protocol standard, HTTP / 3, implements encrypted transmission based on the QUIC protocol. Therefore, the method for extracting SNI field information for the QUIC protocol can be applied to network service traffic based on HTTP / 3.

[0007] However, as the QUIC protocol has been improved, the existing methods for extracting SNI field information for the QUIC protocol have gradually become unsuitable for some scenarios using the QUIC protocol for transmission. The QUIC protocol has been continuously improved since its standardization in 2021. In early QUIC protocol traffic data, the packetization mechanism designed in RFC 9000 was not used, so a QUIC data packet only contained an independent, complete frame. However, in order to minimize the bandwidth and computing resources consumed by each data packet, before sending an underutilized data packet, the sender can encapsulate multiple frames in a data packet to avoid sending a large number of small data packets, which is the packetization mechanism of the QUIC protocol. In the QUIC protocol that applies the packetization mechanism, TLS records may be encapsulated in multiple encrypted frames, and the order of the frames in the Initial data packet is scrambled. Therefore, the existing patents for extracting SNI field information for the QUIC protocol cannot extract SNI field information from QUIC protocol traffic that applies the packetization mechanism. In addition, with the widespread application of the QUIC protocol, the proportion of QUIC protocol traffic in the Internet continues to increase, and existing patents for analyzing QUIC traffic are difficult to handle massive Internet traffic.

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

[0009] In order to extract SNI field information from QUIC protocol traffic that uses a packetization mechanism, the present invention proposes a QUIC protocol traffic SNI field extraction method for a packetization mechanism. This method extracts SNI field information from a captured QUIC stream in Internet traffic by analyzing the QUIC protocol and the packetization mechanism. The analysis method in the present invention is divided into four stages: capturing the initial packet of the QUIC stream, decrypting the ciphertext payload data, restoring the complete TLS record, and extracting the SNI field information. First, the captured Internet traffic is subjected to a five-tuple grouping, and the initial packet sent by the client is extracted based on the special field flag of the QUIC protocol; secondly, the 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 ciphertext payload is decrypted in turn; next, for the out-of-order frames in the QUIC protocol data packet, the Length field and Offset field of each frame are extracted, and the out-of-order frames are reordered to restore the complete plaintext payload; finally, the TLS record in the QUIC stream is screened out, and the SNI field information contained in the ClientHello segment is extracted. The present invention can be used to parse the QUIC protocol traffic that applies the subpacketization mechanism, providing a basis for in-depth analysis of QUIC traffic.

[0010] To achieve the purpose of the present invention, the technical solution of the present invention is as follows: a method for extracting the SNI field of QUIC protocol traffic for a subpacketization mechanism, the method comprising the following steps:

[0011] Step (1) captures the traffic transmitted on the Internet and filters out non-QUIC traffic. Using the Farm hash function and a custom Bloom Filter structure, the captured traffic is grouped into five tuples to obtain pure QUIC flow data.

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

[0013] Step (3) constructs a QUIC packet structure to parse the extracted Initial data packet, constructs the data packet header protection key and the client initial key, removes the header protection and decrypts the ciphertext payload to obtain the plaintext payload;

[0014] Step (4) reads the field information and determines the frame boundary based on the plaintext payload obtained in step (3) according to the packetization mechanism of the QUIC protocol, and divides the plaintext payload into different frames;

[0015] Step (5) calculates the actual position of each frame in the original payload by reading the packet header information and the information of each frame, and restores the position of the disordered frames to obtain the original payload;

[0016] Step (6) filters the TLS record based on the original payload obtained in step (5). If the first Initial data packet does not contain a TLS record, the process from step (3) to step (5) is executed on subsequent Initial data packets in the QUIC stream in sequence, and the ClientHello segment is retrieved for the TLS record to 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 screening 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 does, determine it as a QUIC packet and retain it;

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

[0021] Furthermore, in step (2), the SNI field information is included in the ClientHello segment 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 several packets of the QUIC stream and verify whether the packet header type field and the long packet type field of the packet are the target field.

[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 ID, data packet length, data packet sequence number, ciphertext payload, and AEAD identifier;

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

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

[0026] (3.4) After determining the boundary between the header and the ciphertext payload in step (3.3), select the corresponding cryptographic algorithm based on 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 steps of dividing the plaintext payload into different frames are as follows:

[0028] (4.1) Read the frame type flag of the first byte of the plaintext payload, distinguish CRYPTO / ACK / PADDING frame types 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, 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, the byte sequence of the corresponding length is cut into independent frame entities according to the starting position and length field value of the current frame;

[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 back 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 using the packetization mechanism, the TLS record sent by the client may be encapsulated in multiple encrypted frames in a disordered order, and padding frames are inserted between the frames. Therefore, after decryption, the disordered frames need to be restored. To restore the order of the frames, the length of the frame and the offset relative to the first byte must be calculated. In step (4), after reading the length field of each frame, the offset field of the frame needs to be read.

[0034] (5.2) The offset field determines the relative position of the initial packet in the frame. The absolute position of each frame can be calculated by combining it with the length field.

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

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

[0037] (6.1) Based on the original payload restored in step (5), identify the TLS record fragments through the TLS protocol special identification field, extract the length information of the TLS record, and merge the fragments to obtain the complete TLS record;

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

[0039] (6.3) If the handshake type of the TLS record is ClientHello, move the current pointer backward 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, find the extension item with ExtensionType of server_name (field value 0x00), parse the length field value in the NameList structure, determine the starting and ending 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. When the processor executes the program, the method for extracting the SNI field of QUIC protocol traffic for a packetization mechanism is implemented.

[0042] A computer-readable storage medium stores computer instructions, which, when executed by a processor, implement the QUIC protocol traffic SNI field extraction method for a subpacketization mechanism.

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

[0044] (1) The present invention proposes a method for extracting the SNI field of QUIC protocol traffic based on a packetization mechanism. By analyzing the QUIC protocol traffic data and standard files that apply the packetization mechanism, the QUIC stream is captured from the Internet traffic and the SNI field information therein is extracted.

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

[0046] (3) The QUIC traffic analysis method for the subpacketization mechanism proposed in the present invention realizes application identification of QUIC traffic by real-time processing of subpacketized QUIC traffic and extracting SNI field information, thus filling the gap in network management capabilities for QUIC traffic. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0049] Figure 3 This is the method for extracting SNI field information. DETAILED DESCRIPTION

[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 used to limit the scope of the present invention.

[0051] Specific embodiment: The present invention provides a method for extracting the SNI field of QUIC protocol traffic for a subpacketization mechanism. The overall framework is as follows: Figure 1 As shown, it specifically includes the following steps:

[0052] Step (1) captures the traffic transmitted on the Internet and filters out non-QUIC traffic. Using the Farm hash function and a custom Bloom Filter structure, the captured traffic is grouped into five tuples to obtain pure QUIC flow 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, use the Tcpdump tool, specify the network interface through "-i", and perform preliminary screening based on UDP protocol type and destination port. The destination port includes the default HTTPS port 443 and some custom ports. Filter TCP protocol type and other non-QUIC protocol traffic, retaining potential QUIC packets;

[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 rest are fixed bits. Therefore, the first 4 bits of the first byte of the transport layer payload can be detected to be 0xc. If the QUIC protocol identifier is included, that is, the first 4 bits of the first byte of the transport layer payload are 0xc, it is determined to be a QUIC data packet and retained.

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

[0057] Step (2) traverse each QUIC stream according to the special field flags specified in the QUIC protocol standardization document RFC 9000, extract the Initial data packets sent by the client, and the number of Initial data packets sent by the client in each QUIC stream in the QUIC stream applying the subpacketization mechanism is 1-3;

[0058] In one embodiment of the present invention, the SNI field information is included in the ClientHello segment of a TLS record, which is then encapsulated in one of the 1-3 Initial packets sent by the client. In a QUIC stream, the first packet is typically sent by the client. Since the number of Initial packets sent by the client in a QUIC stream using a packetization mechanism is 1-3, detecting the first five packets of the QUIC stream ensures that the Initial packets sent by the client are not missed. This is achieved by verifying that the packet header type field and the long packet type field are the target field.

[0059] Step (3) constructs a QUIC packet structure for the extracted Initial data packet, parses the data packet byte stream, constructs the data packet header protection key and the client initial key based on the QUIC protocol, removes the header protection and decrypts the ciphertext payload to obtain the plaintext payload; Figure 2 Demonstrates the process of decrypting and obtaining the plaintext payload;

[0060] In one embodiment of the present invention, the steps for obtaining a 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 the version number, connection identifier ID, data packet length, data packet sequence number, ciphertext payload, and AEAD identifier; Table 1 lists the QUIC data packet header field information in the embodiment;

[0062] Table 1: QUIC packet header field information

[0063] (3.2) Different versions of the QUIC protocol generate different construction materials for the header protection key and the initial key. 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 the original key material destination connection ID of 0xf69441a23fb04232. 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. The header protection calculates a mask of a specific length and encrypts the lower 4 bits of the first byte and the packet sequence number field based on stream cipher encryption, thereby hiding the boundary between the packet header and the payload. The cipher algorithm for generating the mask corresponding to version number 0x00000001 is the 128-bit ECB mode AES cipher algorithm. The header protection key is used to decrypt the lower 4 bits of the first byte and the packet sequence number field according to the stream cipher decryption method;

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

[0066] Step (4) reads the field information and determines the boundaries of different frames based on the plaintext payload obtained in step (3) according to the packetization mechanism of the QUIC protocol, and divides the plaintext payload into different frames;

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

[0068] (4.1) Read the frame type flag 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 a CRYPTO frame. Table 2 lists the field information of the CRYPTO frame in this embodiment;

[0069] Field Name value 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 frame

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

[0072] (4.2) Read the length field of the frame, which is 0x03 here, and determine the start and end positions of the frame. The start position is the first byte of the payload, and the end position is the length of the Frame Type field, Offset field, and Length field plus the Length field value, a total of 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 byte sequence of the corresponding length is cut according to the starting position and length field value of the current frame as an independent frame entity. Here, the byte stream from bytes 1 to 7 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 back 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 22 out-of-order frames in total.

[0075] Step (5) calculates the actual position of each frame in the original payload by reading the packet header information and the information of each frame, and restores the position of the disordered frames to obtain the original payload;

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

[0077] (5.1) In the QUIC protocol traffic using the packetization 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, the out-of-order frames need to be restored. To restore the order of the frames, the length of the frame and the offset relative to the first byte need to be calculated. In step (4), the length field of each frame is read, and the offset field of the frame needs to be read. 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 relative position of the Initial packet in the frame to the header. Combined with the Length field, the absolute position of each frame can be calculated. In this embodiment, the actual position of the first out-of-order frame should be between bytes 1436 and 1438 in the payload.

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

[0080] Step (6) filters the TLS record based on the original payload obtained in step (5). If the first Initial data packet does not contain a TLS record, the process from step (3) to step (5) is executed on subsequent Initial data packets in the QUIC stream in sequence, and the ClientHello segment is retrieved for the TLS record to extract the SNI field information contained therein. Figure 3 Shows the acquisition

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

[0082] (6.1) Based on the original payload restored in step (5), identify the TLS record fragments using the TLS protocol special identification field, extract the TLS record length information, which is 1721 (0x0006b9) in this embodiment, and merge the fragments to obtain the complete TLS record;

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

[0084] (6.3) If the handshake type of the TLS record is ClientHello, move the current pointer backward 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 field is 5 bytes after the CipherSuites part;

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

[0086] Table 3: SNI field information

[0087] Field Name value 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, and equivalent changes or substitutions made on the basis of the above technical solutions fall within the scope of protection of the claims of the present invention.

Claims

1. A method for extracting the SNI field of QUIC protocol traffic based on a subpacketization mechanism, characterized in that: The method comprises the following steps: Step (1) captures traffic transmitted on the Internet, filters out non-QUIC traffic, uses the Farm hash function and a custom Bloom Filter data structure, groups the captured traffic according to the five-tuple (source IP address, destination IP address, source port, destination port, transport layer protocol), and obtains pure QUIC flow data; Step (2) extracting the Initial data packet sent by the client for each QUIC stream according to the special field flag of the QUIC protocol, and the number of Initial data packets sent by the client in the QUIC stream applying the subpacketization mechanism is 1-3; Step (3) constructs a QUIC packet structure parsing packet for the Initial data packet extracted in step (2), constructs the client Initial data packet header protection key and the client initial key based on the QUIC protocol, removes the header protection and performs a decryption operation on the ciphertext payload to obtain the plaintext payload; Step (4) reads the special field information based on the plaintext payload obtained in step (3), determines the frame boundary, and divides the plaintext payload into different frames according to the packetization mechanism of the QUIC protocol; Step (5) determines the actual position of each frame in the original payload by reading the packet header information and the information of each frame, and reorders the out-of-order frames to obtain the original payload; Step (6) extracts the TLS record based on the original payload obtained in step (5). If the first Initial data packet does not contain a TLS record, the process from step (3) to step (5) is executed on subsequent Initial data packets in the QUIC stream in sequence, and the ClientHello segment is retrieved for the TLS record to extract the SNI field information contained therein.

2. A method for extracting the SNI field of QUIC protocol traffic based on a subpacketization mechanism according to claim 1, characterized in that: The step (1) specifically includes the following sub-steps: (1.1) Capture all raw traffic passing through the preset network interface, perform preliminary screening 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; (1.2) Based on the preliminary screening results of (1.1), the transport layer payload header field containing the QUIC protocol identifier is used as the matching rule to confirm and retain pure QUIC packets; (1.3) For all confirmed QUIC data packets, extract the five-tuple (source IP address, destination IP address, source port, destination port, transport layer protocol), use the Farm hash function to generate a stream unique identifier, merge the data packets with the same stream unique identifier, and finally output the complete QUIC stream data.

3. The method for extracting the SNI field of QUIC protocol traffic based on a subpacketization mechanism according to claim 1, wherein: In step (2), the SNI field information is included 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. The Initial data packet in the QUIC protocol 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 several data packets sent by the client in the QUIC stream and verify whether the header type field and the long data packet type field of the data packet are the target field.

4. The method for extracting the SNI field of QUIC protocol traffic based on a subpacketization mechanism according to claim 1, wherein: The 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 ID, data packet length, data packet sequence number, ciphertext payload, and AEAD identifier; (3.2) Different versions of the QUIC protocol data packets use different construction materials and algorithms to generate header protection keys and initial keys. The version number extracted in step (3.1) is used to determine the relevant functions, algorithms, and materials for key generation, and to construct the header protection key and client initial key. (3.3) The QUIC protocol protects QUIC layer data by including header protection and payload encryption. Header protection hides the boundary between the packet header and payload. The header protection key is used to decrypt the lower 4 bits of the first byte and the packet sequence number field. (3.4) After determining the boundary between the header and the ciphertext payload in step (3.3), determine the cryptographic algorithm based on 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 based on a subpacketization mechanism according to claim 1, wherein: The step (4) specifically includes the following sub-steps: (4.1) Read the frame type flag (first byte) of the plaintext payload, distinguish CRYPTO / ACK / PADDING frame types according to the frame type mapping table (0x00-0x1F) defined by the QUIC protocol, and determine the frame parsing mode; (4.2) Read the length field of the frame, 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, the byte sequence of the corresponding length is cut according to the starting position and length field value of the current frame as an independent frame entity; (4.4) If the end position of the current frame is not the end position of the data packet, determine the starting position of the next frame to be the end position of the current frame shifted 1 byte later, 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 based on a subpacketization mechanism according to claim 1, wherein: In the step (5), (5.1) In the QUIC protocol traffic using the packetization 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 scrambled, and padding frames are inserted between the frames. Therefore, after decryption, the out-of-order frames need to be restored. To restore the order of the frames, the length and relative offset of the frames need to be calculated. In step (4), the length field of each frame is read, and the offset field of the frame needs to be read. (5.2) The Offset field determines the relative position of the Initial packet in the frame and is used in conjunction with the Length field to calculate the absolute position of each frame. (5.3) Traverse all non-filled frames, sort each frame by the offset field value, and output the restored original payload.

7. The method for extracting the SNI field of QUIC protocol traffic based on a subpacketization mechanism according to claim 1, wherein: The step (6) specifically includes the following sub-steps: (6.1) Based on the original payload restored in step (5), identify the TLS record fragments through the TLS protocol special identification field, extract the length information of the TLS record, and merge the fragments to obtain the complete TLS record; (6.2) The SNI field is included in the extension of the TLS record whose type is Handshake and whose Handshake Type is ClientHello (field value is 0x01). Extract the Handshake Type field of the TLS record and verify whether it is 0x01, that is, ClientHello type; (6.3) If the handshake type of the TLS record is ClientHello, move the current pointer back to skip the TLS length field (3 bytes) and the Handshake length field (3 bytes) 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 of server_name (field value 0x00), parse the length field value in the NameList structure, determine the starting and ending 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, wherein: When the processor executes the program, it implements a QUIC protocol traffic SNI field extraction method for a packetization mechanism as described in any one of claims 1 to 7 above.

9. A computer-readable storage medium having computer instructions stored thereon, characterized in that: When the computer instruction is executed by the processor, it implements a QUIC protocol traffic SNI field extraction method for a subpacketization mechanism as described in any one of claims 1-7.

Images