CN116074026A

CN116074026A - SNI domain name extraction method, electronic equipment and computer readable storage medium

Info

Publication number: CN116074026A
Application number: CN202111280714.9A
Authority: CN
Inventors: 宋科; 朱娜; 李华光
Original assignee: ZTE Corp
Current assignee: ZTE Corp
Priority date: 2021-10-29
Filing date: 2021-10-29
Publication date: 2023-05-05
Also published as: WO2023071958A1

Abstract

The application provides a method for extracting an SNI domain name indicated by a server name, electronic equipment and a computer readable storage medium, wherein the method for extracting the SNI domain name comprises the following steps: under the condition that a received data packet is a quick user data packet protocol (QUIC) initial packet connected with the Internet, decrypting a ciphertext part of a target length of a QUIC load in the received data packet to obtain a plaintext part of the target length; wherein the target length is less than the total length of the QUIC load; and decoding the plaintext part to obtain an SNI domain name.

Description

SNI domain name extraction method, electronic equipment and computer readable storage medium

Technical Field

The embodiment of the application relates to the field of intelligent operation and maintenance of mobile communication networks, in particular to a method for extracting a server name indication (SNI, server Name Indication) domain name, electronic equipment and a computer readable storage medium.

Background

In the field of intelligent operation and maintenance of a mobile communication network, network data extraction is an important basis for intelligent operation and maintenance. According to the definition of smart operation and maintenance by Gartner, a good smart operation and maintenance platform should have the following capabilities: network data extraction, measurement data extraction, log data extraction, document text extraction, historical data management, stream data management, automatic mode discovery and prediction, anomaly detection, root cause determination, on-demand delivery, and software as a service. The network data extraction function can be used for acquiring real-time service flow information in a network, so that an intelligent operation and maintenance system can conveniently process and analyze the real-time flow data, sense specific services and rapidly detect abnormality and intelligent response.

With fifth generation mobile communication technology (5 g,5 ^th Generation Mobile Communication Technology) the popularity of networks and mobile internet services are becoming more and more abundant and various, the requirements of different services on network load indexes (such as bandwidth, time delay, reliability, etc.) are all different, and some services need large bandwidth (such as: excellent video), some services require low latency (e.g.: a space wing cloud game), and so forth. The refined service perception based on the network data extraction function can be used for service key performance index (KPI, key Performance Indicator) analysis, high-value service quality difference and service quality (QoS, quality of Service) guarantee, which are important components in intelligent operation and maintenance.

In packet-domain mobile networks, the hypertext transfer protocol (HTTP, hyper Text Transfer Protocol) Host (Host) and HTTP (HTTPs, HTTP over TLS) server name indication (SNI, server Name Indication) domain names based on the secure transport layer protocol (TLS, transport Layer Security) in user internet traffic are one important type of network information metadata. The Host and SNI domain names can accurately represent various network service information, and extracting the Host and SNI domain names from network data and correlating related data flows are important methods for service awareness. And with the advent of domain name system (DNS, domain Name System) encryption technology, this method of extracting Host and SNI domain names is becoming more and more indispensable.

Conventionally, the Host field of the HTTP GET/POST request message exists in plain text, such as "Host: www.zte.com.cn ", then the extractable Host metadata is" www.zte.com.cn ".

The SNI domain name field of the ClientHello message of HTTPS also exists in plain text, such as "\x00\x00\x00\x14\x00\x12\x00\x00\x0Fh5.m. taobao.com. (the format of the SNI domain Name field in this example is 2-byte extension type \x00\x00, 2-byte extension length \x00\x14, 2-byte Server Name list length \x00\x12, 1-byte Server Name type \x00, 2-byte Server Name length \x00\x0F, and then the Server Name itself, i.e., "h5.m. taobao.com"), then the metadata of the extractable SNI domain Name is "h5.m. taobao.com".

In recent years, the evolution of network protocols has been ongoing, and google corporation has proposed the rapid user datagram protocol (UDP, user Datagram Protocol) internet connection (qic, quick UDP Internet Connection) protocol for a short period of time, which has been standardized by the internet engineering task force (IETF, internet Engineering Task Force) at month 5 of 2021, i.e., solicited review documents (RFC, request For Comments) 8999, RFC 9000, RFC 9001, RFC 9002. Since the QUIC protocol is implemented based on UDP, with the advantageous characteristics of Round-Trip delay (0-RTT), no head of queue blocking, multiplexing, connection migration, etc., it is expected that it will gradually replace most of the usage scenarios of HTTP and HTTPs, and more QUIC protocol-based traffic will appear in the network, such as: most of the traffic of internet companies such as Google (Google), youtube, facebook have adopted the QUIC protocol. Thus, it will also become very important to employ SNI domain name extraction in the qic initial package.

The QUIC protocol relies on TLS 1.3, the TLS 1.3 ClientHello message in the Crypto frame in the old version of the QUIC protocol is unencrypted, and the SNI domain name exists in a plaintext form and can be positioned and extracted by adopting a common codec mode. However, in newer versions of the QUIC protocol draft and standardized QUIC protocol versions RFC 9000/RFC 9001, it has been specified that the QUIC initial packet Crypto frame and ClientHello message are encrypted, requiring decryption to extract the SNI domain name.

According to RFC 9001, the aead_aes_128_gcm algorithm is used for decrypting the quench initial packet, which is at least 1200 bytes long, and applying the aead_aes_128_gcm algorithm for decrypting such long packets is very consuming to the central processing unit (CPU, central Processing Unit) performance of the system. The performance of the QUIC initial packet decryption may be reduced by a fraction compared to the process of extracting the Host for the plaintext HTTP GET/POST request message or the SNI domain name for the plaintext HTTPS ClientHello message, which results in significant performance consumption for the relevant Host system.

Disclosure of Invention

The embodiment of the application provides an SNI domain name extraction method, electronic equipment and a computer readable storage medium.

In a first aspect, an embodiment of the present application provides a method for extracting an SNI domain name, including: under the condition that a received data packet is a quick user data packet protocol (QUIC) initial packet connected with the Internet, decrypting a ciphertext part of a target length of a QUIC load in the received data packet to obtain a plaintext part of the target length; wherein the target length is less than the total length of the QUIC load; and decoding the plaintext part to obtain an SNI domain name.

In a second aspect, an embodiment of the present application provides an electronic device, including: at least one processor; and the memory is stored with at least one program, and when the at least one program is executed by the at least one processor, the extraction method of any SNI domain name is realized.

In a third aspect, an embodiment of the present application provides a computer readable storage medium, where a computer program is stored, where the computer program when executed by a processor implements any one of the SNI domain name extraction methods described above.

