Message filtering method and device, equipment, storage medium and program product

Abstract

The invention discloses a message filtering method and device, equipment, a storage medium and a product, a protocol to which a message belongs is identified, and a handshake stage of the message is analyzed only when the message belongs to a user datagram protocol UDP-based fast UDP Internet connection QUIC protocol, so that accurate identification and processing of HTTP / 3 traffic are realized, and the message filtering efficiency is improved. And the problem that HTTP / 3 traffic is difficult to intercept due to message structure difference is solved. Moreover, according to the message filtering method, the encrypted protocol control information is decrypted, and the encryption barrier of the QUIC protocol can be broken through, so that the feature information for identifying the communication target can be extracted from the decrypted protocol control information, the feature which is originally encrypted and hidden is converted into an effective interception voucher, and the security of the communication target is improved. The problem that the features cannot be extracted due to encryption is solved. And finally, the message is filtered based on the extracted feature information, such a filtering strategy based on an accurate identifier realizes accurate identification of the traffic selected to be intercepted by the user, and the error interception rate can be reduced.

Description

Technical Field

[0001] This application relates to the field of computer network technology, specifically to a message filtering method, message filtering device, electronic device, computer-readable storage medium, and computer program product. Background Technology

[0002] Currently, Uniform Resource Locator (URL) filtering and content filtering primarily rely on Domain Name System (DNS) messages and Hypertext Transfer Protocol (HTTP) / Hypertext Transfer Protocol Secure (HTTPS) message field parsing. HTTP / 3, which transmits messages using the Quick UDP Internet Connection (QUIC) protocol, differs from HTTP / 2, which transmits messages using the Transmission Control Protocol (TCP) protocol. Furthermore, some platforms lack more comprehensive deployments and standardized workflows for HTTP / 3, making it impossible to process or intercept HTTP / 3 traffic. Moreover, because the QUIC protocol enforces the use of Transport Layer Security (TLS) 1.3 for handshakes, key negotiation, and authentication, most data and control information in the QUIC protocol is encrypted, making it impossible to extract valid features such as the Server Name Indication (SNI) as credentials for interception.

[0003] To address this issue, HTTP / 3 traffic is typically blocked by intercepting common HTTP / 3 ports, dropping messages containing encrypted fields (to prevent encryption), and forcing users to refuse to use HTTP / 3. This results in a large number of false positives and low accuracy in filtering the traffic that users choose to block. Summary of the Invention

[0004] Based on the above technical problems, embodiments of this application provide a message filtering method, message filtering device, electronic device, computer-readable storage medium, and computer program product, which performs progressive processing on the QUIC protocol fields. By identifying, decrypting, and parsing the QUIC handshake message, it extracts feature information such as the SNI field in the TLS handshake record within the UDP payload, and uses this feature information as a policy basis to achieve filtering of the QUIC handshake message.

[0005] In a first aspect, this application provides a message filtering method, which includes receiving a message and identifying the protocol to which the message belongs; if the message belongs to the Quick UDP Internet Connection (QUIC) protocol based on User Datagram Protocol (UDP), parsing the handshake phase of the message to obtain encrypted protocol control information; decrypting the encrypted protocol control information; extracting feature information for identifying the communication target from the decrypted protocol control information; and filtering the message based on the extracted feature information.

[0006] In some implementations, identifying the protocol to which the message belongs includes determining whether the transport layer protocol of the message is in UDP format, whether the UDP payload is complete, and whether it belongs to an established connection tracking protocol; if the transport layer protocol of the message is in UDP format, the UDP payload is complete, and it belongs to an established connection tracking protocol, then the UDP payload in the message is extracted; and based on the characteristics in the UDP payload, it is determined whether the UDP payload belongs to the QUIC protocol.

[0007] In some implementations, parsing the handshake phase of the message to obtain encrypted protocol control information includes determining whether the message is an initial message sent during the connection handshake phase; and if the message is an initial message sent during the connection handshake phase, then disassembling the initial message according to the specifications of the QUIC protocol to obtain the encrypted protocol control information.

[0008] In some implementations, the encrypted protocol control information includes protected header information and protected payload information; the decryption of the encrypted protocol control information includes initializing a first decryptor for decrypting the header information and a second decryptor for decrypting the protected payload information; using the first decryptor to decrypt the header information to restore the unencrypted header information; and using the unencrypted header information, using the second decryptor to decrypt the protected payload information to restore the unencrypted payload information.

[0009] In some implementations, extracting feature information for identifying the communication target from the decrypted protocol control information includes traversing all data frames in the decrypted protocol control information, filtering and reassembling data frames carrying TLS handshake data to obtain reassembled data; and obtaining the Server Name Indicator (SNI) from the reassembled data as the feature information.

[0010] In some implementations, the message filtering method further includes temporarily storing the filtered data frames if the feature information has not been extracted and the data frame carrying TLS handshake data is fragmented, and then reassembling them when subsequent data carrying TLS handshake data arrives; and allowing the message to pass.

[0011] In some implementations, filtering the packets based on the extracted feature information includes matching the feature information with a preset filtering policy library; and allowing or blocking the packets according to the matching result.

