A method for detecting URLs, a network device, and a storage medium.

Abstract

This specification provides a method, network device, and storage medium for detecting URLs. The method includes: receiving a message; obtaining the packet header information of the message; obtaining the packet number of the message by offsetting a pointer to the packet header information; decrypting the packet number; obtaining a first decryption result; obtaining a nonce value based on the first decryption result; obtaining the packet header of the message; decrypting the packet header using the first decryption result; obtaining a second decryption result; decrypting the message payload data based on the second decryption result and the nonce value to obtain a server name; obtaining the URL from the server name; and detecting the URL. This method can effectively reduce the impact of SSL offloading on device performance and improve device performance.

Description

Technical Field

[0001] This disclosure relates to the field of communication technology, and in particular to a method for detecting URLs, a network device, and a storage medium. Background Technology

[0002] Deep Packet Inspection (DPI) is a security mechanism that detects and controls network traffic passing through a device based on application-layer information. In the increasingly complex network security threats, many malicious behaviors (such as worms, spam, and vulnerabilities) are hidden in the application-layer payload of data packets. Traditional security protection technologies that rely solely on network and transport layer security detection are no longer sufficient to meet network security requirements. Therefore, devices need to have DPI functionality to detect and control network application-layer information, ensuring data content security and improving network security.

[0003] URL filtering controls the HTTP URLs accessed by users, allowing or blocking access to web resources to regulate user online behavior. For HTTPS URL filtering, it's necessary to filter content after the SSL certificate has been removed.

[0004] like Figure 1 As shown, HTTP / 3 is the third major version of the HTTP protocol. Unlike its predecessors HTTP / 1.1 and HTTP / 2, HTTP / 3 deprecates the TCP protocol and replaces it with the QUIC protocol based on UDP.

[0005] The HTTP / 3 protocol is based on QUIC, a new transport layer protocol built on top of UDP, which enables reliable transmission.

[0006] HTTP / 3 supports URL filtering because the URI and host portion of HTTP / 3 are encrypted. This requires negotiating the certificate and key during the SSL handshake process, followed by decryption of the HTTP / 3 data. However, the asymmetric key algorithm used in SSL offloading is computationally time-consuming and CPU-intensive, significantly impacting device performance. Summary of the Invention

[0007] This disclosure provides a method, network device, and storage medium for detecting URLs, which can effectively reduce the impact of SSL offloading on device performance and improve device performance.

[0008] This disclosure provides a method for detecting a URL, the method being based on the QUIC protocol, the method comprising:

[0009] Receive a message and obtain the data packet header information of the message;

[0010] The packet number of the message is obtained by offsetting the pointer of the packet header information, the packet number is decrypted, the first decryption result is obtained, and the Nonce value is obtained based on the first decryption result;

[0011] Obtain the Packet Header of the message, and decrypt the Packet Header using the first decryption result to obtain the decrypted second decryption result;

[0012] The ServerName is obtained by decrypting the message payload data based on the second decryption result and the Nonce value.

[0013] Obtain the URL from the Server Name and perform detection on the URL.

[0014] Optionally, after receiving the message, the method further includes:

[0015] Based on the QUIC Flag and Packet Type, determine whether the packet satisfies the Long Packet Header and QUIC_LPT_INITIAL type;

[0016] If the conditions are met, the steps of obtaining the packet number of the message and decrypting the packet number are executed; otherwise, the steps of obtaining the packet number of the message and decrypting the packet number are not executed.

[0017] The step of obtaining the PacketNumber of the message by offsetting the pointer information of the packet header includes:

[0018] The length of the DCID is obtained by offsetting the header information of the data packet by 4 bytes;

[0019] Offset DCID by Len+1 length to obtain the length of SCID;

[0020] Offset SCID Len+1 length to obtain Token Length;

[0021] Offset the token length by 1 (Len+1) to get the packet length.

[0022] Offset by 2 bytes to get the Packet Number.

[0023] Specifically, the process involves obtaining the Packet Header of the message, decrypting the Packet Header using the first decryption result, and obtaining the decrypted second decryption result, including:

[0024] Obtain the Packet Header, replace the original ciphertext with the first byte of the decryption and the first decryption result to obtain the second decryption result.

[0025] The step of decrypting the message payload data to obtain the Server Name based on the second decryption result and the Nonce value includes:

[0026] The obtained second decryption result and Nonce are used to decrypt the message payload data using OpenSSL EVP to obtain the Server Name.

[0027] The step of obtaining the URL from the Server Name and detecting the URL includes:

[0028] Obtain the CRYPTO Frame field from the decrypted payload data;

[0029] Get the Server Name from the CRYPTO Frame field, and get the URL from the Server Name.

[0030] As can be seen from the above embodiments, this disclosure only needs to parse and process the first QUIC interaction message (Initial type message) of the HTTP3 protocol and obtain the URL for detection. There is no need to perform deep parsing processing on the message, which can effectively reduce the impact of SSL offloading on device performance and improve device performance.

[0031] This disclosure also provides a network device that supports the QUIC protocol, the network device comprising:

[0032] A receiving module is used to receive messages and obtain the data packet header information of the messages;

[0033] The decryption module is used to obtain the PacketNumber of the message by offsetting the pointer information of the data packet header, decrypt the PacketNumber, obtain the first decryption result, and obtain the Nonce value based on the first decryption result;

[0034] The decryption module is further configured to obtain the Packet Header of the message, and decrypt the Packet Header using the first decryption result to obtain the decrypted second decryption result;

[0035] The processing module is used to decrypt the message payload data according to the second decryption result and the Nonce value to obtain the Server Name;

[0036] The processing module is also used to obtain the URL from the Server Name and to detect the URL.

[0037] The network device also includes:

[0038] The judgment module is used to determine whether the received message satisfies the Long Packet Header and QUIC_LPT_INITIAL type based on the QUIC Flag and Packet Type after receiving the message.

[0039] If the conditions are met, the steps of obtaining the packet number of the message and decrypting the packet number are executed; otherwise, the steps of obtaining the packet number of the message and decrypting the packet number are not executed.

[0040] This disclosure also provides a network device that supports the QUIC protocol. The network device includes a memory, a processor, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the method steps in any of the above embodiments.

[0041] This disclosure also provides a computer-readable storage medium storing a program that, when executed by a processor, implements the method steps of any of the above embodiments. Attached Figure Description

[0042] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this specification and, together with the description, serve to explain the principles of this specification.

[0043] Figure 1 This is a schematic diagram of a network protocol architecture provided in an embodiment of the present disclosure.

[0044] Figure 2 This is a schematic flowchart of a method for detecting a URL provided in an embodiment of this disclosure.

[0045] Figure 3 This is a schematic diagram of message data provided in an embodiment of the present disclosure. Detailed Implementation

[0046] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this specification as detailed in the appended claims.

[0047] The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of this specification. The singular forms “a,” “the,” and “the” as used in this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0048] It should be understood that although the terms first, second, third, etc., may be used in this specification to describe various information, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, without departing from the scope of this specification, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0049] QUIC (Quick UDP Internet Connection) is a UDP-based transport protocol introduced by Google. It implements the functions of TCP, HTTPS, and HTTP / 2, aiming to reduce network latency while ensuring reliability. Because UDP is a simple transport protocol, it eliminates the problems of TCP transmission acknowledgment, retransmission, and slow start. Establishing a secure connection only requires one round trip. It also implements HTTP / 2 multiplexing and header compression.

[0050] The HTTP / 3 message format mainly includes Packet Header, QUIC Frame Header, HTTP / 3 Frame Header, and the data portion, HTTP Message.

[0051] The Packet Header implements a reliable connection. When a UDP packet is lost, retransmission is achieved using the Packet Number in the Packet Header. The connection is also defined through the Connection ID field.

[0052] The QUIC Frame Header implements an ordered byte stream based on the QUIC Stream concept in unordered packet messages, which allows HTTP messages to be transmitted as if they were on a TCP connection.

[0053] The HTTP3 Frame Header defines the format of the HTTP Header and Body, as well as functions such as server push and QPACK codec streams.

[0054] HTTP / 3 supports URL filtering because the URI and host portion of HTTP / 3 are encrypted. This requires negotiating the certificate and key during the SSL handshake process, followed by decryption of the HTTP / 3 data. However, the asymmetric key algorithm used in SSL offloading is computationally time-consuming and CPU-intensive, significantly impacting device performance.