According to the SNI domain name extraction method, when the received QUIC load in the QUIC initial packet is decrypted, the ciphertext of the total length of the QUIC load is not decrypted, but only the ciphertext part with the target length is decrypted, so that the performance consumption of a CPU is reduced.

Drawings

Fig. 1 is a flowchart of an SNI domain name extraction method according to an embodiment of the present application;

FIG. 2 is a diagram of a package structure of a QUIC initial package provided in an embodiment of the present application;

fig. 3 is a schematic structural diagram of an IP header according to an embodiment of the present application;

FIG. 4 is a schematic diagram of a process for generating a decryption key and decryption parameters according to an embodiment of the present application;

FIG. 5 is a schematic diagram of the structure of the QUIC load provided by the embodiments of the present application;

fig. 6 is a block diagram of an SNI domain name extraction apparatus according to another embodiment of the present application.

Detailed Description

In order to better understand the technical solutions of the present application, the following describes in detail the SNI domain name extraction method, the electronic device, and the computer readable storage medium provided in the present application with reference to the accompanying drawings.

Example embodiments will be described more fully hereinafter with reference to the accompanying drawings, but may be embodied in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

In the absence of conflict, embodiments and features of embodiments herein may be combined with one another.

As used herein, the term "and/or" includes any and all combinations of at least one of the associated listed items.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of at least one other feature, integer, step, operation, element, component, and/or group thereof.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the relevant art and this application and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Fig. 1 is a flowchart of an SNI domain name extraction method according to an embodiment of the present application.

In a first aspect, referring to fig. 1, an embodiment of the present application provides a method for extracting an SNI domain name, including:

step 100, under the condition that the received data packet is a QUIC initial packet, decrypting a ciphertext part of a target length of a QUIC load in the received data packet to obtain a plaintext part of the target length; wherein the target length is less than the total length of the QUIC load.

In the embodiment of the present application, in the case where the received data packet is a quitc initial packet, as shown in fig. 2, the packet structure of the quitc initial packet includes: internet protocol (IP, internet Protocol) header and IP payload; wherein the IP payload comprises: a UDP header and UDP payload; wherein the UDP payload comprises: a QUIC header and a QUIC payload; wherein, part of the fields in the QUIC header are encrypted ciphertext, and the QUIC payload is also encrypted ciphertext. The starting position of the QUIC payload is unknown before decrypting the QUIC header; after decrypting the QUIC header, the starting position of the QUIC payload is known.

In some exemplary embodiments, the QUIC header may be decrypted using the AES_128_ECB algorithm and the QUIC payload may be decrypted using the AEAD_AES_128_GCM algorithm.

In some exemplary embodiments, the target length is greater than or equal to the length of the Crypto frame in the qic payload.

In some exemplary embodiments, in the case where the received data packet is not a quitc initial packet, the present flow is ended, i.e., the ciphertext portion of the target length of the quitc payload in the received data packet is not decrypted to obtain the plaintext portion of the target length.

In this embodiment of the present application, before decrypting the ciphertext portion of the target length of the quit load in the received data packet to obtain the plaintext portion of the target length, it is first determined whether the received data packet is a quit initial packet, and if the received data packet is a quit initial packet, the ciphertext portion of the target length of the quit load in the received data packet is decrypted to obtain the plaintext portion of the target length, so as to avoid decrypting illegal messages that are irrelevant and structured by hackers, and reduce the loss of CPU performance caused by unnecessary decryption attempts, that is, reduce the security risk of being attacked by denial of service (DoS, denial of Service) to a certain extent, where DoS attack takes up 100% of the CPU of the target system, and does not allow the target system to normally process other services.

In some exemplary embodiments, the received data packet is determined to be a QUIC initial packet if the following conditions are met: determining the received data packet as a UDP packet according to the IP header of the received data packet; determining the received data packet as an uplink packet according to the IP header of the received data packet; determining the received data packet as the first packet of the UDP flow according to the IP header and the UDP header of the received data packet; determining that the length of the UDP load of the received data packet is greater than or equal to a preset length according to the UDP header of the received data packet; determining that the received data packet is a QUIC long packet according to the QUIC header of the received data packet; the received data packet is determined to be the QUIC initial packet based on the QUIC header of the received data packet.

In some exemplary embodiments, it is determined that the received data packet is not a QUIC initial packet if any of the following conditions are met: determining that the received data packet is not a UDP packet according to the IP header of the received data packet; or determining that the received data packet is not an uplink packet according to the IP header of the received data packet; or determining that the received data packet is not the first packet of the UDP stream based on the IP header and the UDP header of the received data packet; or determining that the length of the UDP load of the received data packet is smaller than the preset length according to the UDP header of the received data packet; or determining that the received data packet is not a QUIC long packet according to the QUIC header of the received data packet; alternatively, it is determined from the QUIC header of the received data packet that the received data packet is not the QUIC initial packet.

In some exemplary embodiments, since the QUIC protocol is implemented based on UDP, the QUIC initial packet must be a UDP packet, requiring a determination as to whether the received data packet is a UDP packet.

Specifically, for internet Protocol version 4 (IPv 4, internet Protocol Version 4), it is determined whether the received data packet is a UDP packet according to a Protocol field in an IP header of the received data packet; if the value of the Protocol field is 17, determining that the received data packet is a UDP packet; if the value of the Protocol field is not 17, it is determined that the received data packet is not a UDP packet.

For internet protocol version 6 (IPv 6, internet Protocol Version 6), determining whether the received packet is a UDP packet based on the value of the next header (nexheader) field in the IP header of the received packet; if the value of one of the NextHeader fields is 17, determining that the received data packet is a UDP packet; if all the values of the nexthaader field are not 17, it is determined that the received packet is not a UDP packet.

In some exemplary embodiments, since the QUIC initial packet must be an upstream packet, it may be determined whether the received data packet is an upstream packet based on the value of the source IP address field in the IP header of the received data packet; if the value of the source IP address field is the IP address of the user, determining that the received data packet is an uplink packet; if the value of the source IP address field is the IP address of the network element device, it is determined that the received data packet is not an upstream packet.