[0012] Secondly, this application also provides a message filtering device, which includes an identification module, a parsing module, a decryption module, an extraction module, and a filtering module. The identification module is used to receive messages and identify the protocol to which the message belongs; the parsing module is used to parse the handshake phase of the message to obtain encrypted protocol control information if the message belongs to the Fast UDP Internet Connection (QUIC) protocol based on User Datagram Protocol (UDP); the decryption module is used to decrypt the encrypted protocol control information; the extraction module is used to extract feature information for identifying communication targets from the decrypted protocol control information; and the filtering module is used to filter the message based on the extracted feature information.

[0013] Thirdly, this application also provides an electronic device, which includes the above-described message filtering device; or, the electronic device includes a processor and a memory, wherein the memory stores a computer program, and the processor executes the message filtering device as described in any of the above embodiments by calling the computer program stored in the memory.

[0014] Fourthly, embodiments of this application also provide a computer-readable storage medium storing a computer program adapted for loading by a processor to execute the message filtering method as described in any of the above embodiments.

[0015] Fifthly, embodiments of this application also provide a computer program product, including computer instructions, which, when executed by a processor, implement the message filtering method as described in any of the above embodiments.

[0016] The message filtering method, device, electronic equipment, computer-readable storage medium, and computer program product provided in this application identify the protocol to which the message belongs and only parse the handshake phase of the message when the message belongs to the UDP-based QUIC protocol. This achieves accurate identification and processing of HTTP / 3 traffic, overcoming the problem of difficulty in intercepting HTTP / 3 traffic due to differences in message structure. Furthermore, the message filtering method of this application decrypts encrypted protocol control information, breaking through the encryption barrier of the QUIC protocol. This allows for the extraction of feature information (such as SNI) used to identify the communication target from the decrypted protocol control information, transforming the originally encrypted and hidden features into valid interception credentials, solving the problem of feature extraction failure due to encryption. Finally, it abandons traditional methods such as port-based blocking or protocol rejection, and instead uses message filtering based on extracted feature information. This filtering strategy based on precise identifiers (such as domain names) achieves accurate identification of user-selected traffic, reducing the false interception rate. Attached Figure Description

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

[0018] Figure 1 This is a first flowchart illustrating a message filtering method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a message filtering device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the second process of a message filtering method provided in an embodiment of this application; Figure 4 A schematic diagram of the third process of a message filtering method provided in an embodiment of this application; Figure 5 A schematic diagram of the fourth process of a message filtering method provided in an embodiment of this application; Figure 6 A schematic diagram of the fifth process of a message filtering method provided in an embodiment of this application; Figure 7 A schematic diagram of the sixth process of a message filtering method provided in an embodiment of this application; Figure 8 A seventh flowchart illustrating a message filtering method provided in an embodiment of this application; Figure 9 A schematic diagram summarizing a message filtering method provided in an embodiment of this application; Figure 10 A schematic diagram of state transitions for a message filtering method provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0019] Explanation of key component symbols: Message filtering device 10; Identification module 11; Parsing module 12; Decryption module 13; Extraction module 14; Filtering module 15; 20 electronic devices; Processor 21; Memory 22; Computer program 23. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] Firewalls and other network security systems implement security policies to filter out traffic that users choose to block, in order to defend against various threats, including hackers, malware, and other forms of cyberattacks. By verifying and filtering Uniform Resource Locators (URLs) and related information, network traffic can be intercepted and controlled.

[0022] This application can be applied to scenarios where users request access to web pages using a browser. The user first enters the website's domain name in the browser, obtains the IP address of the target server via the DNS protocol, and then, after establishing a connection based on the IP address, the browser sends a request message to the target server via an application-layer transport protocol (such as HTTP) to request access to the specified resource. This initiates the process of attempting to connect, handshake, and encrypt with the target server. Upon receiving the request, the target server performs corresponding operations based on the request content, such as accessing a database or calling a script, and then generates a response. This response is packaged into a message and sent to the browser for display. After receiving the data, the browser renders the page based on HTML (Hypertext Markup Language), CSS (Cascading Style Sheets), JavaScript, and other content. For different types or versions of application layer transport protocols, the result of the request access may be affected by the algorithm of the URL filtering process. For example, compared with the traditional TCP protocol, the QUIC protocol integrates TLS 1.3 encryption, which provides higher security, reduces the complexity of the handshake phase, and can reduce latency. However, it also brings challenges to the traffic filtering of intermediate devices (such as firewalls). Some network administrators lack the deployment of QUIC protocol message processing when deploying firewalls or security gateways, or they circumvent the processing of HTTP / 3 traffic by intercepting HTTP / 3 traffic based on the QUIC protocol at the port. Therefore, this application proposes a message filtering method that specifically processes the QUIC protocol field of HTTP / 3 traffic to effectively filter HTTP / 3 traffic.

[0023] The QUIC protocol is based on UDP transmission, using UDP port 443 (primarily for HTTPS, HTTP / 3 runs on this port by default) or TCP port 80 (primarily for HTTP; when first using the target server, it may first make a brief connection through port 80 to discover HTTP / 3 support, and then switch to the UDP port).

