Method for blocking traffic based on domain in inline network

Abstract

This paper discloses a method for masking traffic based on functional variable names in an inline network. This embodiment provides a method for masking HTTP / 3 traffic based on functional variable names in a network environment where an inline masking system is constructed. In this inline network environment, the method identifies the relevant messages of received QUIC data packets, decodes them, and performs SNI parsing. When the parsing result is a masking target SNI, a pseudo-QUIC data packet is selectively generated and transmitted to the client. The client selectively masks the traffic based on the functional variable name. Then, the QUIC data packets received from the client are discarded. Alternatively, if a functional variable name that is not a masking target is identified, HTTP / 3 traffic is masked based on the functional variable name in the inline masking system transmitted to the server.

Description

[Technical Field]

[0001] An embodiment of the present invention relates to an HTTP / 3 traffic masking method based on functional variable names in a network environment consisting of an inline masking system. [Previous Technology]

[0002] The following content is merely background information related to this embodiment and does not constitute conventional technology.

[0003] Large enterprises such as Google and Meta are rapidly transitioning to HTTP / 3. HTTP / 3 is based on QUIC (Quick UDP Internet Connection), and as a result, its adoption on the internet is gradually expanding.

[0004] QUIC, as the basic choice for FAANG (Facebook, Apple, Amazon, Netflix, Google) for network streaming media and data transmission, is a popular new protocol. QUIC is a new session layer protocol based on UDP, offering extremely fast speeds, stability, and security, potentially replacing TLS & TCP. Therefore, the internet community often considers it a new transport layer protocol. The QUIC protocol significantly improves the security of network traffic packets, even protecting against basic sniffing of handshake packets to prevent packet modulation and easy sniffing by network equipment. Currently, functional variable name masking services treat DNS and TLS traffic as service objects; however, due to the increasing prevalence of encrypted DNS, the effectiveness of traditional DNS-based functional variable name masking methods is gradually decreasing.

[0005] The simplest access method for implementing masking based on functional variable names is DNS hijacking. Confirm whether it is necessary to intercept all DNS queries and mask the requested functional variable names.

[0006] However, when DNS requests are encrypted, the function variable name cannot be extracted. This issue occurs, for example, when using DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT). With the increasing adoption of DoH (e.g., in Firefox and Android), it is important to go beyond relying solely on DNS in order to achieve masking based on function variable names.

[0007] When only TLS traffic exists, detection and masking can be implemented within the actual TLS Handshake. To identify the functional variable name of the World Wide Web server in the connection, the client extracts the SNI (Server Name Indication) field from the unencrypted TLS Client Hello message. If the server name is the functional variable name of the masking object, the TLS connection will be masked. However, the drawback of the above method is that it only works in connections that do not use HTTP / 3. HTTP / 3 uses "UDP & QUIC & TLS" instead of "TCP & TLS," so it is difficult to extract the SNI within TLS or mask the TLS connection using the simple methods used in the past. Nevertheless, QUIC still uses TLS Handshake in its internal Initial data packets, so the SNI can be analyzed and extracted. However, the drawback is that extraction is not simple because it is encrypted using a fixed key (refer to RFC9001) based on the payload (and part of the header) of the Initial data packet. [Summary of the Invention]

[0008] [Problem to be Solved by the Invention] The purpose of this embodiment is to provide a method as follows: In an in-band network environment, the relevant messages of the received QUIC data packets are confirmed, and after decoding, SNI parsing is performed. When the parsing result is a masking object SNI, a pseudo QUIC data packet is selectively generated and transmitted to the client. The client selectively masks the traffic based on the functional variable name. Then, the QUIC data packets received from the client are discarded. Alternatively, when the functional variable name that is not a masking object is identified, HTTP / 3 traffic is masked based on the functional variable name in the network environment in which the in-band (inline) transmission to the server constitutes the masking system.

[0009] [Technical Means for Solving the Problem] One aspect of this embodiment provides a method for masking traffic based on functional variable name in an in-band network, comprising the following steps: receiving QUIC data packets from a client in an in-band network environment; after confirming that the QUIC data packet is a QUIC Client Initial data packet, generating a decoding result; based on the decoding result, confirming whether the decoding of the QUIC Client Initial data packet was successful; if the decoding of the QUIC Client Initial data packet is successful according to the confirmation result, after confirming the TLS Client Hello message based on the decoding result, implementing SNI (Server Name Indication). The process involves parsing and generating an SNI parsing result; based on the SNI parsing result, confirming whether the SNI parsing of the TLS client greeting message was successful; if the SNI parsing of the TLS client greeting message was successful according to the confirmation result, confirming whether the SNI parsing result is a masked object SNI; if the SNI parsing result is confirmed to be the masked object SNI, selectively generating a fake QUIC server initial data packet; selectively transmitting the fake QUIC server initial data packet to the client, masking traffic based on the functional variable name; and discarding the QUIC data packet received from the client.