[0055] To address the aforementioned technical problems, this disclosure provides a method for detecting URLs, based on the QUIC protocol, such as... Figure 2 As shown, the method includes:

[0056] S201 receives a message and obtains the data packet header information of the message;

[0057] S202 obtains the Packet Number of the message by offsetting the pointer of the packet header information, decrypts the Packet Number, obtains the first decryption result, and obtains the Nonce value based on the first decryption result;

[0058] S203 obtains the Packet Header of the message, and decrypts the Packet Header using the first decryption result to obtain the decrypted second decryption result;

[0059] S204 Decrypts the message payload data according to the second decryption result and the Nonce value to obtain the ServerName;

[0060] S205 obtains the URL from the Server Name and performs detection on the URL.

[0061] In step S201, the data header information of the received message is obtained. Specifically, the QUIC Flag (QUIC first byte) is obtained to determine whether the QUIC header is a Long Packet Header or a Short Packet Header. For example, if first_byte&0x80 is not 0, it is determined that the QUIC header is a Long Packet Header. The scheme in this embodiment is applied to Long Packet Header.

[0062] Furthermore, the Packet Type is determined. In this embodiment, the solution is applied to the QUIC_LPT_INITIAL type.

[0063] In step S202, after obtaining the data packet header, offset by 4 bytes, obtain the length of DCID. If the length exceeds the maximum value of 20, return a parsing error.

[0064] Next, obtain the DCID and record it under the QUIC control block for subsequent decoding. Offset the DCID by Len+1 length to obtain the SCID length; if the length exceeds the maximum value of 20, return a parsing error.

[0065] Further, offset the SCID by 1 length to obtain the Token Length.

[0066] Furthermore, offset the Token by 1 length to obtain the packet length.

[0067] Further, offset by 2 bytes, now pointing to the Packet Number, and decrypt the Packet Number.

[0068] It should be noted that header protection applies to the least significant bits of the first byte and the Packet Number field. For long header packets, the four least significant bits of the first byte are protected; for short header packets, the five least significant bits of the first byte are protected. Therefore, regardless of the header format, the reserved bits and the packet number length field will be covered; the key phase bits of short header packets are also protected.

[0069] It should be noted that the last 4-5 bits of the first byte of the Initial packet header in the QUIC protocol, as well as the PacketNumber field in the header, are obfuscated using AES-128-ECB. The last two bits of the first byte indicate the storage length of the PacketNumber, making the Packet Number length of the packet invisible.

[0070] The key for encrypting these two parts is derived from the Initialization Vector (IV) and the protection key. This key uses "quichp" as a tag and applies to the least significant bit of the first byte of the header and the Packet Number field. If it is a long header, it encrypts 4 bits; if it is a short header, it encrypts at least 5 bits.

[0071] During the packet number decryption step, a password context EVP_CIPHER_CTX is created. The initial secrets of the QUIC initial packet are related to the version number and the target Connection ID, and the encryption algorithm is fixed at AES-128-GCM.

[0072] Obtain the sample data. For the Initial data packet, the sample content is the 16 bytes following the Packet Number.

[0073] The mask information is obtained through EVP_CipherUpdate based on the sampled data.

[0074] If it is a long header data packet, then the last 4 bits are de-obfuscated: buffer[0]^=mask[0]&0x0f; if it is a short header data packet, then the last 5 bits are de-obfuscated: buffer[0]^=mask[0]&0x1f.

[0075] Get the Packet Number length. The lowest 2 bits of the first byte indicate the length of the Packet Number. pn_length = (buffer[0] & 0x03) + 1.

[0076] Remove the Packet Number header protection to obtain the first decryption result:

[0077] for(int i = 0; i <pn_length;++i){

[0078] buffer[packet_number_offset+i]^=mask[i+1];

[0079] *truncated_pn=buffer[packet_number_offset+i]|(*truncated_pn)<<8);

[0080] }

[0081] Calculate the Packet Number, and use the Packet Number to calculate the final nonce:

[0082] memcpy(nonce,pp_cipher->pp_iv,TLS13_AEAD_NONCE_LENGTH);

[0083] / *Packet number is left-padded with zeroes and XORed with write_iv* /

[0084] nonce[sizeof(nonce)-4]^=(pn&0xff000000)>>24;