[0024] The basic communication data unit of a QUIC message is a packet, which is classified into two types based on the length of its header. Long headers include Version Negotiation packets, Initial packets (used to initiate a connection and transmit initial encrypted handshake data), Handshake packets (used to transmit encrypted data in non-initial stages of the handshake), 0-RTT packets (used to transmit early application data in a 0-RTT handshake), and Retry packets (used to verify the validity of the client address). Short headers include 1-RTT packets, which are used to transmit application data after a successful handshake and have minimal overhead.

[0025] The data packet consists of two parts: Header and Data. The Header includes four fields: Flags, Connection ID, QUIC Version, and Packet Number. Flags use different bits to identify attributes such as message type, header format, and cipher phase, guiding subsequent field parsing. The Connection ID uniquely identifies the QUIC connection. The QUIC Version identifies the QUIC protocol version number, used to negotiate protocol compatibility between communicating parties. The Packet Number is a unique sequence number within the QUIC message connection, indicating the transmission order. Different types of QUIC data packets belong to different packet number spaces; retransmissions are assigned new packet numbers to ensure ordered message transmission. Data is encrypted and consists of Frames, which can contain one or more data frames. Each data frame is divided into type and payload, with the payload being application data. There are many types of data frames, including Stream, ACK, PADDING, PING, and CRYPTO. The handshake process primarily uses CRYPTO frames. The packet number is divided into three spaces: the Initial space for all Initial packets, the Handshake space for all Handshake packets, and the Application data space for all 0-RTT and 1-RTT packets. CRYPTO frames can be sent within these spaces.

[0026] In the QUIC protocol's TLS handshake process, the client first sends an Initial packet containing a ClientHello field message initiating an encryption request. The TLS handshake begins with the ClientHello, which includes information such as the TLS version supported by the client. Upon receiving the Initial packet, the server verifies the client's connection information and generates an initial key. The server responds with a ServerHello message, sending its TLS certificate and certificate chain. This TLS certificate contains the server's public key, which the client can use to verify the server's identity. Upon receiving the certificate, the client verifies its validity. If the certificate verification is successful, the client confirms that the server it is communicating with is trustworthy. The QUIC protocol uses the TLS 1.3 handshake protocol, negotiating a session key based on a key exchange algorithm. QUIC binds this key exchange process to its own transport authentication information, ensuring that the cryptographic handshake is completed in one round trip (1-RTT) or zero round trips (0-RTT).

[0027] The TLS certificate itself does not participate in the QUIC protocol discovery process; instead, it is used for connection establishment and encryption. Protocol discovery relies on the Alternate Service (Alternative Service) field in the HTTP response header, informing the client that the server supports QUIC. The TLS certificate, however, is used after the client decides to initiate a QUIC connection to verify the server's identity and negotiate encryption keys during the QUIC handshake. These can be understood as two independent but complementary steps: first, the QUIC connection is discovered via Alt-SVC, and then a secure channel is established within the QUIC connection using the TLS certificate.

[0028] Against the above background, this application provides a message filtering method, which is described in detail below.

[0029] Please see Figure 1 and Figure 2 This application provides a message filtering method and a message filtering device 10. The message filtering method includes: 01: Receive messages and identify the protocol to which the message belongs; 03: If the message belongs to the UDP-based QUIC protocol, then parse the handshake phase of the message to obtain encrypted protocol control information; 05: Decrypt the encrypted protocol control information; 07: Extract the feature information used to identify the communication target from the decrypted protocol control information; 09: Filter the messages based on the extracted feature information.

[0030] The above-described message filtering method can be applied to the message filtering device 10. The message filtering device 10 of this application includes an identification module 11, a parsing module 12, a decryption module 13, an extraction module 14, and a filtering module 15. The identification module 11 is used to receive messages and identify the protocol to which the message belongs; the parsing module 12 is used to parse the handshake phase of the message if it belongs to the UDP-based QUIC protocol to obtain encrypted protocol control information; the decryption module 13 is used to decrypt the encrypted protocol control information; the extraction module 14 is used to extract feature information for identifying the communication target from the decrypted protocol control information; and the filtering module 15 is used to filter messages based on the extracted feature information.

[0031] In step 01, a message is a data unit for network exchange and transmission, containing header and payload information. It is an application layer concept and is a data packet during transmission. By monitoring the target port, it is possible to distinguish between UDP and TCP protocol transmissions on that port, for example, through the distinctive symbols of the TCP three-way handshake or UDP data packets. If it is a TCP message, it is handed over to the TCP protocol stack for processing. Since the QUIC protocol is based on the UDP protocol, the UDP message at the target port is further processed.

[0032] In step 03, the protocol control information is data used in the QUIC protocol handshake phase to manage and control the communication process, negotiate and establish a secure connection, rather than application data to be transmitted. The encrypted protocol control information is used to ensure the correct establishment, maintenance and security of the connection.

[0033] It is understandable that in step 05, since the target information (such as SNI) of the application layer has been encrypted in the QUIC protocol message, it is not possible to achieve accurate filtering based solely on the information at the port. The filtering here can be understood as intercepting messages using protocols other than QUIC and illegal QUIC protocol messages, and no longer performing parsing, display, access, or interaction.

[0034] Specifically, in step 07, the decrypted protocol control information is in plaintext. The plaintext of the protocol control information can be used to identify and extract the feature information used to identify the communication target. The communication target can be a website that needs to be accessed, and the feature information can be the IP address, port number, target domain name, and TLS certificate of the website's server (used to verify whether the server's identity is secure, which can be a hash value or a sequence number).