In some exemplary embodiments, since the first packet of each UDP stream may be the qic initial packet, it is necessary to determine whether the received data packet is the first packet of a UDP stream. Specifically, according to the UDP stream management policy, the UDP packets having the same source IP address, source port number, destination IP address, and destination port number belong to the same UDP stream, and then it may be determined whether the received data packet is the first packet of the UDP stream according to the source IP address field and destination IP address field in the IP header of the received data packet and the values of the source port number field and destination port number field in the UDP header. According to the UDP flow management strategy, the UDP packet of each received UDP flow is recorded, so that the values of a source IP address field, a destination IP address field, a source port number field and a destination port number field in the IP header of the received data packet can be respectively compared with the values of the source IP address field, the destination IP address field, the source port number field and the destination port number field in the IP header of the counted UDP packet of the UDP flow, and if the counted UDP flow has the UDP packet with the same value as the received data packet, the received data packet is determined not to be the first packet of the UDP flow; if the counted UDP packet with the same value as the received data packet does not exist in the source IP address field, the source port number field, the destination IP address field and the destination port number field, the received data packet is determined to be the first packet of the UDP flow.

In some exemplary embodiments, whether the Length of the UDP payload of the received packet is greater than or equal to a preset Length (e.g., 1200 bytes) may be determined according to the value of the Length field in the UDP header of the received packet; if the value of the Length field is greater than or equal to the preset Length, determining that the Length of the UDP load of the received data packet is greater than or equal to the preset Length; if the value of the Length field is smaller than the preset Length, determining that the Length of the UDP payload of the received data packet is smaller than the preset Length.

In some exemplary embodiments, as shown in FIG. 3, it may be determined whether the received data packet is a QUIC long packet based on the value of the most significant bit of the 1 st byte (i.e., the packet information field in FIG. 3) in the QUIC header of the received data packet; if the value of the most significant bit is 1, determining that the received data packet is a QUIC long packet; if the value of the most significant bit is not 1, it is determined that the received data packet is not a QUIC long packet.

In some exemplary embodiments, as shown in fig. 3, it may be determined whether the received data packet is a quit initial packet based on the values of the 3 rd and 4 th bits calculated from the upper bits of the 1 st byte (i.e., the packet information field in fig. 3) in the quit header of the received data packet; if the values of the 3 rd bit and the 4 th bit are both 0, determining that the received data packet is a QUIC initial packet; if the value of at least one of the 3 rd bit and the 4 th bit is not 0, it is determined that the received data packet is not the QUIC initial packet.

In some exemplary embodiments, decrypting the ciphertext portion of the target length of the QUIC payload in the received data packet to obtain the plaintext portion of the target length comprises: generating a decryption key and decryption parameters; and taking the decryption key, the decryption parameter and the target length short length as input parameters of a decryption algorithm, and decrypting the ciphertext part of the target length by adopting the decryption algorithm to obtain a plaintext part of the target length.

In some exemplary embodiments, the decryption parameters include: the start Offset of the QUIC payload, the total length of the QUIC payload FullLength, the initialization vector (IV, initialization Vector), the Associated Data (AD, associated Data), the authentication tag (AuthTag, authentication Tag).

Generating the decryption key and the decryption parameters includes: determining a corresponding SALT (SALT) value based on the quit version number of the received packet; and generating a decryption key and decryption parameters according to the salt value corresponding to the QUIC version number, the first special character string, the second special character string, the third special character string, the fourth special character string and a target connection identifier (DCID, destination Connection IDentifier) extracted from the received data packet.

In some exemplary embodiments, the salt value corresponding to the QUIC version number of the received data packet may be determined according to the correspondence between the QUIC version number and the salt value. For example, assuming the QUIC version number is 0xFF00001D, its corresponding SALT value is 0xafbfec289993D24c9e9786f19c6111e04390a899; and QUIC version number 0xFF000022, its corresponding SALT value is 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a. The SALT value, i.e. "SALT" in the cryptography field, is one of the materials used to generate keys, SALT being a string of numbers, which is used to combat the method by which rainbow table attacks collide with keys. The SALT values corresponding to the different qic versions may be different and may be found in the corresponding qic protocol publications.

In some exemplary embodiments, the first special string may be the string "tls13 client in", the second special string may be the string "tls13 quic iv", the third special string may be the string "tls13 quic hp", and the fourth special string may be the string "tls13 quic key".

In some exemplary embodiments, as shown in fig. 4, generating the decryption key and the decryption parameter according to the salt value corresponding to the quit version number, the first special character string, the second special character string, the third special character string, the fourth special character string, and the destination connection identification DCID extracted from the received data packet includes: generating an intermediate key ClientKey according to the salt value corresponding to the QUIC version number, the first special character string and the DCID; generating a first intermediate variable QuicIV according to the second special character string and the intermediate key ClientKey; generating a second intermediate variable QuicHP according to the third special character string and the intermediate key ClientKey; generating a decryption key QuicKey according to the fourth special character string and the intermediate key ClientKey; acquiring a message Number (PKN, packet Number) and a PKN length from a QUIC header in a received data Packet according to a second intermediate variable; acquiring a starting Offset (Offset) of the QUIC load and the total length FullLength of the QUIC load from the QUIC header according to the PKN length, and authenticating a tag AuthTag; acquiring an initialization vector IV from the QUIC header according to the first intermediate variable and PKN; the association data AD is retrieved from the quitc header according to the PKN and the PKN length.

In some exemplary embodiments, the intermediate key ClientKey may be generated based on the Extract algorithm and the Expand algorithm in a Hash-based Extract-and-Expand Key Derivation Function algorithm based on the extraction of a Hash-based message authentication code (HMAC, hash-based Message Authentication Code) and the DCID as parameters.

In some exemplary embodiments, the first intermediate variable quickiv may be generated based on the Expand algorithm in the HKDF algorithm with the second special string "ts 13 quic iv", the intermediate key ClientKey as parameters.

In some exemplary embodiments, the second intermediate variable quickp may be generated based on the Expand algorithm in the HKDF algorithm, with the third special string "ts 13 quic hp", the intermediate key ClientKey as parameters.

In some exemplary embodiments, the decryption key quickkey may be generated based on the Expand algorithm in the HKDF algorithm with the fourth special string "ts 13 quic key" tag, the intermediate key ClientKey as parameters.

In some exemplary embodiments, the PKN and PKN lengths may be obtained based on the aes_128_ecb algorithm, with the second intermediate variable quickp as a parameter, and according to the quitc header protection rules.

In some exemplary embodiments, the starting Offset of the QUIC payload and the total length FullLength of the QUIC payload may be obtained according to the QUIC header encoding rules based on the PKN length.

In some exemplary embodiments, the authentication tag AuthTag may be obtained according to the quitc header encoding rules based on PKN length.

In some exemplary embodiments, the initialization vector IV may be obtained according to the quitc header encoding rules based on the first intermediate variables quickv and PKN.

In some exemplary embodiments, the association data AD may be obtained according to the quitc header encoding rules based on PKN length and PKN.

And 101, decoding the plaintext part to obtain the SNI domain name.