[0010] As described above, according to this embodiment, the following technical effects are achieved: In an in-band network environment, the relevant messages of the received QUIC data packets are confirmed, and after decoding, SNI parsing is performed. When the parsing result is a masking object SNI, a pseudo QUIC data packet is selectively generated and transmitted to the client. The client selectively masks the traffic based on the functional variable name. Then, the QUIC data packet received from the client is discarded. Alternatively, when the functional variable name that is not a masking object is identified, it is transmitted to the server or client.

Implementation Method

[0012] Hereinafter, this embodiment will be described in detail with reference to the accompanying drawings.

[0013] Figure 1 is a system view of the traffic based on the functional variable name masking in the in-band network described in this embodiment.

[0014] According to this embodiment, the system for masking traffic based on functional variable name in an in-band network includes one HTTP / 3 client 112, another HTTP / 3 client 114, a third HTTP / 3 client 116, a traffic masking device 130, one HTTP / 3 server 142, another HTTP / 3 server 144, and a third HTTP / 3 server 146. The components included in the system for masking traffic based on functional variable name in an in-band network are not necessarily limited to these.

[0015] In-band network does not refer to a method of copying traffic to another network unrelated to traffic, such as out-of-band, but rather to the operation of a regular line. The traffic masking device 130 for in-band network only needs to increase traffic; therefore, its operation is unrelated to the path of traffic reduction. After receiving QUIC data packets, the traffic masking device 130 for in-band network does not transmit them to the outside before internal processing.

[0016] When the message is not relevant, the traffic masking device 130 for intranets will transmit it to the outside. The traffic masking device 130 for intranets generates a fake QUIC server initial data packet relative to the masking object data packet that needs filtering results, and transmits it or not. When the fake QUIC server initial data packet is transmitted, the traffic masking device 130 for intranets will quickly terminate the session. When the fake QUIC server initial data packet is transmitted, the data packet will not be transmitted to the server side, thus preventing it from communicating.

[0017] In an in-band network environment, the traffic masking device 130 masks the masking target website for HTTP / 3 traffic based on the functional variable name. The traffic masking device 130 is connected to both sides, namely, the client side and the server side, via in-band.

[0018] In an inline network environment, the traffic masking device 130 described in this embodiment receives QUIC data packets from the client. After confirming that the QUIC data packet is a QUIC Client Initial data packet, the traffic masking device 130 generates a decoding result. Based on the decoding result, the traffic masking device 130 confirms whether the decoding of the QUIC Client Initial data packet was successful. According to the confirmation result, when the decoding of the QUIC Client Initial data packet is successful, the traffic masking device 130, based on the decoding result, confirms the TLS Client Hello message and then performs SNI (Server Name Indication) resolution, generating an SNI resolution result. Based on the SNI resolution result, the traffic masking device 130 confirms whether the SNI resolution of the TLS Client Hello message was successful. According to the confirmation result, when the SNI resolution of the TLS Client Hello message is successful, the traffic masking device 130 confirms whether the SNI resolution result is the masking target SNI. Upon confirmation that the SNI resolution result is the masking object SNI, the traffic masking device 130 selectively generates a fake QUIC server initial data packet. The traffic masking device 130 selectively transmits the fake QUIC server initial data packet to the client, masking traffic based on the function variable name. The traffic masking device 130 discards the QUIC data packets received from the client.

[0019] When decoding the initial data packet of the QUIC client fails, the traffic masking device 130 identifies the functional variable name corresponding to the initial data packet of the QUIC client as a functional variable name unrelated to the functional variable name of the masking object, and transmits the initial data packet of the QUIC client to the server. When the SNI parsing of the TLS client greeting message fails, the traffic masking device 130 identifies the functional variable name corresponding to the TLS client greeting message as a functional variable name unrelated to the functional variable name of the masking object, and transmits the initial data packet of the QUIC client to the server. If the SNI parsing result is not confirmed to be the SNI of the masking object, the traffic masking device 130 transmits the initial data packet of the QUIC client to the server.

[0020] The traffic masking device 130 performs the following operations to facilitate the decoding of the QUIC Client Initial data packet: The traffic masking device 130 determines whether the QUIC Client Initial data packet is UDP and generates a payload parsing result. Based on the payload parsing result, the traffic masking device 130 generates multiple decoding keys for decoding. The traffic masking device 130 uses the multiple decoding keys to decode the QUIC Client Initial data packet. The traffic masking device 130 uses the multiple decoding keys to selectively authenticate the QUIC Client Initial data packet.

[0021] The traffic masking device 130 performs the following operations to facilitate SNI (Server Name Indication) resolution for TLS Client Hello messages. The traffic masking device 130 queries the cached memory for stored CRYPTO data. The traffic masking device 130 confirms the CRYPTO framework from the QUIC Client Initial Payload, parses the data, and generates an assembly result. Based on the assembly result, the traffic masking device 130 confirms the TLS Client Hello message from the CRYPTO data and generates a resolution result that resolves the SNI (Server Name Indication).