[0035] Specifically, in step 09, based on the extracted feature information, it can be determined whether the application corresponding to these feature information is legitimate or whether there is a corresponding processing strategy, and then the message can be filtered to intercept or discard illegal messages.

[0036] The message filtering method provided in this application identifies the protocol to which a message belongs and only parses the handshake phase of the message when the message belongs to the UDP-based QUIC protocol. This achieves accurate identification and processing of HTTP / 3 traffic, overcoming the problem of difficulty in intercepting HTTP / 3 traffic due to differences in message structure. Furthermore, the message filtering method of this application decrypts encrypted protocol control information, breaking through the encryption barrier of the QUIC protocol. This allows for the extraction of feature information used to identify the communication target from the decrypted protocol control information, transforming the originally encrypted and hidden features into valid interception credentials, solving the problem of feature extraction failure caused by encryption. Finally, filtering messages based on the extracted feature information, this filtering strategy based on precise identifiers, achieves accurate identification of the traffic selected for interception by the user, reducing the false interception rate.

[0037] Please see Figure 2 and Figure 3 In some implementations, 01: Identifying the protocol to which the message belongs, including: 011: Determine whether the transport layer protocol of the message is UDP format, whether the UDP payload is complete, and whether it belongs to an established connection tracking protocol; 013: If the transport layer protocol of the message is UDP format, the UDP payload is complete, and it belongs to an established connection tracking protocol, then extract the UDP payload from the message; and 015: Determine whether the UDP payload belongs to the QUIC protocol based on the characteristics of the UDP payload.

[0038] The above-described message filtering method can be applied to the message filtering device 10. The identification module 11 in this embodiment is used to determine whether the transport layer protocol of the message is UDP format, whether the UDP payload is complete, and whether it belongs to an established connection tracking protocol. If the transport layer protocol of the message is UDP format, the UDP payload is complete, and it belongs to an established connection tracking protocol, then the UDP payload in the message is extracted. And based on the characteristics in the UDP payload, it is determined whether the UDP payload belongs to the QUIC protocol.

[0039] For step 011, the UDP payload is the raw data remaining after removing the UDP header. Specifically, the UDP format can be determined by checking the protocol field of the IP header to determine if it belongs to the UDP packet based on the QUIC protocol. To ensure the normal operation of subsequent processes, the integrity of the UDP payload needs to be guaranteed. This can be verified by checking whether the length declared in the UDP header matches the actual length of the UDP packet. It is understood that the goal of the QUIC protocol is to provide reliable, ordered, and efficient transmission; therefore, a connection tracking protocol is needed to maintain continuous and stable communication. The sender and receiver establish connection tracking during their first communication, maintaining a state database for the current connection, including connection creation time, number of packets sent, number of bytes sent, etc., to collect and record packet information. In the embodiments of this application, previously established connections are locked, and feature information such as SNI and certificate hashes previously parsed for that connection can be queried to match whether the feature information extracted from the current packet needs filtering. If no connection has been established, it can also be added to the state database or the policy database updated in a timely manner.

[0040] Regarding step 013, it can be understood that, according to the QUIC protocol, during the handshake phase, the characteristic information identifying the communication target is located in the UDP payload, so the UDP payload should be extracted for subsequent processing.

[0041] For step 015, the features in the UDP payload can be the magic number, connection ID, and / or flags. The magic number, connection ID, and flags are all located in the QUIC protocol header. The magic number is a flag used to identify traffic as QUIC, the connection ID is used to identify a QUIC connection, and the flags are used to identify header data fields that represent message attributes.

[0042] In this embodiment, identifying the protocol of a message primarily involves identifying HTTP / 3 traffic on the port, i.e., identifying QUIC protocol messages for subsequent processing. The QUIC protocol transmits data packets based on the UDP transport protocol; therefore, it must first be determined whether the message belongs to the UDP format. The port can be a specific UDP port, such as port 443. Since other protocols may share the same port with HTTP / 3 protocol traffic, it is necessary to distinguish between TCP-based traffic and UDP-based HTTP / 3 traffic. Specifically, the length of the UDP format data can be used to determine if it meets the requirements of a complete UDP payload. If it is determined that the message contains a complete UDP payload and the server has established a QUIC protocol connection and can process QUIC protocol messages, the UDP payload in the message is further verified to belong to the QUIC protocol based on the header information and data information of the QUIC protocol data packet that identify the QUIC protocol itself.

[0043] Please see Figure 2 and Figure 4 In some implementations, 03: Parsing the handshake phase of the message to obtain encrypted protocol control information, including: 031: Determine if the message is the initial message sent during the connection handshake phase; and 033: If the message is the initial message sent during the connection handshake phase, the initial message is deconstructed according to the QUIC protocol specifications to obtain encrypted protocol control information.

[0044] The above-mentioned message filtering method can be applied to the message filtering device 10. The parsing module 12 in this embodiment is used to determine whether the message is an initial message sent during the connection handshake phase; and if the message is an initial message sent during the connection handshake phase, the initial message is decomposed according to the QUIC protocol specification to obtain encrypted protocol control information.