In some exemplary embodiments, decoding the plaintext portion to obtain the SNI domain name includes: performing Crypto frame decoding on the plaintext part to obtain first decoded content; acquiring the CryptoData content in the first decoded content; performing ClientHello message decoding on the CryptoData content to obtain second decoded content; and acquiring the SNI domain name in the second decoding content.

In some exemplary embodiments, performing Crypto frame decoding and ClientHello message decoding on the plaintext portion to obtain the SNI domain name includes: performing Crypto frame decoding on the plaintext part to obtain first decoded content; under the condition that the first decoding verification is passed on the first decoding content, acquiring the CryptoData content in the first decoding content; performing ClientHello message decoding on the CryptoData content to obtain second decoded content; and under the condition that the second decoding verification is passed on the second decoding content, acquiring the SNI domain name in the second decoding content.

In some exemplary embodiments, in the event that the first decoding check is not passed on the first decoded content or the second decoding check is not passed on the second decoded content, the decryption is deemed to have failed and the SNI domain name cannot be extracted. That is, the decoding verification of the plaintext portion of the target length obtained after the ciphertext portion of the target length is decrypted and the correctness of the process of extracting the SNI domain name are used to replace the complete decryption and AEAD verification of the ciphertext of the FullLength length. Because the decryption performance of the AEAD_AES_128_GCM algorithm is closely related to the length, the performance consumption is larger as the decryption length is longer, and therefore the decryption method only decrypts the ciphertext part of the target length, and the decryption performance can be remarkably improved.

In this embodiment of the present application, since decryption is not performed for the full ciphertext full length, the AEAD verification cannot be passed, that is, according to the aead_aes_128_gcm algorithm, although the ciphertext portion with the ShortLength is decrypted, the decrypted plaintext portion may be obtained, but the AEAD verification may consider that decryption fails. The method in the embodiment of the application ignores the failure of the AEAD verification and still carries out subsequent processing on the decrypted plaintext part. And (3) attempting to decode the Crypto frame and the ClientHello message from front to back on the decrypted plaintext part, and considering that the decryption is successful and finishing QUIC SNI domain name extraction when the SNI domain name is successfully decoded. When the Crypto frame decoding process fails, or the ClientHello message decoding process fails, then the decryption is deemed to fail and the QUIC SNI domain name cannot be extracted.

In some exemplary embodiments, as shown in FIG. 5, the QUIC payload contains, in order, a Crypto frame and a Padding frame, the Crypto frame typically having only hundreds of bytes (e.g., 300 or 400 bytes or so), the Padding frame is full 0 Padding such that the length of the UDP payload of the QUIC initial packet is at least 1200 bytes, and because the QUIC SNI domain name is typically located earlier in the Crypto frame, the target length ShortLength may be taken as 640 bytes, starting from the starting Offset Offset of the QUIC payload, decrypting the ciphertext portion of the front ShortLength based on the AEAD_AES_128_GCM algorithm, and not decrypting the ciphertext portion of the rear FullLength-ShortLength length.

In some exemplary embodiments, as shown in fig. 5, performing a first decoding check on the first decoded content includes: the frame type field of the first decoded content indicates "CRYPTO"; the value of the CryptoOffset (CryptoOffset) field of the first decoded content is less than or equal to the second remaining length of the UDP payload; the value of the Crypto length (CryptoLength) field of the first decoded content is less than or equal to the third remaining length of the UDP payload.

In some exemplary embodiments, as shown in fig. 5, performing the first decoding check on the first decoded content does not pass includes: the frame type field of the first decoded content indicates not "CRYPTO"; alternatively, the value of the CryptoOffset field of the first decoded content is greater than the second remaining length of the UDP payload; alternatively, the value of the CryptoLength field of the first decoded content is greater than the third remaining length of the UDP payload.

As shown in fig. 5, the frame type field is located at byte 1, and when the value of the frame type field is 0x06, the frame type indicated by the frame type field is "CRYPTO".

As shown in fig. 5, the CryptoOffset field starts from byte 2 and occupies a variable length number of bytes. The second remaining length of the UDP payload is the difference of the total length of the UDP payload minus the length of the quench header, the length of the frame type field, the length of the CryptoOffset field.

As shown in fig. 5, the CryptoLength field follows the CryptoOffset field, occupying a variable length number of bytes. The third remaining length of the UDP payload is the difference of the total length of the UDP payload minus the length of the quit header, the length of the frame type field, the length of the CryptoOffset field, the length of the CryptoLength field.

As shown in fig. 5, the CryptoData field is located after the CryptoLength field, and the value of the CryptoData field is the CryptoData content. When the first decoding verification is passed on the first decoded content, the CryptoData content in the first decoded content can be obtained.

In some exemplary embodiments, as shown in fig. 5, performing a second decoding check on the second decoded content includes: a Handshake type (Handshake) field in the second decoded content indicates "Client Hello"; the value of a ClientHello length (ClientHello length) field in the second decoded content is less than or equal to a fourth remaining length of the value of the CryptoLength field; the 5 th byte and the 6 th byte in the second decoded content represent "TLS 1.2"; the value of a session identification length (SessionIdLength) field in the second decoded content is within a value range [0, 32 ]; the value of a cipher-group-length (ciphersuite length) field in the second decoded content is less than or equal to a fifth remaining length of the value of the clienthello length field; a value of a compression method length (compression method length) field in the second decoded content is less than or equal to a sixth remaining length of a value of a clienthellongth field; the value of an extension length (extensionlength) field in the second decoded content is less than or equal to a seventh remaining length of the value of the clienthellongth field; an extension type (ExtensionType) field in the second decoded content indicates a Server name (Server name); the value of an extension server name length (extensionservername) field in the second decoded content is less than or equal to the eighth remaining length of the value of the extensionlength field; a value of a server name list length (servernamelist length) field in the second decoded content is less than or equal to a ninth remaining length of a value of an ExtensionServerNameLength field; a server name type (servername type) field in the second decoded content indicates a host name (host name); the value of a server name length (ServerNameLength) field in the second decoded content is greater than 0 and less than or equal to a tenth remaining length of the value of the ExtensionServerNameLength field.