[0022] The traffic masking device 130 performs the following operations to generate a fake QUIC Server Initial data packet. The traffic masking device 130 generates a connection termination frame (CONNECTION_CLOSE Frame) and generates the packet number length and packet number to be included in the QUIC Server Initial Header, using the QUIC Server Initial Payload as its content. The traffic masking device 130 generates multiple encryption keys for encryption. The traffic masking device 130 uses the multiple encryption keys to generate an encryption and authentication tag for the QUIC Server Initial Payload. The traffic masking device 130 generates an encryption result that encrypts the packet number length and packet number of the QUIC Server Initial Header. Traffic masking device 130 uses the encryption result to generate a fake QUIC Server Initial data packet.

[0023] Figure 2 is a schematic diagram of the QUIC protocol in this embodiment.

[0024] QUIC (Quick UDP Internet Connection) was initially called GQUIC and was developed by Google. Later, the IETF adopted it and named it QUIC. Currently, both the Google version and the IETF version of QUIC have millions of users on the Internet.

[0025] QUIC is a UDP-based protocol that provides both transport and session layer functionality. Compared to conventional TCP-based connections, performance is significantly improved. As shown in Figure 2, QUIC replaces the "TCP & TLS" portion of the network.

[0026] The reliable components of TCP, such as damage repair, congestion control, and connection setup, are handled by QUIC, and the security provided by TLS is adjusted by QUIC.

[0027] QUIC itself implements TLS Handshake and TCP Handshake settings at the transport layer. Multiple QUICs save round-trip time and will greatly improve connection settings.

[0028] The entire encrypted transport layer does not rely on "TCP & TLS", thus enhancing QUIC's security. The entire encrypted transport layer therefore prevents transparent traffic modification by attackers in the middle of the network, ultimately eliminating attacks provided by TCP.

[0029] Figure 3 is a schematic diagram of the QUIC communication process in this embodiment.

[0030] Typically, a Handshake process occurs during the initial QUIC connection, but unlike the existing "TCP & TLS" Handshake, the number of round trips is significantly reduced, and the process becomes faster.

[0031] When the connection is started, the HTTP / 3 client transmits a QUIC Initial data packet including a TLS 1.3 ClientHello message to the HTTP / 3 server (S310).

[0032] When the server agrees to the attached parameters, the HTTP / 3 server responds to the HTTP / 3 client with a QUIC Initial data packet including a TLS ServerHello message (S320).

[0033] After the HTTP / 3 server transmits the QUIC Initial data packet to the HTTP / 3 client, it then transmits the QUIC Handshake data packet to the HTTP / 3 client (S330). In step S330, the HTTP / 3 server continuously transmits the Handshake data packet, which is the TLS ServerHello message followed by other TLS server messages (server authentication related information).

[0034] The HTTP / 3 client transmits the QUIC Handshake to the HTTP / 3 server while ending the client's message (S340).

[0035] The HTTP / 3 client and HTTP / 3 server work together, based on a 1-RTT data packet exchange application (S350). 1-RTT (One Round-Trip Time) is a conventional communication method, including the following steps: the client sends a request to the server, the server receives and processes the request, and then responds to the client again. This process consumes round-trip time. 0-RTT (Zero Round-Trip Time) is a technology to improve transmission speed. If the client has previously communicated with the server, it can cache previously exchanged information and reuse it. The client can send data to the server without attaching any additional information. The client can utilize information obtained from previous sessions, and the server can send data without waiting for a response; therefore, the RTT is reduced to 0. This shortens transmission time and improves webpage download speed, etc.

[0036] The three steps corresponding to different data packet types in QUIC (Initial, Handshake, 1-RTT) are equivalent to the three encryption steps (Cleartext messages, Protection using Handshake secrets, Protection using Traffic secrets) used in TLS 1.3. TLS 1.3 typically encrypts all content after the Hello message, but in order to hide it from intermediate devices in the network path, the QUIC protocol also encrypts the Hello message.

[0037] All QUIC data packets consist of two parts: a header and a payload (encrypted TLS data). From a QUIC-level encryption perspective, the two parts of the QUIC data packet, namely the header and the payload, are encrypted using different methods to generate a QUIC data packet that is completely encrypted by overlapping the two parts.

[0038] Figure 4 is a schematic flowchart of the method for masking traffic based on functional variable name in the in-band network described in this embodiment.

[0039] In an out-of-band network environment, the traffic masking device 130 receives QUIC data packets from the HTTP / 3 server (S410).

[0040] After confirming that the QUIC data packet is a QUIC Client Initial data packet, the traffic masking device 130 generates the decoding result of the decoding (S420).