[0045] For step 031, the connection handshake phase is a handshake process that two devices (such as a client sending an access request and a server being requested) must go through before securely transmitting actual data in a computer network. This handshake phase is specifically used for: mutual authentication, negotiating encryption algorithms, and generating a shared key for subsequent communication. For the QUIC protocol involved in this application, multi-level encryption is used in the handshake process. The encrypted handshake is used to negotiate the key, and the protocol control information in the encrypted handshake is carried by the Initial and Handshake packets. The QUIC protocol combines the handshake of the encryption layer and the transport layer, which can reduce the handshake latency. The initial message, i.e., the Initial packet of the QUIC protocol, is the first packet sent at the beginning of the handshake. The initial message includes protected payload information and header information, which are the control information necessary to establish a connection and the protocol control information used to initiate the TLS 1.3 encrypted handshake. TLS is a secure communication protocol that supports encryption and authentication, and TLS 1.3 is the TLS version used by the QUIC protocol.

[0046] For step 032, protocol control information is data used to manage and control the communication process itself, rather than application data (such as HTTP web page access requests) to be transmitted by the client, to ensure the correct establishment and security maintenance of the connection. Specifically, by parsing the initial message of the handshake phase through an intermediate device (such as a firewall) or network analysis tool (such as Wireshark), connection information, packet length, etc., can be obtained from the header information of the initial message, as well as the protected data information in the payload (i.e., UDP payload) encrypted using the public initial keys. All of this information belongs to protocol control information.

[0047] In this embodiment of the application, after confirming that the message belongs to the QUIC protocol, encrypted protocol control information can be obtained by parsing the initial message of the QUIC protocol. This provides a basic basis for determining whether the message needs to be filtered based on the protocol control information.

[0048] Please see Figure 2 and Figure 5 In some implementations, the encrypted protocol control information includes protected header information and protected payload information; 05: Decrypting the encrypted protocol control information includes: 051: Initialize the first decryptor used to decrypt the header information and the second decryptor used to decrypt the protected payload information; 053: Use the first decryptor to decrypt the header information to restore the unencrypted header information; 055: Using the unencrypted header information, a second decryptor is used to decrypt the protected payload information to restore the unencrypted payload information.

[0049] The above-mentioned message filtering method can be applied to the message filtering device 10. The decryption module 13 in this embodiment is used to initialize a first decryptor for decrypting header information and a second decryptor for decrypting protected payload information; the first decryptor is used to decrypt the header information to restore the unencrypted header information; using the unencrypted header information, the second decryptor is used to decrypt the protected payload information to restore the unencrypted payload information.

[0050] The encrypted protocol control information includes protected header information and protected payload information. This encrypted protocol control information comes from the initial parsing of the initial message of the QUIC protocol. In fact, QUIC header protection can be understood as covering some header fields (such as packet number) with a pseudo-random mask generated by an algorithm, making it look like ciphertext and preventing intermediate devices from eavesdropping.

[0051] It is understandable that the payload of the initial message is encrypted and cannot be directly decrypted by intermediate devices or network analysis tools. However, by using a public initial key (derived from a publicly available salt value and the target connection ID), endpoints (clients and servers) can decrypt this encrypted protocol control information and extract more specific feature information to determine whether to intercept or process the message.

[0052] The first decryptor uses a header key derived from the initial key to generate an identical mask using a specific algorithm. It then removes this mask from the received bytes, thereby restoring the original, complete plaintext header.

[0053] The second decryptor uses the payload key corresponding to the payload information and the initial vector of the symmetric encryption algorithm, combined with the data packet number obtained from the decrypted header information (as part of the encrypted random number or additional data), to execute a standard decryption algorithm and finally restore the complete payload information.

[0054] The unencrypted header or payload information includes the TLS 1.3 ClientHello handshake information, such as the TLS 1.3 ClientHello, which is the first step in the TLS handshake; Cipher Suites, which is a list of encryption algorithms and suites supported by the client; Server Name Indication (SNI), which is the domain name of the target server the client wants to connect to; Application-Layer Protocol Negotiation (ALPN), which is the application-layer protocol declared by the client, such as h3 for HTTP / 3; and Transport Parameters, which are QUIC-specific parameters, such as maximum stream ID and maximum packet size. These parameters are negotiated during the TLS handshake to optimize the performance of the QUIC connection.

[0055] The unencrypted payload information is message data that includes the final target domain name (SNI).

[0056] In this embodiment, decrypting the encrypted protocol control information already obtained in the QUIC initial message can be achieved by sequentially decrypting the protected header information and the protected payload information. A first decryptor can be used to decrypt the header information to restore the unencrypted header information. Using the initial key from the restored unencrypted header information, a second decryptor can be used to decrypt the protected payload information to restore the unencrypted payload information. The unencrypted header and payload information obtained through decryption can be used to more precisely determine whether the QUIC protocol message needs to be intercepted, filtered, or further processed. Furthermore, only the client and server corresponding to the QUIC connection can use the first decryptor to decrypt the header information, and the header information and the second decryptor to decrypt the payload information. Feature information such as SNI can be extracted from the CRYPTO frame containing the TLS1.3 ClientHello message (which belongs to the unencrypted payload information), thereby negotiating the security key, verifying identity, and establishing an encrypted session.