[0085] nonce[sizeof(nonce)-3]^=(pn&0x00ff0000)>>16;

[0086] nonce[sizeof(nonce)-2]^=(pn&0x0000ff00)>>8;

[0087] nonce[sizeof(nonce)-1]^=(pn&0x000000ff);

[0088] In step S203, for the payload data that needs to be decrypted, since the EVP decryption algorithm does not support decryption of packet-splitter data, the decrypted data needs to be cached and recorded under the QUIC control block. The payload data is the data after PacketNumber. This time, only the Initial request data packet decryption is supported.

[0089] The payload of the initial data packet uses the AES-128-GCM encryption algorithm. First, the OpenSSL EVP is initialized.

[0090] Obtain the Packet Header, get the second decryption result, and replace the original ciphertext with the first byte of the decryption and the plaintext data of the Packet Number.

[0091] The obtained Packet Header (decrypted) and nonce are processed by decrypting the payload data using OpenSSL EVP.

[0092] The decrypted content is then parsed and processed using the QUIC frame in step S204.

[0093] Specifically, the QUIC frame is parsed to obtain the Server Name, and the URL is obtained from the Server Name, thereby enabling URL detection.

[0094] In one example, such as Figure 3 As shown, CRYPTO Frame

[0095] Type: 0x06 This frame transmits encrypted handshake data. It does not belong to any specific stream; it corresponds to an encryption level. One encryption level corresponds to one CRYPTO Frame.

[0096] offset: A variable-length encoded integer that specifies the offset of the data in this frame within the stream.

[0097] Length: Variable-length encoding, specifies the number of bytes in the Crypto data.

[0098] Crypto data: encrypted messages.

[0099] When processing QUIC frames, the payload data is decrypted, and then the decrypted data is parsed. The QUIC frame type is obtained; if it is CRYPTO, the size and offset of the CRYPTO data are obtained, and parsing of the Crypto Data begins.

[0100] Parse the first character of the Crypto Data; if it is Client Hello (0x01),

[0101] The clienthello message is processed by offsetting each field, such as Record Layer, Handshake Type, and Random. These fields may have fixed lengths or be carried in the message. This process continues until the SNI field is extracted for encrypted traffic filtering.

[0102] As can be seen from any of the above embodiments, the solution in this embodiment can realize the URL detection of the message by parsing and processing the first QUIC interaction message (Initial type message) of the HTTP3 protocol, without the need for deep parsing processing, reducing the impact of SSL offloading on device performance and improving device performance.

[0103] Based on the method embodiments, this disclosure also provides a network device that supports the QUIC protocol, the network device comprising:

[0104] A receiving module is used to receive messages and obtain the data packet header information of the messages;

[0105] The decryption module is used to obtain the PacketNumber of the message by offsetting the pointer information of the data packet header, decrypt the PacketNumber, obtain the first decryption result, and obtain the Nonce value based on the first decryption result;

[0106] The decryption module is further configured to obtain the Packet Header of the message, and decrypt the Packet Header using the first decryption result to obtain the decrypted second decryption result;

[0107] The processing module is used to decrypt the message payload data according to the second decryption result and the Nonce value to obtain the Server Name;

[0108] The processing module is also used to obtain the URL from the Server Name and to detect the URL.

[0109] The network device also includes:

[0110] The judgment module is used to determine whether the received message satisfies the Long Packet Header and QUIC_LPT_INITIAL type based on the QUIC Flag and Packet Type after receiving the message.

[0111] If the conditions are met, the steps of obtaining the packet number of the message and decrypting the packet number are executed; otherwise, the steps of obtaining the packet number of the message and decrypting the packet number are not executed.

[0112] The network devices in this embodiment may include network devices with data processing capabilities, such as servers or routers.

[0113] This disclosure also provides a network device that supports the QUIC protocol. The network device includes a memory, a processor, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the method steps in any of the above embodiments.

[0114] This disclosure also provides a computer-readable storage medium storing a program that, when executed by a processor, implements the method steps of any of the above embodiments.

[0115] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0116] Other embodiments of this specification will readily occur to those skilled in the art upon consideration of the specification and practice of the invention claimed herein. This specification is intended to cover any variations, uses, or adaptations that follow the general principles of this specification and include common knowledge or customary techniques in the art not claimed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this specification are indicated by the following claims.