[0041] The traffic masking device 130 confirms whether the decoding of the initial data packet of the QUIC client was successful based on the decoding result (S430).

[0042] In step S430, when the QUIC client initial data packet is successfully decoded, the traffic masking device 130 confirms the TLS client greeting (TLS Client Hello) message based on the decoding result, and then performs SNI (Server Name Indication) parsing to generate the SNI parsing result (S440).

[0043] Confirming the result of S430, when the decoding of the QUIC client initial data packet fails, the traffic masking device 130 identifies the function variable name corresponding to the QUIC client initial data packet as a function variable name that is not related to the function variable name of the masking object, and transmits the QUIC client initial data packet to the server (S492).

[0044] The traffic masking device 130 confirms whether the SNI parsing of the TLS client greeting message is successful based on the SNI parsing result (S450).

[0045] In step S450, when the SNI of the TLS client greeting message is successfully parsed, the traffic masking device 130 confirms whether the SNI parsing result is the masking object SNI (S460).

[0046] Confirming the result of S450, when the SNI parsing of the TLS client greeting message fails, the traffic masking device 130 identifies the functional variable name corresponding to the TLS client greeting message as a functional variable name that is not related to the functional variable name of the masking object, and transmits the QUIC client initial data packet to the server (S492).

[0047] According to the confirmation result of step S460, when the SNI parsing result is confirmed to be the masking object SNI, the traffic masking device 130 generates a fake QUIC server initial data packet.

[0048] According to the confirmation result of step S460, if the SNI parsing result is not confirmed as the masking object SNI, the QUIC client initial data packet is transmitted to the server (S492).

[0049] The traffic masking device 130 transmits the pseudo-QUIC server initial data packet to the HTTP / 3 client, masking the traffic based on the function variable name (S480). The traffic masking device 130 discards the QUIC data packet received from the mirroring device 120 (S490).

[0050] Figure 4 shows the flow of steps S410 to S492 being implemented sequentially, but it is not necessarily limited to this. In other words, the following methods can be applied: the steps shown in Figure 4 can be changed and implemented or more than one step can be implemented in parallel. Therefore, Figure 4 is not limited to the time sequence.

[0051] As described above, as shown in FIG4, in the in-band network of this embodiment, the method for masking traffic based on functional variable name can be implemented by a program and recorded in a computer-readable recording medium. In the in-band network of this embodiment, the recording medium records a program for implementing the method for masking traffic based on functional variable name and can be read by a computer, and includes all types of recording devices for storing computer system readable data.

[0052] Figure 5 is a view of the system receiving data packets based on the functional variable name masking traffic in the in-band network described in this embodiment.

[0053] As shown in Figure 5, one of the HTTP / 3 clients 112 attempts to access the masked object website, namely, one of the HTTP / 3 servers 142.

[0054] One of the HTTP / 3 clients 112 transmits the QUIC Client Initial data packet to one of the HTTP / 3 servers 142. The traffic masking device 130 receives the QUIC Client Initial data packet.

[0055] Figure 6 is a view of the QUIC Client Initial data packet before decoding in this embodiment.

[0056] The traffic masking device 130 receives the initial data packet from the QUIC client. The initial data packet from the QUIC client before decoding is shown in Figure 6.

[0057] Figure 7 is a schematic flowchart of the method for confirming and decoding the initial data packet of the QUIC client in this embodiment.

[0058] The traffic masking device 130 confirms whether the QUIC client initial data packet of the QUIC data packet is a User Datagram Protocol (UDP), and generates a payload parsing result (S710) to parse the payload.

[0059] The traffic masking device 130 confirms whether the parsing of the initial data packet of the QUIC client is successful based on the payload parsing result (S712).

[0060] According to the confirmation result of step S712, when the parsing of the QUIC client initial data packet is successful, the traffic masking device 130 analyzes the payload based on the payload parsing result to confirm whether it is the QUIC initial message (S714).

[0061] According to the confirmation result of step S714, when it is confirmed to be a QUIC initial message, the traffic masking device 130 parses the version and destination connection ID from the QUIC Client Initial Header (S716).

[0062] The flow masking device 130 obtains the initial salt value using the version (S718).

[0063] The flow masking device 130 generates an initial secret using the initial salt value and the destination connection ID (S720).

[0064] The traffic masking device 130 generates a client initial secret (S722) using the initial secret and the client in label.

[0065] The traffic masking device 130 generates a key using the Client Initial Secret and the QUIC key label (S724).

[0066] The traffic masking device 130 uses the Client Initial Secret and the "QUIC Initialization Vector Label" to generate a Previous IV (Initialization Vector) (S726).

[0067] The traffic masking device 130 uses the Client Initial Secret and the "QUIC Header Protection Label" to generate a Header Protection Key (S728).

[0068] The traffic masking device 130 parses the sample payload from the QUIC Client Initial Payload (S730).