[0057] Please see Figure 2 and Figure 6 In some implementations, 07: Extract feature information for identifying the communication target from the decrypted protocol control information, including: 071: Traverse all data frames in the decrypted protocol control information, filter and reassemble the data frames carrying TLS handshake data to obtain the reassembled data; 073: In the reconstructed data, obtain the Server Name Indicator (SNI) as a feature information. The above-described message filtering method can be applied to the message filtering device 10. The extraction module 14 in this embodiment is used to traverse all data frames in the decrypted protocol control information, filter and reassemble data frames carrying TLS handshake data to obtain reassembled data; in the reassembled data, the server name indicator (SNI) is obtained as feature information. Among them, the characteristic information that identifies the communication target is the information of the website to be accessed, and the data frame carrying TLS handshake data is the CRYPTO frame in the TLS handshake process.

[0058] For step 071, reassembly specifically refers to the splicing operation of QUIC CRYPTO frames. Since a complete TLSClientHello message (containing SNI as characteristic information) may be fragmented into multiple consecutive CRYPTO frames for transmission, each CRYPTO frame carries offset and length fields, indicating the position of the TLS handshake data fragment carried by that CRYPTO frame within the complete TLS message. If CRYPTO frames arrive out of order (a common network phenomenon), reassembling them without following the offset will result in garbled text, making it impossible to obtain the characteristic information. Therefore, it is necessary to traverse these data frames, filter out the CRYPTO frames, and reassemble them according to their offset and length fields.

[0059] For step 072, SNI is an extension of the TLS protocol. At the very beginning of the TLS handshake, when the client sends the ClientHello message, it sends the domain name (hostname) of the website it wants to access to the server. This allows the client to explicitly inform the server of the requested target domain name (SNI) during the handshake, enabling the server to provide separate certificates for multiple websites sharing the same IP address. Successful acquisition of the SNI requires the complete TLS handshake data stream, meaning the CRYPTO frames need to be reassembled into a correctly ordered data stream. Finally, the SNI is used as feature information to determine whether filtering is necessary.

[0060] In addition, other protocol control information extracted during the parsing process, such as connectivity feature information (SNI) combinations like IP address, port number, and certificate information, can be used to establish and maintain a QUIC connection mapping table. Based on this table, SNI / IP can be queried using a hash table or a Bloom filter. If a set of feature mappings in the connection mapping table is on the whitelist, the protection is allowed; if it is on the blacklist, the connection is blocked and logged. The feature mappings and corresponding action results are stored in the data center for statistical analysis, optimization, and dynamic adjustment of the blacklist and whitelist.

[0061] In this embodiment, obtaining the Server Name Indicator (SNI) is the direct objective. The SNI addresses the problem of server mismatch errors caused by the inability of the server to determine which website the client intends to access during the TLS handshake, thus preventing the provision of a correct SSL certificate. By traversing all data frames in the decrypted protocol control information, filtering and reassembling data frames carrying TLS handshake data, the reassembled data is obtained, and the Server Name Indicator (SNI) is acquired. This transforms the previously decrypted protocol control information into a key identifier (SNI) that can be used to determine the target domain name.

[0062] Please see Figure 2 and Figure 7 In some implementations, 09: Based on the extracted feature information, the message is filtered, including: 091: Match the feature information with the preset filtering strategy library; 093: Based on the matching results, the message is allowed or blocked.

[0063] The above-mentioned message filtering method can be applied to the message filtering device 10. The filtering module 15 of this application embodiment is used to match the feature information with the preset filtering strategy library; and to allow or block the message according to the matching result.

[0064] The filtering policy library is a pre-configured, structured set of rules used to define actions to be taken to handle specific network traffic.

[0065] Specifically, for packets that do not match in the blacklist or whitelist, the QUIC feature information or the feature mapping on the connection mapping table are used to match each packet in the filtering policy library. If a policy is matched, actions such as blocking, redirection, or logging are taken. If no policy is matched, the packet can be allowed to pass through a proxy or other detection module, or it can be directly blocked.

[0066] In addition, after executing a filtering action, the corresponding action results can be fed back to the policy management center for statistics, optimization, and dynamic adjustment of the filtering policy library.

[0067] In this embodiment of the application, by matching the feature information with a preset filtering policy library and performing allow or block on the message according to the matching result, it is possible to perform policy matching and processing (allow or block) on target websites of different domains according to their existing processing methods, that is, to achieve more detailed URL filtering.

[0068] Please see Figure 2 and Figure 8 In some implementations, the message filtering method further includes: 081: If no feature information is extracted and the data frame carrying TLS handshake data is fragmented, the selected data frame is temporarily stored and reassembled when the subsequent data carrying TLS handshake data arrives. 083: Release message.

[0069] The above-mentioned message filtering method can be applied to the message filtering device 10. The filtering module 15 of this application is used to temporarily store the filtered data frames when no feature information is extracted and the data frames carrying TLS handshake data are fragmented, and then reassemble them when the data frames carrying TLS handshake data arrive later; and allow the message to pass.

[0070] TLS certificates are digital certificates containing information such as domain name, issuing authority, and public key. They are used to prove the identity of the server and ensure the confidentiality, integrity, and authenticity of data transmission.