In some exemplary embodiments, as shown in fig. 5, performing the second decoding check on the second decoded content does not pass includes: the Handshake field in the second decoded content indicates not "Client Hello"; or, the value of the clienthello length field in the second decoded content is greater than the fourth remaining length of the value of the CryptoLength field; alternatively, the 5 th byte and the 6 th byte in the second decoded content represent not "TLS 1.2"; or, the value of the SessionIdLength field in the second decoded content is outside the value Fan Gang, 32 ]; alternatively, the value of the ciphersuite length field in the second decoded content is greater than the fifth remaining length of the value of the clienthellongth field; alternatively, the value of the compression method length field in the second decoded content is greater than the sixth remaining length of the value of the clienthellongth field; or, the value of the extensionlength field in the second decoded content is greater than the seventh remaining length of the value of the clienthello length field; alternatively, the ExtensionType field in the second decoded content indicates that it is not a Server name; or, the value of the extensionservername field in the second decoded content is greater than the eighth surplus length of the value of the extensionname field; or, the value of the servernalistlength field in the second decoded content is greater than the ninth remaining length of the value of the extensionservernallength field; alternatively, the ServerNameType field in the second decoded content indicates that it is not a hostname; alternatively, the value of the ServerNameLength field in the second decoded content is less than 0 or greater than the tenth remaining length of the value of the ExtensionServerNameLength field.

As shown in fig. 5, the handle field is located at byte 1 of the second decoded content, and when the value of the handle field is 0x01, the handle field indicates "Client Hello".

As shown in fig. 5, the clienthello length field is located from the 2 nd byte to the 4 th byte of the second decoded content. The fourth remaining length of the value of the CryptoLength field is the value of the CryptoLength field minus 4.

As shown in fig. 5, when the values of the 5 th byte and the 6 th byte in the second decoded content are 0x0303, "TLS 1.2" is indicated.

As shown in fig. 5, the 7 th to 32 th bytes in the second decoded content are Random (Random) fields, and are not checked.

As shown in fig. 5, the sessionidllength field is located after the Random field, and is followed by a session identifier (SessionId) field, where the value of the SessionId field is the SessionId content.

As shown in fig. 5, the ciphersuites length field follows the SessionId field. The fifth remaining length of the value of the clienthello length field is the difference of the value of the clienthello length field minus 35, the length of the SessionId field, and the length of the ciphersuites length field.

As shown in fig. 5, the CipherSuites length field is followed by a cipher suite (CipherSuites) field whose value is the CipherSuites content.

As shown in fig. 5, the compression methods length field is located after the ciphertests field, and the compression methods length field is followed by a compression methods field, the value of which is the compression methods content. The sixth remaining length of the value of the clienthello length field is the difference of the value of the clienthello length field minus 35, the length of the SessionId field, the length of the CipherSuites length field, the length of the CipherSuites field, the length of the compression method length field.

As shown in fig. 5, the extensionlength field is located after the compression methods field. The seventh remaining length of the value of the ClientHelloLength field is the difference of the value of the ClientHelloLength field minus 35, the length of the SessionId field, the length of the CipherSuitesLength field, the length of the CipherSuite field, the length of the Compressmethod Length field, the length of the Compressmethod field, the length of the Extension Length field.

As shown in fig. 5, the ExtensionType field is located after the extensionlength field, and indicates a Server name when the value of the ExtensionType field is 0x 0000.

As shown in fig. 5, the ExtensionServerNameLength field is located after the ExtensionType field, and the eighth remaining length of the value of the extensionlength field is the difference of the value of the extensionlength field minus the length of the ExtensionType field and the length of the ExtensionServerNameLength field.

As shown in fig. 5, the servernalistlength field is located after the extensionservernalmelength field, and the ninth remaining length of the value of the extensionservernalmelength field is the difference of the value of the extensionservernalmelength field minus the length of the servernalistlength field.

As shown in fig. 5, when the ServerNameType field is located after the servernamelistvength field and the value of the ServerNameType field is 0, the ServerNameType field indicates a host name.

As shown in fig. 5, the servernalmelength field is located after the servernalmetype field, and the tenth remaining length of the value of the extensionservernalmelength field is the difference obtained by subtracting the length of the servernallistvlength field, the length of the servernalmetype field, and the servernalmelength field from the value of the extensionservernalmelength field.

As shown in fig. 5, the server name (ServerName) field is located after the ServerName field, and the value of the ServerName field is the SNI domain name.

In the embodiment of the present application, after performing Crypto frame decoding on the plaintext portion to obtain first decoded content, performing a first decoding check on the first decoded content; the first decoding verification, that is, the verification while decoding, may also be performed on the first decoded content in the process of decoding the plain text portion to obtain the first decoded content, for example, the decoded field is verified every time a field is decoded.

In the embodiment of the application, after the CryptoData content is decoded by the ClientHello message to obtain second decoded content, second decoding verification may be performed on the second decoded content; the second decoding verification, that is, the verification while decoding, may also be performed on the second decoded content in the process of decoding the CryptoData content to obtain the second decoded content by using the ClientHello message, for example, the decoded field is verified every time a field is decoded.

In some exemplary embodiments, since reducing the decryption length would result in failure to verify by authenticated encryption of the associated data (AEAD, authenticated Encryption with Associated Data), lightweight verification of Crypto frame decoding and ClientHello message decoding is introduced in place of AEAD verification, thereby proving the correctness of decryption.

In some exemplary embodiments, in the case that the received data packet is a quick user data packet protocol internet connection quitc initial packet, the method further comprises: and if the received data packet meets the decryption condition of the QUIC load, continuing to execute the step of decrypting the ciphertext part of the target length of the QUIC load in the received data packet to obtain the plaintext part of the target length. According to the method, under the condition that the received data packet meets the decryption condition of the QUIC load, the ciphertext part of the target length of the QUIC load in the received data packet is decrypted to obtain the plaintext part of the target length, so that illegal messages which are irrelevant and constructed by hackers are further prevented from being decrypted, the loss of CPU performance caused by unnecessary decryption attempts is further reduced, and the security risk under DOS attack is further reduced.

In some exemplary embodiments, when the received data packet does not meet the decryption condition of the qic payload, the present process is ended, that is, the ciphertext portion of the target length of the qic payload in the received data packet is not decrypted to obtain the plaintext portion of the target length, thereby further avoiding decrypting the irrelevant and hacked illegal messages, further reducing the CPU performance loss caused by unnecessary decryption attempts, that is, further reducing the security risk under DOS attack.

In some exemplary embodiments, it is determined that the received data packet satisfies the decryption condition of the QUIC payload if: extracting a correct QUIC version number from a received data packet, wherein the QUIC version number is a version number corresponding to a version supported by a system; correctly extracting DCID from the received data packet; the sum of the length of the QUIC payload and the length of the QUIC header extracted from the received data packet is equal to the length of the UDP payload.

In some exemplary embodiments, it is determined that the received data packet does not satisfy the decryption condition of the QUIC payload if any of the following conditions are satisfied: the correct QUIC version number cannot be extracted from the received data packet; alternatively, the extracted QUIC version number is not the version number corresponding to the version supported by the system; or, the DCID cannot be extracted correctly from the received data packet; alternatively, the sum of the length of the QUIC payload and the length of the QUIC header extracted from the received data packet is not equal to the length of the UDP payload.