[0069] The flow masking device 130 generates a mask using the sample payload and the header protection key (S732).

[0070] The traffic masking device 130 uses a mask to decode the packet number length of the QUIC Client Initial Header (S736).

[0071] The traffic masking device 130 uses the mask and the packet number length to decode the packet number of the QUIC Client Initial Header (S736).

[0072] The flow masking device 130 generates an initialization vector (IV) using the previous initialization vector (Previous IV) and the data packet number (Packet Number) (S738).

[0073] The traffic masking device 130 parses the authentication tag from the QUIC Client Initial Payload (S740). In step S740, the traffic masking device 130 may optionally omit the authentication tag parsing process.

[0074] The traffic masking device 130 uses the key, initialization vector (IV), and authentication tag to decode the QUIC Client Initial Payload and authenticate the QUIC Client Initial Header (S750). In step S750, the traffic masking device 130 may optionally omit the authentication process of the QUIC Client Initial Header.

[0075] Figure 7 shows the sequential implementation of steps S710 to S750, but it is not necessarily limited to this. In other words, the following methods can be applied: modifying the steps shown in Figure 7 and implementing them, or implementing one or more steps in parallel. Therefore, Figure 7 is not limited to the timing sequence.

[0076] As described above, as shown in FIG7, the QUIC client initial data packet confirmation and decoding method of this embodiment can be implemented by a program and recorded in a computer-readable recording medium. The recording medium contains a program for implementing the QUIC client initial data packet confirmation and decoding method of this embodiment and can be read by a computer, including all types of recording devices for storing computer system readable data.

[0077] Figure 8 is a view of the initial data packet of the QUIC client after decoding in this embodiment.

[0078] The QUIC client initial data packet decoded after confirmation by the traffic masking device 130 is shown in Figure 8.

[0079] Figure 9 is a schematic flowchart of the implementation of the SNI (Server Name Indication) resolution method after confirming the TLS Client Hello message in this embodiment.

[0080] Based on the decoding result of decoding the QUIC Client Initial data packet, the traffic masking device 130 confirms the TLS Client Hello message, performs SNI (Server Name Indication) resolution, and generates SNI resolution result.

[0081] The QUIC Client Initial Payload consists of multiple frames. A CRYPTO frame can be segmented and transmitted on more than one QUIC initial message. CRYPTO data can be segmented and transmitted on more than one CRYPTO frame. In other words, CRYPTO data can be segmented and transmitted on more than one data packet, and should be configured on the receiving server.

[0082] The flow masking device 130 queries the stored CRYPTO data in the cache memory (S910). In step S910, the flow masking device 130 may optionally omit the CRYPTO data query process.

[0083] In step S910, the source IP address, source port, destination IP address, destination port, source connection ID, and destination connection ID can be used as the key for querying CRYPTO data.

[0084] The flow masking device 130 confirms the CRYPTO framework from the QUIC Client Initial Payload, parses the data, and then generates the assembly result of the assembly (S920).

[0085] After analyzing the CRYPTO frame based on the assembly results, the flow shielding device 130 confirms whether the assembly is successful (S930).

[0086] According to the confirmation result of step S930, when the assembly fails after parsing the CRYPTO frame, the flow masking device 130 stores the CRYPTO data in the cache memory (S940). In step S940, the flow masking device 130 may optionally omit the process of storing the CRYPTO data in the cache memory.

[0087] According to the confirmation result of step S930, when the CRYPTO framework is successfully assembled after parsing, the traffic masking device 130 confirms the TLS Client Hello message from the CRYPTO data based on the assembly result and generates the parsing result of the SNI (Server Name Indication) (S950).

[0088] The traffic masking device 130 confirms whether the parsing of the SNI (Server Name Indication) of the TLS Client Hello message was successful (S960).

[0089] According to the confirmation result of step S960, when the SNI (Server Name Indication) of the TLS Client Hello message is successfully parsed, the traffic masking device 130 terminates the SNI parsing.

[0090] According to the confirmation result of step S960, when the parsing of the SNI (Server Name Indication) of the TLS Client Hello message fails, the traffic masking device 130 returns to step S920.

[0091] Figure 9 shows the sequential implementation of steps S910 to S960, but it is not necessarily limited to this. In other words, the following methods can be applied: modifying the steps shown in Figure 9 and implementing them, or implementing one or more steps in parallel. Therefore, Figure 9 is not limited to the timing sequence.

[0092] As described above, as shown in FIG9, the TLS client greeting message acknowledgment and SNI parsing method described in this embodiment can be implemented by a program and recorded in a computer-readable recording medium. The recording medium contains a program for implementing the TLS client greeting message acknowledgment and SNI parsing method described in this embodiment and can be read by a computer, including all types of recording devices for storing computer system readable data.

[0093] Figure 10 is a view of the SNI parsing results of this embodiment.