[0071] This application aims to address the issues of delayed or failed Special Indicator (SNI) extraction caused by CRYPTO frame reassembly failure and QUIC protocol packet fragmentation in real network environments, ensuring the accuracy of the filtering system under complex network conditions. For packets where SNI extraction fails, the packets are allowed to proceed, enabling the QUIC handshake process to continue normally between the client and server. This ensures that connection timeouts or interruptions are not caused by processing delays in intermediate devices, thereby reducing false interceptions due to protocol compatibility issues.

[0072] All of the above technical solutions can be combined in any way to form optional embodiments of this application, and will not be described in detail here.

[0073] Please see Figure 9 The following is through Figure 9 The given process examples illustrate the message filtering method in the above embodiments provided in this application.

[0074] S1: Determine whether the transport layer protocol of the received message is UDP format, whether the UDP payload is complete, and whether it is associated with an established connection tracking session. If all the above conditions are met, proceed to S2; if none of the conditions are met, proceed to S11.

[0075] S2: Extract the UDP payload from the message and determine if it belongs to the first version of the QUIC protocol. If yes, proceed to S3; otherwise, proceed to S11.

[0076] S3: Parse the UDP payload. If it is confirmed to be the first data fragment and a QUIC initial message type, then execute S4; otherwise, execute S11.

[0077] S4: Disassemble the initial message to obtain the protected header information and the protected payload information.

[0078] S5: Use the first decryptor to decrypt the protected header information, restore the unencrypted header information, and use the second decryptor to decrypt the protected payload information.

[0079] S6: Determine if decryption was successful. If yes, proceed to S7; otherwise, proceed to S11.

[0080] S7: Traverse all data frames in the unencrypted payload information, filter and reassemble CRYPTO frames to obtain the TLS handshake data stream, and extract SNI.

[0081] S8: Determine whether SNI was successfully acquired. If yes, proceed to S9; otherwise, proceed to S10.

[0082] S9: Input SNI as feature information into the filtering strategy library for matching, and execute the processing actions in the strategy according to the matching results.

[0083] S10: Store the currently parsed data slice offset information into the record of the connection tracking session, and allow the current message to pass, waiting for the message carrying the subsequent data slice to arrive for reassembly processing.

[0084] S11: Skip this message (no need to continue detecting and controlling this traffic).

[0085] As can be understood, the fragmentation in the above process refers to the fact that a complete TLS handshake message is divided into multiple QUICCRYPTO frames, and the corresponding data fragments need to be arranged in order in order to extract feature information such as SNI.

[0086] Please see Figure 10 The following is through Figure 10The given state transition process example illustrates the packet filtering method in the above embodiments provided in this application. The diagram depicts the iptables-based packet filtering process, the core of which is the extraction of URL / SNI and policy matching for HTTP / HTTPS / QUIC (UDP) packets. iptables is a traffic control tool for Linux systems, and Content_filter is a custom packet filter using the method in the embodiments of this application. The state changes of packets flowing through Content_filter are as follows: (1) In the initial interception phase, the packet enters the PREROUTING chain of the nat table in iptables and first matches the urlfilter_redirect rule: if the packet matches the block_redirection_set (a predefined blacklist set), it is forwarded to the INPUT chain (sent to the local machine for processing, such as receiving the packet through the nginx server, which then interacts with the packet sender and displays an HTTP page to inform the user of the reason why the packet was intercepted); if the packet does not match the blacklist, it enters the mangle subchain of the FORWARD chain and triggers the ipt_urlfilter_target module (the module that implements the filtering function of this application).

[0087] (2) In the feature extraction stage, if the packets in the original direction (ctdir==ORIGINAL) are HTTP / HTTPS / UDP type packets, they enter the urlfilter_target module. First, the connection state is obtained and recorded through conntrack (a subsystem in the Netfilter framework, which is a state table used to track and manage the state and context information of all network connections passing through the local machine in real time), and the packet type is distinguished after parsing the TCP / UDP header: If it is an HTTP message, extract the URL from the HOST field of the HTTP request; If it is an HTTPS message, the SNI is extracted from the TLS layer to replace the URL as an identification feature. If it is a UDP message, further check whether it is a QUIC protocol and extract the SNI from the QUIC Initial message.

[0088] Other types of messages are allowed to proceed for further processing.

[0089] (3) During the message filtering stage, the extracted URL / SNI is matched with the predefined URL type database (such as a list of illegal domains / URLs): If the policy is matched, the port of the message is added to the block_redirection_set (subsequent messages are directly intercepted) policy and the current message is discarded; if the policy is not matched, the message enters the filter subchain of the FORWARD chain and is forwarded out after passing through the urlfilter_resen rule chain.

[0090] According to the message method provided in the embodiments of this application, the state transition process realizes unified filtering of three mainstream encrypted / unencrypted messages: HTTP (URL), HTTPS (SNI), and QUIC (SNI).