In some exemplary embodiments, as shown in FIG. 3, the QUIC version number is located at the 2 nd byte to the 5 th byte of the QUIC header, consisting of 4 bytes. Whether the extracted QUIC version number is the version number corresponding to the version supported by the system can be judged according to the version number corresponding to the version supported by the preset system; if the version number corresponding to the version supported by the preset system contains the extracted QUIC version number, determining that the extracted QUIC version number is the version number corresponding to the version supported by the system; if the version number corresponding to the version supported by the preset system does not contain the extracted QUIC version number, the extracted QUIC version number is determined not to be the version number corresponding to the version supported by the system.

Or judging whether the extracted QUIC version number is the version number corresponding to the version supported by the system according to the corresponding relation between the version number corresponding to the version supported by the preset system and the SALT (SALT) value; if the corresponding relation contains the extracted QUIC version number, determining that the extracted QUIC version number is the version number corresponding to the version supported by the system; if the extracted QUIC version number is not included in the correspondence, it is determined that the extracted QUIC version number is not the version number corresponding to the version supported by the system.

In some exemplary embodiments, the 6 th byte of the QUIC header is a DCID length field, the DCID length field occupies 1 byte, the value of the DCID length field is the DCID length, and the DCID can be extracted from the QUIC header based on the DCID length. For example, assuming a DCID length of 8 bytes, 8 bytes from the 7 th byte to the 14 th byte of the QUIC header are DCIDs. Therefore, whether the DCID can be correctly extracted from the received data packet can be judged according to the value of the DCID length field; specifically, if the value of the DCID length field is greater than the first remaining length of the UDP payload, it is determined that the DCID cannot be correctly extracted from the received data packet; if the value of the DCID length field is less than or equal to the first remaining length of the UDP payload, it is determined that the DCID can be correctly extracted from the received data packet. Wherein the first remaining length of the UDP payload is the difference between the total length of the QUIC payload and 6.

In some exemplary embodiments, as shown in FIG. 3, the QUIC header comprises, in order: packet information field, QUIC version number field, DCID length field, DCID field, source connection identification (SCID, source Connection IDentifier) length field, SCID field, token (Token) length field, token field, QUIC payload length field. The length of the qic header should be equal to the number of bytes occupied by these fields and the length of the qic payload should be equal to the value of the qic payload length field.

That is, according to the QUIC header encoding rule, the QUIC payload length field is located after the DCID length field, the DCIC field, the SCID length field, the SCID field, the Token length field, the Token field, and the decoding of the SCID length field, the SCID field, the Token length field, and the Token field is continued from the DCID field, thereby finding the position of the QUIC payload length field to extract the value of the QUIC payload length field. One byte after the DCID field is the SCID length field, and the value of the SCID length field is the length of the SCID field. For example, assuming that the SCID length field occupies 1 byte and the value of the SCID length field is 0, it means that there is no SCID field in the QUIC header, i.e., the SCID field is not occupied. Following the SCID field is a variable length Token length field, which may be 1 byte or 2 bytes or 4 bytes or 8 bytes. For example, assuming that the Token length field occupies 1 byte and the value of the Token length field is 0, it indicates that there is no Token field, i.e., the Token field does not occupy a space. Following the Token field is a variable length QUIC payload length field, which may be 1 byte or 2 bytes or 4 bytes or 8 bytes. For example, assume that the QUIC payload length field is 2 bytes, the value of the QUIC payload length field is 1332, i.e., the length of the QUIC payload is 1332 bytes; and, the offset of the QUIC payload length field in the QUIC header is 18 bytes, the value of the UDP length field is 1358, the value of the UDP length field indicates the sum of the UDP header and the UDP payload length, the UDP header is fixed to 8 bytes, and then it can be judged whether the sum of the length of the QUIC payload extracted from the received data packet and the length of the QUIC header is equal to the length of the UDP payload by judging whether the result of 1358-8-18-1332 is equal to 0 or not; specifically, if the result of 1358-8-18-1332 is equal to 0, it is determined that the sum of the length of the QUIC payload and the length of the QUIC header extracted from the received packet is equal to the length of the UDP payload; if the result of 1358-8-18-1332 is not equal to 0, then it is determined that the sum of the length of the QUIC payload and the length of the QUIC header extracted from the received packet is not equal to the length of the UDP payload.

This embodiment verifies the correctness of the QUIC header decoding based on whether the sum of the length of the QUIC payload and the length of the QUIC header extracted from the received data packet is equal to the length of the UDP payload.

In some exemplary embodiments, in the case where the received data packet is a qic initial packet, the method further comprises: and under the condition that the speed limit condition in the preset level range is met, continuing to execute the step of decrypting the ciphertext part of the target length of the QUIC load in the received data packet to obtain the plaintext part of the target length. According to the embodiment, under the condition that the speed limiting condition in the preset level range is met, the ciphertext part of the target length of the QUIC load in the received data packet is decrypted to obtain the plaintext part of the target length, so that legal information constructed by a hacker can be identified and ignored by the speed limiting condition, and the security risk of being attacked by DoS is further reduced.

In some exemplary embodiments, the present flow is ended without executing the step of decrypting the ciphertext portion of the target length of the QUIC payload in the received data packet to obtain the plaintext portion of the target length, in the event that the speed limit condition within the preset level range is not satisfied.

In some exemplary embodiments, in the case that the received data packet is a quick user data packet protocol internet connection quitc initial packet and the received data packet satisfies a decryption condition of the quitc payload, the method further comprises: and under the condition that the speed limit condition in the preset level range is met, continuing to execute the step of decrypting the ciphertext part of the target length of the QUIC load in the received data packet to obtain the plaintext part of the target length. According to the embodiment, under the condition that the speed limiting condition in the preset level range is met, the ciphertext part of the target length of the QUIC load in the received data packet is decrypted to obtain the plaintext part of the target length, so that legal information constructed by a hacker can be identified and ignored by the speed limiting condition, and the security risk of being attacked by DoS is further reduced.

In the embodiment of the application, the level range can be set at will according to actual needs. For example, the level range includes any one of the following: the same user and the same thread.

In some exemplary embodiments, satisfying the speed limit condition within the preset level range includes: the number of QUIC initial packets received in the ith preset time period is less than or equal to the ith preset threshold; wherein i is an integer of 1,2,3, … … and M in sequence, and M is an integer greater than or equal to 2. The embodiment introduces a multi-level speed limiting strategy, thereby further reducing the security risk of DoS attacks.