[0094] When the traffic masking device 130 successfully parses the SNI (Server Name Indication) of the TLS Client Hello message, as shown in Figure 10.

[0095] Figure 11 is a schematic flowchart of the method for generating fake QUIC server initial data packets when the SNI parsing result is confirmed to be the mask object SNI in this embodiment.

[0096] When the SNI resolution result is confirmed to be the masked object SNI, the traffic masking device 130 generates a fake QUIC server initial data packet.

[0097] The traffic masking device 130 generates a connection termination frame (S1110) based on the content of the QUIC Server Initial Payload.

[0098] Traffic masking device 130 generates the packet number length (S1112) that will enter the QUIC Server Initial Header.

[0099] Traffic masking device 130 generates a packet number (S1114) that will enter the QUIC Server Initial Header.

[0100] The traffic masking device 130 generates a QUIC server initial header (S1116) using the version and source connection ID parsed from the QUIC client initial header.

[0101] The flow masking device 130 obtains the initial salt value (S1118) by using the version parsed from the QUIC Client Initial Header.

[0102] The flow masking device 130 generates an initial secret (S1120) by using the destination connection ID parsed from the initial salt value and the QUIC client initial header.

[0103] The traffic masking device 130 generates a server initial secret (S1122) using the initial secret and the server in label.

[0104] The traffic masking device 130 generates a key using the Server Initial Secret and the QUIC key label (S1124).

[0105] The traffic masking device 130 uses the Server Initial Secret and the QUIC Initialization Vector Label to generate a Previous IV (Initialization Vector) (S1126).

[0106] The traffic masking device 130 uses the Server Initial Secret and the QUIC header protection label to generate a header protection key (S1128).

[0107] The flow masking device 130 generates an initialization vector (IV) using the previous initialization vector (Previous IV) and the already generated data packet number (Packet Number) (S1130).

[0108] The traffic masking device 130 uses the key, the initialization vector (IV) and the generated QUIC server initial header to encrypt the QUIC server initial payload and generate an authentication tag (S1132).

[0109] The traffic masking device 130 parses the sample payload from the encrypted QUIC Server Initial Payload (S1134).

[0110] The flow masking device 130 generates a mask using the sample payload and the header protection key (S1136).

[0111] The traffic masking device 130 uses a mask to encrypt the packet number length of the QUIC Server Initial Header (S1138).

[0112] The traffic masking device 130 uses a mask to encrypt the packet number of the QUIC Server Initial Header (S1140).

[0113] The traffic masking device 130 sequentially attaches the encrypted QUIC Server Initial Header, Payload and Authentication Tag to generate a QUIC Server Initial message (S1142).

[0114] The traffic masking device 130 uses the source IP address, destination IP address, source port, destination port, and QUIC Server Initial message parsed from the IP header and UDP header of the received QUIC data packet to generate a fake QUIC Server Initial data packet (S1144).

[0115] Figure 11 shows the sequential implementation of steps S1110 to S1144, but it is not necessarily limited to this. In other words, the following methods can be applied: modifying the steps shown in Figure 11 and implementing them, or implementing one or more steps in parallel. Therefore, Figure 11 is not limited to the timing sequence.

[0116] As described above, as shown in FIG11, when the SNI parsing result described in this embodiment is confirmed to be a masking object SNI, the method for generating the pseudo-QUIC server initial data packet can be implemented by a program and recorded in a computer-readable recording medium. When the SNI parsing result described in this embodiment is confirmed to be a masking object SNI, the recording medium contains a program for implementing the pseudo-QUIC server initial data packet generation method and can be read by a computer, including all types of recording devices for storing computer system readable data.

[0117] Figure 12 is a view of the initial data packet of the QUIC server before encryption in this embodiment.

[0118] The traffic masking device 130 encrypts the QUIC server initial data packet before the QUIC server initial header and QUIC server initial payload, as shown in Figure 12.

[0119] Figure 13 is a view of the encrypted QUIC server initial data packet in this embodiment.

[0120] After the traffic masking device 130 encrypts the QUIC Server Initial Header and the QUIC Server Initial Payload, the QUIC Server Initial Data Packet is shown in Figure 13.

[0121] Figure 14 is a view of the system transmission of QUIC server initial data packets in the out-of-band network described in this embodiment, based on the functional variable name masking traffic.

[0122] The traffic masking device 130 transmits the generated fake QUIC server initial data packet to one of the HTTP / 3 clients 112, masking the connection between one of the HTTP / 3 clients 112 and one of the HTTP / 3 servers 142 identified as the masking target website.

[0123] Figure 15 is a working view of the in-band network described in this embodiment when the system decoding of the traffic based on the functional variable name fails, the SNI parsing fails, or the SNI is not identified as a masking object.