[0117] It should be understood that this specification is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this specification is limited only by the appended claims.

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

Claims

1. A method for detecting URLs, characterized in that, The method is based on the QUIC protocol and includes: Receive a message and obtain the data packet header information of the message; By offsetting the pointer of the data packet header information, the packet number of the message is obtained, the packet number is decrypted, the first decryption result is obtained, and the Nonce value is obtained based on the first decryption result; Obtain the Packet Header of the message, and decrypt the Packet Header using the first decryption result to obtain the decrypted second decryption result; The Server Name is obtained by decrypting the message payload data based on the second decryption result and the Nonce value. Obtain the URL from the Server Name and perform detection on the URL; Specifically, obtaining the packet number of the message by offsetting the pointer of the packet header information, and decrypting the packet number, includes: Based on the QUIC Flag and Packet Type in the packet header information, determine whether the packet meets the Long PacketHeader and QUIC_LPT_INITIAL type; if it does, then retrieve the Packet Number of the packet.

2. The method according to claim 1, characterized in that, After receiving the message, the method further includes: Based on the QUIC Flag and Packet Type, determine whether the packet satisfies the Long Packet Header and QUIC_LPT_INITIAL type; If the conditions are met, the steps of obtaining the packet number of the message and decrypting the packet number are executed; otherwise, the steps of obtaining the packet number of the message and decrypting the packet number are not executed.

3. The method according to claim 1, characterized in that, The step of obtaining the packet number of the message by offsetting the pointer of the packet header information includes: The length of the DCID is obtained by offsetting the header information of the data packet by 4 bytes; Offset DCID by Len+1 length to obtain the length of SCID; Offset SCID Len+1 length to obtain Token Length; Offset Token Len + 1 length to get packet Length Offset by 2 bytes to get the Packet Number.

4. The method according to claim 1, characterized in that, Obtain the Packet Header of the message, and decrypt the Packet Header using the first decryption result to obtain the decrypted second decryption result, including: Obtain the Packet Header, replace the original ciphertext with the first byte of the decryption and the first decryption result to obtain the second decryption result.

5. The method according to claim 1, characterized in that, The step of decrypting the message payload data based on the second decryption result and the Nonce value to obtain the Server Name includes: The obtained second decryption result and Nonce are used to decrypt the message payload data using OpenSSL EVP to obtain the ServerName.

6. The method according to claim 1, characterized in that, The step of obtaining the URL from the Server Name and detecting the URL includes: Obtain the CRYPTO Frame field from the decrypted payload data; Get the Server Name from the CRYPTO Frame field, and get the URL from the Server Name.

7. A network device, characterized in that, The network device supports the QUIC protocol, and the network device includes: A receiving module is used to receive messages and obtain the data packet header information of the messages; The decryption module is used to obtain the PacketNumber of the message by offsetting the pointer information of the data packet header, decrypt the PacketNumber, obtain the first decryption result, and obtain the Nonce value based on the first decryption result; The decryption module is further configured to obtain the Packet Header of the message, and decrypt the Packet Header using the first decryption result to obtain the decrypted second decryption result; The processing module is used to decrypt the message payload data according to the second decryption result and the Nonce value to obtain the Server Name; The processing module is further configured to obtain the URL from the Server Name and detect the URL; Specifically, obtaining the packet number of the message by offsetting the pointer of the packet header information, and decrypting the packet number, includes: Based on the QUIC Flag and Packet Type in the packet header information, determine whether the packet meets the Long PacketHeader and QUIC_LPT_INITIAL type; if it does, then retrieve the Packet Number of the packet.

8. The network device according to claim 7, characterized in that, The network device also includes: The judgment module is used to determine whether the received message satisfies the Long Packet Header and QUIC_LPT_INITIAL type based on the QUIC Flag and Packet Type after receiving the message. If the conditions are met, the steps of obtaining the packet number of the message and decrypting the packet number are executed; otherwise, the steps of obtaining the packet number of the message and decrypting the packet number are not executed.

9. A network device, characterized in that, The network device supports the QUIC protocol and includes: a memory, a processor, and a program stored in the memory and executable on the processor. When the program is executed by the processor, it implements the method steps as described in any one of claims 1 to 6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program that, when executed by a processor, implements the method steps as described in any one of claims 1 to 6.

Images