For example, assume that M is equal to 3, for each user, only M1 quit initial packets satisfying the decryption condition are allowed to be decrypted within N1 seconds, only M2 quit initial packets satisfying the decryption condition are allowed to be decrypted within N2 seconds, and only M3 quit initial packets satisfying the decryption condition are allowed to be decrypted within N3 seconds. For example, the system allows processing of only 10 of its quitc initial packets satisfying the decryption condition within 1 second, and of only 50 of its quitc initial packets satisfying the decryption condition within 10 seconds, and of only 250 of its quitc initial packets satisfying the decryption condition within 100 seconds, for each user.

For each thread, only Y1 QUIC initial packets satisfying the decryption conditions are allowed to be decrypted within X1 seconds, only Y2 QUIC initial packets satisfying the decryption conditions are allowed to be decrypted within X2 seconds, and only Y3 QUIC initial packets satisfying the decryption conditions are allowed to be decrypted within X3 seconds. For example, the system allows processing of only 100 of its QUIC initial packets satisfying the decryption conditions within 1 second, and of only 500 of its QUIC initial packets satisfying the decryption conditions within 10 seconds, and of only 2500 of its QUIC initial packets satisfying the decryption conditions within 100 seconds, for each thread.

In a second aspect, another embodiment of the present application provides an electronic device, including: at least one processor; and the memory is stored with at least one program, and when the at least one program is executed by the at least one processor, the SNI domain name extraction method is realized.

Wherein the processor is a device having data processing capabilities including, but not limited to, a Central Processing Unit (CPU) or the like; the memory is a device with data storage capability including, but not limited to, random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically charged erasable programmable read-only memory (EEPROM), FLASH memory (FLASH).

In some example embodiments, the processor, memory, and the like are interconnected by a bus, which in turn is connected to other components of the computing device.

In a third aspect, another embodiment of the present application provides a computer readable storage medium, where a computer program is stored, where the computer program when executed by a processor implements any one of the SNI domain name extraction methods described above.

In a fourth aspect, another embodiment of the present application provides an apparatus for extracting an SNI domain name, including: the decryption module 601 is configured to decrypt a ciphertext portion of a target length of a quit payload in a received data packet to obtain a plaintext portion of the target length when the received data packet is a quick user data packet protocol internet connection quit initial packet; wherein the target length is less than the total length of the QUIC load; and the decoding module 602 is configured to decode the plaintext portion to obtain an SNI domain name.

In some exemplary embodiments, the decryption module 601 is specifically configured to: under the condition that the received data packet is a quick user data packet protocol (QUIC) initial packet connected with the Internet, under the condition that the speed limit condition in the preset level range is met, decrypting the ciphertext part of the target length of the QUIC load in the received data packet to obtain the plaintext part of the target length.

In some exemplary embodiments, the level range includes any one of: the same user and the same thread.

In some exemplary embodiments, the meeting the speed limit condition within the preset level range includes: the number of QUIC initial packets received in the ith preset time period is less than or equal to the ith preset threshold; wherein i is an integer of 1,2, … … and M in sequence, and M is an integer greater than or equal to 2.

In some exemplary embodiments, the decryption module 601 is specifically configured to: and under the condition that the received data packet is a quick user data packet protocol (QUIC) initial packet, under the condition that the received data packet meets the decryption condition of the QUIC load, decrypting the ciphertext part of the target length of the QUIC load in the received data packet to obtain the plaintext part of the target length.

In some exemplary embodiments, the received data packet meeting the decryption condition of the QUIC payload comprises: extracting a correct QUIC version number from the received data packet, wherein the QUIC version number is a version number corresponding to a version supported by a system; correctly extracting a target connection identifier DCID from the received data packet; the sum of the length of the QUIC payload and the length of the QUIC header extracted from said received data packet is equal to the length of the user data packet protocol UDP payload.

In some exemplary embodiments, the received data packet is a quick user data packet protocol internet connection quitc initial packet comprising: determining that the received data packet is a user data packet protocol UDP packet according to an Internet protocol IP header of the received data packet; determining that the received data packet is an uplink packet according to the IP header of the received data packet; determining that the received data packet is the first packet of a UDP flow according to the IP header and the UDP header of the received data packet; determining that the length of the UDP load of the received data packet is greater than or equal to a preset length according to the UDP header of the received data packet; determining that the received data packet is a QUIC long packet according to the QUIC header of the received data packet; and determining the received data packet as a QUIC initial packet according to the QUIC header of the received data packet.

In some exemplary embodiments, the decryption module 601 is specifically configured to decrypt the ciphertext portion of the target length of the QUIC payload in the received data packet to obtain a plaintext portion of the target length in the following manner: generating a decryption key and decryption parameters; and taking the decryption key, the decryption parameter and the target length as input parameters of a decryption algorithm, and decrypting the ciphertext part of the target length by adopting the decryption algorithm to obtain the plaintext part of the target length.

In some exemplary embodiments, the decryption parameters include: the initial offset of the QUIC load, the total length of the QUIC load, an initialization vector IV, associated data AD, and an authentication tag AuthTag;

the decryption module 601 is specifically configured to implement the generating a decryption key and decryption parameters in the following manner: determining a corresponding salt value according to the QUIC version number of the received data packet; and generating the decryption key and the decryption parameter according to the salt value, the first special character string, the second special character string, the third special character string, the fourth special character string and the target connection identifier DCID extracted from the received data packet, which correspond to the QUIC version number.

In some exemplary embodiments, the decryption module 601 is specifically configured to implement the generation of the decryption key and the decryption parameter according to the salt value, the first special string, the second special string, the third special string, the fourth special string, and the destination connection identifier DCID extracted from the received data packet, where the salt value, the first special string, the second special string, the third special string, and the fourth special string correspond to the quit version number in the following manner: generating an intermediate key according to the salt value corresponding to the QUIC version number, the first special character string and the DCID; generating a first intermediate variable from the second special string and the intermediate key; generating a second intermediate variable from the third special string and the intermediate key; generating the decryption key from the fourth special string and the intermediate key; obtaining a message number PKN and a PKN length from a QUIC header in the received data packet according to the second intermediate variable; acquiring a starting offset of the QUIC load, a total length of the QUIC load and the AuthTag from the QUIC header according to the PKN length; obtaining the IV from the qic header according to the first intermediate variable and the PKN; the AD is obtained from the QUIC header according to the PKN and the PKN length.

In some exemplary embodiments, the decoding module 602 is specifically configured to: performing Crypto frame decoding on the plaintext part to obtain first decoded content; under the condition that the first decoding verification is passed on the first decoding content, acquiring the CryptoData content in the first decoding content; performing ClientHello message decoding on the CryptoData content to obtain second decoded content; and under the condition that the second decoding verification is passed on the second decoding content, acquiring the SNI domain name in the second decoding content.