[0124] When the decoding of the QUIC client initial data packet fails, the traffic masking device 130 identifies the function variable name corresponding to the QUIC client initial data packet as a function variable name that is not related to the function variable name of the masking object, and transmits the QUIC client initial data packet to the second HTTP / 3 server 144.

[0125] When the SNI parsing of the TLS client greeting message fails, the traffic masking device 130 identifies the functional variable name corresponding to the TLS client greeting message as a functional variable name that is not related to the functional variable name of the masking object, and transmits the QUIC client initial data packet to the HTTP / 3 server 144.

[0126] When the SNI resolution result is not confirmed to be the masking object SNI, the traffic masking device 130 transmits the QUIC client initial data packet to the HTTP / 3 server 144.

[0127] The above description merely illustrates the technical concept of this embodiment. Those skilled in the art to which this embodiment pertains can make various modifications and variations without departing from the essential characteristics of this embodiment. Therefore, this embodiment is not intended to limit the technical concept of this embodiment, but rather to describe it. The scope of the technical concept of this embodiment is not limited by this embodiment. The protection scope of this embodiment should be interpreted in accordance with the scope of the appended claims, and it should be interpreted that all technical concepts within the same scope are included in the scope of the claims of this embodiment. [Simplified Explanation of the Diagram]

[0011] Figure 1 is a system view of traffic based on functional variable name masking in the in-band network described in this embodiment. Figure 2 is a schematic diagram of the QUIC protocol in this embodiment. Figure 3 is a schematic diagram of the QUIC communication process in this embodiment. Figure 4 is a schematic flowchart of the method for traffic based on functional variable name masking in the in-band network described in this embodiment. Figure 5 is a view of the system receiving data packets based on functional variable name masking traffic in the in-band network described in this embodiment. Figure 6 is a view of the QUIC client initial data packet before decoding in this embodiment. Figure 7 is a schematic flowchart of the confirmation and decoding method of the QUIC client initial data packet in this embodiment. Figure 8 is a view of the QUIC client initial data packet after decoding in this embodiment. Figure 9 is a schematic flowchart of the implementation of the SNI (Server Name Indication) resolution method after confirming the TLS client Hello message in this embodiment. Figure 10 is a view of the SNI resolution result in this embodiment. Figure 11 is a schematic flowchart of the method for generating fake QUIC server initial data packets when the SNI parsing result is confirmed to be the masking object SNI in this embodiment. Figure 12 is a view of the QUIC server initial data packet before encryption in this embodiment. Figure 13 is a view of the QUIC server initial data packet after encryption in this embodiment. Figure 14 is a view of the system transmission of fake QUIC server initial data packets based on functional variable name masking traffic in the in-band network described in this embodiment. Figure 15 is a working view when the system decoding fails, SNI parsing fails, or the masking object SNI is not confirmed in the in-band network described in this embodiment.

Claims

1. A method for name masking traffic based on functional variables in an intranet, wherein, Includes the following steps: In an inline network environment, QUIC data packets received from the client; After confirming that the QUIC data packet is a QUIC Client Initial data packet, a decoding result is generated. Based on the decoding result, it is confirmed whether the decoding of the QUIC Client Initial data packet was successful. If the decoding of the QUIC Client Initial data packet is successful according to the confirmation result, after confirming the TLS Client Hello message based on the decoding result, SNI (Server Name Indication) resolution is performed, and an SNI resolution result is generated. Based on the SNI resolution result, it is confirmed whether the SNI resolution of the TLS Client Hello message was successful. According to the confirmation result, when the SNI of the TLS client greeting message is successfully parsed, it is confirmed whether the SNI parsing result is the masking object SNI; Based on the confirmation results, when the SNI parsing result is confirmed to be the masked object SNI, a fake QUIC server initial data packet is selectively generated; The initial data packets of the pseudo-QUIC server are selectively transmitted to the client, and traffic is masked based on the functional variable name. The process includes discarding the QUIC data packets received from the client; wherein the step of selectively generating a pseudo QUIC server initial data packet includes: generating a connection termination frame (CONNECTION_CLOSE Frame) with the content of the QUIC server initial payload, and generating a packet number length and a packet number to be included in the QUIC server initial header; generating multiple encryption keys for encryption; encrypting the QUIC server initial payload using the multiple encryption keys to generate an authentication tag; encrypting the packet number length and the packet number in the QUIC server initial header to obtain an encryption result; and generating the pseudo QUIC server initial data packet using the encryption result.

2. The method for masking traffic based on the functional variable name in an in-band network as described in request item 1, wherein, According to the confirmation results, when the decoding of the QUIC client initial data packet fails, the function variable name corresponding to the QUIC client initial data packet is identified as a function variable name that is not related to the function variable name of the masking object, and the QUIC client initial data packet is transmitted to the server.