[0091] The message filtering method provided in this application identifies the protocol to which a message belongs and only parses the handshake phase of the message when the message belongs to the UDP-based QUIC protocol. This achieves accurate identification and processing of HTTP / 3 traffic, overcoming the problem of difficulty in intercepting HTTP / 3 traffic due to differences in message structure. Furthermore, the message filtering method decrypts encrypted protocol control information, breaking through the encryption barrier of the QUIC protocol. This allows for the extraction of feature information (such as SNI) used to identify the communication target from the decrypted protocol control information, transforming the originally encrypted and hidden features into valid interception credentials, thus solving the problem of feature extraction failure due to encryption. Finally, it abandons traditional methods such as port-based blocking or protocol rejection, instead using message filtering based on extracted feature information. This filtering strategy based on precise identifiers (such as domain names) achieves accurate identification of traffic selected for interception by the user, reducing the false interception rate. By continuously updating the policy library during the filtering process, a hierarchical matching data center can be established, improving the accuracy and effectiveness of policy matching.

[0092] Optionally, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0093] Please see Figure 11 In some embodiments, this application also provides an electronic device 20, which includes the message filtering device 10 in any of the above embodiments. Alternatively, the electronic device includes a processor 21 and a memory 22, wherein the memory stores a computer program 23, and the processor 21 executes the message filtering method as described in any of the above embodiments by calling the computer program 23 stored in the memory 22.

[0094] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0095] Therefore, embodiments of this application provide a computer-readable storage medium storing multiple computer programs that can be loaded by a processor to execute the steps of any of the message filtering methods provided in this application. Specific implementations of the above operations can be found in the preceding embodiments and will not be repeated here.

[0096] The storage medium may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0097] Since the computer program stored in the storage medium can execute the steps of any of the message filtering methods provided in the embodiments of this application, the beneficial effects that any of the message filtering methods provided in the embodiments of this application can achieve can be realized. For details, please refer to the previous embodiments, which will not be repeated here.

[0098] This application also provides a computer program product including computer instructions stored in a computer-readable storage medium. The processor of an electronic device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the electronic device to perform the corresponding process in any of the message filtering methods described in this application. For simplicity, further details are omitted here.

[0099] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A message filtering method, characterized in that, include: Receive messages and identify the protocol to which the message belongs; If the message belongs to the Fast UDP Internet Connection (QUIC) protocol based on User Datagram Protocol (UDP), then the handshake phase of the message is parsed to obtain encrypted protocol control information. Decrypt the encrypted protocol control information; Extract the feature information used to identify the communication target from the decrypted protocol control information; The message is filtered based on the extracted feature information.

2. The filtration method according to claim 1, characterized in that, The process of identifying the protocol to which the message belongs includes: Determine whether the transport layer protocol of the message is UDP format, whether the UDP payload is complete, and whether it belongs to an established connection tracking protocol; If the transport layer protocol of the message is UDP format, the UDP payload is complete, and it belongs to an established connection tracking protocol, then extract the UDP payload from the message; and Based on the characteristics of the UDP payload, determine whether the UDP payload belongs to the QUIC protocol.

3. The filtration method according to claim 1, characterized in that, The step of parsing the handshake phase of the message to obtain encrypted protocol control information includes: Determine whether the message is an initial message sent during the connection handshake phase; and If the message is an initial message sent during the connection handshake phase, then the initial message is deconstructed according to the specifications of the QUIC protocol to obtain the encrypted protocol control information.

4. The filtration method according to claim 1, characterized in that, The encrypted protocol control information includes protected header information and protected payload information; the decryption of the encrypted protocol control information includes: Initialize a first decryptor for decrypting the header information and a second decryptor for decrypting the protected payload information; The header information is decrypted using the first decryptor to restore the unencrypted header information; Using the unencrypted header information, the second decryptor is used to decrypt the protected payload information to restore the unencrypted payload information.

5. The filtration method according to claim 1, characterized in that, The step of extracting feature information for identifying communication targets from the decrypted protocol control information includes: Traverse all data frames in the decrypted protocol control information, filter and reassemble data frames carrying Transport Layer Security (TLS) handshake data to obtain reassembled data; In the recombined data, the Server Name Indicator (SNI) is obtained as the feature information.

6. The filtration method according to claim 5, characterized in that, Also includes: If the aforementioned feature information is not extracted and the data frame carrying TLS handshake data is fragmented, the selected data frame is temporarily stored and reassembled when subsequent data carrying TLS handshake data arrives. Release the message.

7. The filtration method according to claim 1, characterized in that, The filtering of the message based on the extracted feature information includes: The feature information is matched with a preset filtering strategy library; The message is allowed or blocked based on the matching result.

8. A message filtering device, characterized in that, include: An identification module is used to receive messages and identify the protocol to which the message belongs; The parsing module is used to parse the handshake phase of the message to obtain encrypted protocol control information if the message belongs to the Fast UDP Internet Connection (QUIC) protocol based on User Datagram Protocol (UDP). The decryption module is used to decrypt the encrypted protocol control information; The extraction module is used to extract feature information for identifying communication targets from the decrypted protocol control information; The filtering module is used to filter the message based on the extracted feature information.

9. An electronic device, characterized in that, The electronic device includes the message filtering device of claim 8; or, the electronic device includes a processor and a memory, the memory storing a computer program, the processor executing the message filtering method of any one of claims 1-7 by calling the computer program stored in the memory.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the program implements the message filtering method according to any one of claims 1-7.

11. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the message filtering method according to any one of claims 1-7.

Images