The specific implementation process of the SNI domain name extraction device in the embodiment of the present application is the same as the specific implementation process of the SNI domain name extraction method in the foregoing embodiment, and is not repeated here.

Those of ordinary skill in the art will appreciate that all or some of the steps, systems, functional modules/units in the apparatus, and methods disclosed above may be implemented as software, firmware, hardware, and suitable combinations thereof. In a hardware implementation, the division between the functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, one physical component may have multiple functions, or one function or step may be performed cooperatively by several physical components. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on computer readable media, which may include computer storage media (or non-transitory media) and communication media (or transitory media). The term computer storage media includes both volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data, as known to those skilled in the art. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computer. Furthermore, as is well known to those of ordinary skill in the art, communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media.

Example embodiments have been disclosed herein, and although specific terms are employed, they are used and should be interpreted in a generic and descriptive sense only and not for purpose of limitation. In some instances, it will be apparent to one skilled in the art that features, characteristics, and/or elements described in connection with a particular embodiment may be used alone or in combination with other embodiments unless explicitly stated otherwise. It will therefore be understood by those of ordinary skill in the art that various changes in form and details may be made therein without departing from the scope of the present application as set forth in the following claims.

Claims

1. A method for extracting an SNI domain name indicated by a server name comprises the following steps:

under the condition that a received data packet is a quick user data packet protocol (QUIC) initial packet connected with the Internet, decrypting a ciphertext part of a target length of a QUIC load in the received data packet to obtain a plaintext part of the target length; wherein the target length is less than the total length of the QUIC load;

and decoding the plaintext part to obtain an SNI domain name.

2. The SNI domain name extraction method according to claim 1, further comprising, in case the received data packet is a quick user data packet protocol internet connection quitc initial packet:

And under the condition that the speed limiting condition in the preset level range is met, continuing to execute the step of decrypting the ciphertext part of the target length of the QUIC load in the received data packet to obtain the plaintext part of the target length.

3. The SNI domain name extraction method according to claim 2, wherein the level range includes any one of the following:

the same user and the same thread.

4. The SNI domain name extraction method according to claim 2, wherein the meeting of the speed limit condition within the preset level range includes:

the number of QUIC initial packets received in the ith preset time period is less than or equal to the ith preset threshold; wherein i is an integer of 1,2, … … and M in sequence, and M is an integer greater than or equal to 2.

5. The SNI domain name extraction method according to claim 1, further comprising, in case the received data packet is a quick user data packet protocol internet connection quitc initial packet:

and if the received data packet meets the decryption condition of the QUIC load, continuing to execute the step of decrypting the ciphertext part of the target length of the QUIC load in the received data packet to obtain a plaintext part of the target length.

6. The SNI domain name extraction method of claim 5, wherein the received data packet meeting decryption conditions of the QUIC payload comprises:

extracting a correct QUIC version number from the received data packet, wherein the QUIC version number is a version number corresponding to a version supported by a system;

correctly extracting a target connection identifier DCID from the received data packet;

the sum of the length of the QUIC payload and the length of the QUIC header extracted from said received data packet is equal to the length of the user data packet protocol UDP payload.

7. The SNI domain name extraction method as in any one of claims 1-6, wherein the received data packet is a quick user data packet protocol internet connection quitc initial packet comprising:

determining that the received data packet is a user data packet protocol UDP packet according to an Internet protocol IP header of the received data packet;

determining that the received data packet is an uplink packet according to the IP header of the received data packet;

determining that the received data packet is the first packet of a UDP flow according to the IP header and the UDP header of the received data packet;

determining that the length of the UDP load of the received data packet is greater than or equal to a preset length according to the UDP header of the received data packet;

Determining that the received data packet is a QUIC long packet according to the QUIC header of the received data packet;

and determining the received data packet as a QUIC initial packet according to the QUIC header of the received data packet.

8. The SNI domain name extraction method as in any one of claims 1-6, wherein decrypting the ciphertext portion of the target length of the QUIC payload in the received packet to obtain a plaintext portion of the target length comprises:

generating a decryption key and decryption parameters;

and taking the decryption key, the decryption parameter and the target length as input parameters of a decryption algorithm, and decrypting the ciphertext part of the target length by adopting the decryption algorithm to obtain the plaintext part of the target length.

9. The SNI domain name extraction method of claim 8, wherein the decryption parameters include: the initial offset of the QUIC load, the total length of the QUIC load, an initialization vector IV, associated data AD, and an authentication tag AuthTag;

the generating the decryption key and the decryption parameter includes:

determining a corresponding salt value according to the QUIC version number of the received data packet;

and generating the decryption key and the decryption parameter according to the salt value, the first special character string, the second special character string, the third special character string, the fourth special character string and the target connection identifier DCID extracted from the received data packet, which correspond to the QUIC version number.

10. The SNI domain name extraction method according to claim 9, wherein the generating the decryption key and the decryption parameter according to the salt value corresponding to the QUIC version number, the first special string, the second special string, the third special string, the fourth special string, and the destination connection identifier DCID extracted from the received data packet includes:

generating an intermediate key according to the salt value corresponding to the QUIC version number, the first special character string and the DCID;

generating a first intermediate variable from the second special string and the intermediate key;

generating a second intermediate variable from the third special string and the intermediate key;

generating the decryption key from the fourth special string and the intermediate key;

obtaining a message number PKN and a PKN length from a QUIC header in the received data packet according to the second intermediate variable;

acquiring a starting offset of the QUIC load, a total length of the QUIC load and the AuthTag from the QUIC header according to the PKN length;

obtaining the IV from the qic header according to the first intermediate variable and the PKN;

the AD is obtained from the QUIC header according to the PKN and the PKN length.

11. The method for extracting an SNI domain name as claimed in any one of claims 1 to 6, wherein the decoding the plaintext portion to obtain the SNI domain name includes:

performing Crypto frame decoding on the plaintext part to obtain first decoded content;

under the condition that the first decoding verification is passed on the first decoding content, acquiring the CryptoData content in the first decoding content;

performing ClientHello message decoding on the CryptoData content to obtain second decoded content;

and under the condition that the second decoding verification is passed on the second decoding content, acquiring the SNI domain name in the second decoding content.

12. An electronic device, comprising:

at least one processor;

a memory having at least one program stored thereon, which when executed by the at least one processor, implements the method of extracting a server name indication SNI domain name according to any of claims 1-11.

13. A computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a method of extracting a server name indication SNI domain name according to any of claims 1-11.