3. The method for masking traffic based on the functional variable name in an in-band network as described in request item 1, wherein, According to the confirmation results, when the SNI parsing of the TLS client greeting message fails, the functional variable name corresponding to the TLS client greeting message is identified as a functional variable name that is not related to the functional variable name of the masking object, and the QUIC client initial data packet is transmitted to the server.

4. The method for masking traffic based on the functional variable name in an in-band network as described in request item 1, wherein, If the SNI parsing result is not confirmed to be the SNI of the masking object, the initial data packet of the QUIC client is transmitted to the server.

5. The method for masking traffic based on the functional variable name in an in-band network as described in request item 1, wherein, The decoding process of the initial data packet of the QUIC client includes the following steps: Confirm that the initial data packet of the QUIC client is UDP, and generate the payload parsing result. Based on the payload parsing results, multiple decoding keys are generated for decoding; the QUIC client initial data packet is decoded using the multiple decoding keys; and the QUIC client initial data packet is selectively authenticated using the multiple decoding keys.

6. The method for masking traffic based on the functional variable name in an in-band network as described in request item 5, wherein, The process of generating multiple keys for decoding based on the payload parsing results includes the following steps: When the payload is analyzed based on the payload parsing results and confirmed to be a QUIC initial message, the version and destination connection ID are parsed from the QUIC Client Initial Header; the initial salt is obtained using the version; the initial secret is generated using the initial salt and the destination connection ID; the client initial secret is generated using the initial secret and the client in label; the key is generated using the client initial secret and the QUIC key label; the previous initialization vector is generated using the client initial secret and the QUIC initialization vector label; and the header protection key is generated using the client initial secret and the QUIC header protection label.

7. The method for masking traffic based on the functional variable name in an in-band network as described in request item 6, wherein, The process of decoding the QUIC client initial data packet using the multiple keys includes the following steps: parsing the sample payload from the QUIC client initial payload; generating a mask using the sample payload and the header protection key; decoding the packet number length of the QUIC client initial header using the mask; decoding the packet number of the QUIC client initial header using the mask and the packet number length; generating an initialization vector (IV) using the prior initialization vector and the packet number; and decoding the QUIC client initial payload using the keys and the initialization vector (IV).

8. The method for name masking traffic based on functional variable in an in-band network as described in request item 7, wherein, The process of selectively authenticating the initial data packet of the QUIC client using multiple keys includes the following steps: The authentication tag is selectively parsed from the QUIC client initial payload; and the QUIC client initial payload is decoded using the key, the initialization vector (IV), and the authentication tag, and the QUIC client initial header is selectively authenticated.

9. A method for masking traffic based on the functional variable name in an in-band network as described in request item 1, wherein, The process of performing SNI parsing on the TLS client greeting message includes the following steps: querying the CRYPTO data already stored in the cache memory; confirming the CRYPTO framework from the QUIC Client Initial Payload, parsing the data, and generating the assembly result; and based on the assembly result, confirming the TLS client greeting message from the CRYPTO data and generating the parsing result of the SNI (Server Name Indication).

10. A method for masking traffic based on the functional variable name in an in-band network as described in request item 1, wherein, The process of generating the multiple encryption keys for encryption includes the following steps: generating the QUIC server initial header using the version and source connection ID parsed from the QUIC client initial header; obtaining the initial salt using the version parsed from the QUIC client initial header; generating the initial secret using the initial salt and the target connection ID parsed from the QUIC client initial header; generating the server initial secret using the initial secret and the server in label; generating the key using the server initial secret and the QUIC key label; generating the previous initialization vector using the server initial secret and the QUIC initialization vector label; and generating the header protection key using the server initial secret and the QUIC header protection label.

11. A method for masking traffic based on the functional variable name in an in-band network as described in request item 10, wherein, The process of encrypting the initial payload of the QUIC server and generating an authentication tag using the multiple encryption keys includes the following steps: generating an initialization vector (IV) using the prior initialization vector and the data packet number; and encrypting the initial payload of the QUIC server using the keys, the initialization vector (IV), and the initial header of the QUIC server to generate an authentication tag.

12. The method for masking traffic based on the functional variable name in an in-band network as described in request item 11, wherein, The process of encrypting the data packet number length of the QUIC server initial header and generating the encryption result of the data packet number includes the following steps: parsing the sample payload from the encrypted QUIC server initial payload; generating a mask using the sample payload and the header protection key; encrypting the data packet number length of the QUIC server initial header using the mask; and encrypting the data packet number of the QUIC server initial header using the mask.

13. The method for masking traffic based on the functional variable name in an in-band network as described in request item 12, wherein, The process of generating the pseudo QUIC server initial data packet using the encryption result includes the following steps: sequentially pasting the encrypted QUIC server initial header, payload, and authentication tag to generate a QUIC server initial message; and using the source IP address, destination IP address, source port, destination port, and QUIC server initial message parsed from the IP header and UDP header of the received QUIC data packet to generate the pseudo QUIC server initial data packet.

Images