A quic-based software-defined perimeter method and system

Abstract

The application discloses a software defined border method and system based on QUIC, and realizes the combination of SPA and handshake packet by improving the QUIC protocol, integrating the SPA knocking process in the SPA in the SDP into the QUIC handshake packet information, reducing the network establishment delay, and solving the negotiation problem of the SPA knocking success and the service start; secondly, the original physical firewall concept is extended, and the firewall is placed behind the AH service side, realizing the all-round protection of the network layer (QUIC protocol and authentication information) and the application layer (single service permission), and improving the service management accuracy; finally, the application saves unnecessary extension equipment, saves physical resources, and also simplifies the deployment difficulty, and is easy to modernize large systems.

Description

Technical Field

[0001] This invention relates to the field of data transmission security technology, and specifically to a software-defined boundary method and system based on QUIC. Background Technology

[0002] The concept of Zero Trust was first proposed by John Kindervag of Forrester Research. Its core idea is "never trust, always verify," meaning that by default, anyone, anything, or any entity inside or outside the enterprise is untrustworthy. Any person, thing, or entity attempting to access the network or network resources should be verified before authorization. The three main technologies of Zero Trust architecture (ZTA) are: SDP (Software Defined Perimeter), IAM (Identity and Access Management), and MSG (Micro-Segmentation).

[0003] The SDP Standard Specification 1.0 was released in 2013. The security philosophy of SDP is: (1) to ensure that all resource access is secure regardless of the location of users and server resources; (2) to record and inspect all traffic; and (3) to implement the Need-to-Know principle for all authorizations. At the same time, SDP also innovatively proposed the security concept of network hiding. For traditional security concepts, resources exposed on the public Internet need to withstand attacks from all sides 24 / 7. With the rapid iteration of hacker technology and the emergence of software and hardware vulnerabilities, it is impossible to defend against them all. Therefore, security protection in the digital age should change its concept, and the defender should shift from strict defense to active hiding of "hiding traces". For unauthorized connections, by hiding the access port, all unauthorized data packets are dropped by default, and the target cannot be detected by attack technology. The security concept of network hiding is more in line with the application scenarios of the data age.

[0004] SDP provides security protection for the OSI model, enabling asset hiding and establishing a trusted connection between the data plane and the control plane using the Single Packet Authorization (SPA) protocol before allowing access to hidden resources. The specific process is as follows:

[0005] (1) Separate the control plane for establishing trust from the data plane for transmitting actual data;

[0006] (2) Use the Deny-All firewall to hide service resources, drop all unauthorized packets and use them for logging and traffic analysis;

[0007] (3) Before accessing protected resources, authenticate and authorize users and devices through the Single Package Authorization (SPA) protocol.

[0008] The SDP core consists of three parts: the SDP client (Inception Host, IH), the SDP controller, and the SDP accept host (Accept Host, AH), as detailed below. Figure 1 As shown.

[0009] SDP's security advantages are:

[0010] (1) SDP minimizes the attack surface and reduces security risks;

[0011] (2) SDP protects critical assets and infrastructure by separating access control and data channels, thereby preventing potential network-based attacks;

[0012] (3) SDP provides an integrated security architecture that is difficult to achieve with existing security devices;

[0013] (4) SDP provides a connection-based security architecture rather than an IP-based alternative;

[0014] (5) SDP allows for pre-checking and control of all connections, verifying that these connections can connect devices, services and facilities, thus its overall security is more advantageous than traditional architectures.

[0015] HTTP / 3 (Hypertext Transfer Protocol Version 3) is a new, next-generation Internet transport protocol. It is the latest version of HTTP that has been developed and released. It uses advanced UDP (User Datagram Protocol) technology to solve the performance problems of HTTP / 2.0 in certain situations.

[0016] QUIC (Quick UDP Internet Connections) is a UDP-based protocol that leverages the speed and efficiency of UDP while integrating and optimizing the advantages of TCP, TLS, and HTTP / 2. Figure 2 This demonstrates the relationship between QUIC and HTTP / 2.

[0017] QUIC is a transport layer protocol designed to replace TCP and SSL / TLS. Above the transport layer is the application layer. Currently well-known application layer protocols include HTTP, FTP, and IMAP. Theoretically, these protocols can all run on QUIC. The HTTP protocol running on top of QUIC is called HTTP / 3, which is the meaning of HTTP over QUIC, or HTTP / 3.

[0018] A QUIC data packet has the following format: Figure 3As shown, it consists of two parts: header and data. The header is in plaintext and contains four fields: Flags, Connection ID, QUIC version, and Packet Number. The data is encrypted and can contain one or more frames. Each frame is further divided into type and payload, where the payload is the application data.

[0019] HTTP / 2 connection establishment requires 3 RTTs. If session reuse is considered (i.e., caching the symmetric key calculated during the initial handshake), it still requires 2 RTTs. Furthermore, if TLS is upgraded to 1.3, the HTTP / 2 connection requires 2 RTTs, and considering session reuse, it requires 1 RTT. If HTTP / 2 were not based on HTTPS, it could be simplified, but in reality, almost all browsers are designed to require HTTP / 2 to be based on HTTPS. HTTP / 3 requires only 1 RTT for the initial connection, and subsequent connections require only 0 RTTs, meaning that the first packet sent by the client to the server contains the request data.

[0020] TCP connections are based on a four-tuple (source IP, source port, destination IP, destination port). When switching networks, at least one of these factors will change, causing the connection to be re-established. If the original TCP connection is used when the connection changes, the connection will fail, and the connection will have to be re-established after the original connection times out. QUIC is not affected by the four-tuple; when these four elements change, the original connection is maintained. This is because QUIC does not use a four-tuple representation but instead uses a 64-bit random number called the Connection ID. Even if the IP or port changes, as long as the Connection ID remains unchanged, the connection can still be maintained.

[0021] If a TCP connection transmits 10 requests simultaneously, and the first request is received by the client, but the fourth request is lost, then requests 5 through 10 will be blocked. They can only be processed after the fourth request is completed, thus wasting bandwidth. HTTP / 2 multiplexing breaks each request into multiple frames, which are transmitted simultaneously through a single TCP connection. This way, even if one request is blocked, it won't affect other requests. However, the underlying TCP protocol of HTTP / 2 itself has a head-of-line blocking problem. Each HTTP / 2 request is broken into multiple frames, and frames from different requests are combined into a stream. A stream is a logical transmission unit on TCP. This allows HTTP / 2 to send multiple requests simultaneously over a single connection. If Frame 1 has been correctly delivered, but the third frame in Frame 2 is lost, TCP processes data in a strict order; the first frame sent must be processed first. This requires the sender to resend the third frame. Frames 3 and 4, although arrived, cannot be processed, causing the entire link to be blocked. Furthermore, because HTTP / 2 requires HTTPS, and HTTPS uses the TLS protocol, it also suffers from head-of-line blocking. QUIC uses packets as its transmission and encryption units. The entire encryption, transmission, and decryption process is based on packets, thus avoiding the blocking issues of TLS. QUIC is based on UDP, and UDP packets are processed in no particular order at the receiving end. Even if a packet is lost, it will not block the entire connection, and other resources will be processed normally.

[0022] TCP's congestion control mechanism is rigid; every time congestion is detected, TCP reduces the congestion window size by half. In contrast, QUIC's congestion control is designed to be more flexible, allowing for more efficient use of available network bandwidth and thus achieving better throughput.

[0023] Traditional SDP security policies all provide a trusted SDP policy management center. IH client components must first send SPA knock-on authentication packets directly or indirectly (through a firewall) to the SDP policy management center. Due to the nature of SPA policies (sending UDP packets with no return status), the IH client components cannot know whether the SPA knock-on was successfully sent or whether the SDP policy management center has authorized the user. Currently, most technologies use mass sending of SPA authentication packets to avoid packet loss, but this still cannot solve the problem of unsuccessful SDP policy center authentication. The default assumption is that as long as the SPA knock-on packet is reachable, authentication is successful, which is obviously not absolute in specific business scenarios. Moreover, a large number of SPA authentication packets also significantly consumes precious control plane network resources.

[0024] Furthermore, traditional SDP firewalls are typically deployed between the IH client component and the AH server, with the SDP policy management center serving as a bypass device deployed next to the SDP firewall. SDP firewall policies are directly managed by the policy management center. This layout has a fatal flaw: access control services can only protect the firewall to the south (outside the server side), providing only IP:PORT level protection and lacking micro-segmentation and application-level protection, resulting in insufficient granularity. Summary of the Invention

[0025] In view of the shortcomings of the existing technology, the present invention aims to provide a software-defined boundary method and system based on QUIC.

[0026] To achieve the above objectives, the present invention adopts the following technical solution:

[0027] A software-defined boundary method based on QUIC, the specific process of which is as follows:

[0028] (1) The IH client component requests identity credentials from the identity security infrastructure. After verifying the legitimacy of the client device, the identity security infrastructure issues identity credentials. The IH client component then downloads the identity credentials to the certificate module of the IH client component.

[0029] (2) The IH client component encrypts and signs the client device information, user identity information and application identifier to form an authorization package;

[0030] (3) When the IH client component needs to send a QUIC handshake connection packet to the target AH service, after encapsulating the request data in UDP, the authorization packet and packet identifier are encapsulated in the outer layer of UDP, and then other QUIC encapsulation operations are performed to form a QUIC handshake connection packet.

[0031] (4) The AH trusted proxy on the target AH service side intercepts the QUIC handshake connection packet, first parses the protocol, and determines whether it is QUIC. If it is, proceed to the next step; otherwise, discard it directly.

[0032] (5) The AH trusted proxy determines whether the QUIC handshake connection packet carries an authorization packet. If not, the QUIC handshake connection packet is discarded directly; otherwise, the process proceeds to the next step.

[0033] (6) The AH trusted proxy requests the identity security infrastructure to check the legitimacy of the client device information in the authorization packet. If it is legitimate, proceed to the next step of processing; otherwise, discard the QUIC handshake connection packet directly.

[0034] (7) The AH trusted proxy requests the identity security infrastructure to verify whether the IH client component has access to the service. If it does, proceed to the next step; otherwise, discard the QUIC handshake connection packet.

[0035] (8) The AH trusted proxy requests the target AH service to verify whether the IH client component has access to the resource. If it does, proceed to the next step; otherwise, discard the QUIC handshake connection packet.

[0036] (9) The AH trusted proxy allows the QUIC handshake connection packet to the target AH service;

[0037] (10) The target AH service opens the border firewall control port, establishes a handshake connection, and returns a handshake success message to the IH client component;

[0038] (11) The IH client component begins sending business data to the AH service.

[0039] Furthermore, in step (2), the information of the client device includes the IMEI number of the client device.

[0040] The present invention also provides a QUIC-based software-defined boundary system for implementing the above method, including an IH client component, an AH trusted proxy, and an AH service component;

[0041] The IH client component is a software or hardware component installed on the client device. It has a certificate module and a data encapsulation module based on an HTTP3 client. The certificate module is used to store the identity credentials requested by the IH client component from the identity security infrastructure. The data encapsulation module integrates an improved HTTP3 client. The improved HTTP3 client inserts a separate authorization packet layer below the original multiplexing, secure transport layer protocol, congestion control, and loss recovery of the QUIC protocol. When the IH client component needs to send a QUIC handshake connection packet to the AH service component, the data encapsulation module encapsulates the authorization packet and packet identifier in the outer layer of UDP after encapsulating the request data, and then performs other QUIC encapsulation operations to form a QUIC handshake connection packet, realizing the combination of handshake packet and SPA authorization authentication.

[0042] The AH trusted proxy is used to verify the QUIC handshake connection packet according to steps (4)-(8) in the method of Example 1, and allows it to be passed to the target AH service after successful verification.

[0043] Furthermore, the authorization packet occupies 1-6 bytes at the end of the QUIC handshake connection packet header. When the AH trusted proxy receives the QUIC handshake connection packet, it can extract and parse the authorization packet in the header file for authentication without performing data parsing.

[0044] Furthermore, the IH client component also includes a status detection module, which is used to monitor the update status of the client device certificate information, whether the user liveness detection is passed, the user operation log recording, and the detection and reporting of the client device network status.

[0045] The beneficial effects of this invention are as follows: First, by improving the QUIC protocol, this invention integrates the SPA knocking process in SDP into the QUIC handshake connection packet information, realizing the combination of SPA and handshake packet, reducing network establishment latency, and solving the negotiation problem between successful SPA knocking and service initiation. Second, this invention extends the original concept of physical firewall, placing the firewall behind the AH service side, realizing comprehensive protection at the network layer (QUIC protocol and authentication information) and application layer (individual service permissions), improving the granularity of server-side management. Finally, this invention eliminates unnecessary external devices, saves physical resources, simplifies deployment, and facilitates the modernization of large-scale systems. Attached Figure Description

[0046] Figure 1 This is a schematic diagram of the core SDP in the existing technology;

[0047] Figure 2 This is a diagram illustrating the relationship between QUIC and HTTP / 2.

[0048] Figure 3 This is a schematic diagram of the existing QUIC data packet format;

[0049] Figure 4 This is a schematic diagram of the system structure of Embodiment 2 of the present invention;

[0050] Figure 5 This is an improved QUIC protocol layer diagram according to Embodiment 2 of the present invention;

[0051] Figure 6 This is a diagram of the improved QUIC protocol structure according to Embodiment 2 of the present invention;

[0052] Figure 7 This is a timing diagram of the method in Embodiment 1 of the present invention;

[0053] Figure 8 This is a flowchart illustrating the implementation of Embodiment 3 of the present invention;

[0054] Figure 9 This is a flowchart illustrating the implementation of Embodiment 4 of the present invention. Detailed Implementation

[0055] The present invention will be further described below with reference to the accompanying drawings. It should be noted that this embodiment is based on the present technical solution and provides detailed implementation methods and specific operation processes, but the protection scope of the present invention is not limited to this embodiment.

[0056] Example 1

[0057] This embodiment provides a software-defined boundary method based on QUIC, such as... Figure 7 As shown, the specific process is as follows:

[0058] (1) The IH client component requests identity credentials (such as digital certificates) from the identity security infrastructure. After verifying the legitimacy of the client device, the identity security infrastructure issues identity credentials. The IH client component then downloads the identity credentials to the certificate module of the IH client component.

[0059] (2) The IH client component encrypts and signs the client device information (such as the client device's IMEI number), the user's identity information, application identifiers, etc., to form an authorization package;

[0060] (3) When the IH client component needs to send a QUIC handshake connection packet to the target AH service, after encapsulating the request data in UDP, the authorization packet and packet identifier are encapsulated in the outer layer of UDP, and then other encapsulation operations of QUIC are performed (such as loss recovery, congestion control, secure transport layer protocol and multiplexing functions of TCP) to form a QUIC handshake connection packet.

[0061] (4) The AH trusted proxy on the target AH service side intercepts the QUIC handshake connection packet (i.e., the QUIC handshake request carrying the authorization packet), first parses the protocol, and determines whether it is QUIC. If it is, proceed to the next step; otherwise, discard it directly.

[0062] (5) The AH trusted proxy determines whether the QUIC handshake connection packet carries an authorization packet. If not, the QUIC handshake connection packet is discarded directly; otherwise, the process proceeds to the next step.

[0063] (6) The AH trusted proxy requests the identity security infrastructure to check the legitimacy of the client device information in the authorization packet. If it is legitimate, proceed to the next step of processing; otherwise, discard the QUIC handshake connection packet directly.

[0064] (7) The AH trusted proxy requests the identity security infrastructure to verify whether the IH client component has access to the service. If it does, proceed to the next step; otherwise, discard the QUIC handshake connection packet.

[0065] (8) The AH trusted proxy requests the target AH service to verify whether the IH client component has access to the resource. If it does, proceed to the next step; otherwise, discard the QUIC handshake connection packet.

[0066] (9) The AH trusted proxy allows the QUIC handshake connection packet to the target AH service;

[0067] (10) The target AH service opens the border firewall control port, establishes a handshake connection, and returns a handshake success message to the IH client component;

[0068] (11) The IH client component begins sending business data to the AH service.

[0069] Example 2

[0070] This embodiment provides a QUIC-based software-defined boundary system that implements the method of Embodiment 1, including an IH client component, an AH trusted proxy, and an AH service component.

[0071] The IH client component is a software or hardware component installed on the client device, which includes a certificate module and a data encapsulation module based on the HTTP3 client, such as... Figure 4 As shown. The certificate module stores the identity credentials requested by the IH client component from the identity security infrastructure; the data encapsulation module integrates an improved HTTP3 client, such as... Figure 5 , 6 As shown, the improved HTTP3 client inserts a separate authorization packet layer below the original multiplexing, secure transport layer, congestion control, and loss recovery of the QUIC protocol. When the IH client component needs to send a QUIC handshake connection packet to the AH service component, the data encapsulation module encapsulates the request data into a UDP packet, then encapsulates the authorization packet and packet identifier in the outer UDP layer, and then performs other QUIC encapsulation operations to form a QUIC handshake connection packet, thus combining the handshake packet with SPA authorization authentication.

[0072] More specifically, such as Figure 5 As shown, without affecting other aspects of the original QUIC protocol, this embodiment inserts an authorization packet at the underlying layer of the QUIC protocol. For example... Figure 6 As shown, the authorization packet occupies 1-6 bytes at the end of the QUIC handshake connection packet header. When the AH trusted proxy (such as the firewall on the AH service component side) receives the QUIC handshake connection packet, it can extract and parse the authorization packet in the header file for authentication without performing data parsing.

[0073] The AH trusted proxy is used to verify the QUIC handshake connection packet according to steps (4)-(8) in the method of Example 1, and allows it to be passed to the target AH service after successful verification.

[0074] In this embodiment, the IH client component further includes a status detection module, which is used to monitor the update status of the client device certificate information, whether the user liveness detection is passed, the user operation log recording, and the detection and reporting of the client device network status.

[0075] Example 3

[0076] This embodiment provides an application example of the method described in Embodiment 1, such as... Figure 8 As shown.

[0077] 1) After the IH client component starts, it carries the client device's IMEI number, the user's ID card number, and mobile phone number to request a digital certificate from the cloud identity security infrastructure through VPN tunneling technology;

[0078] 2) The cloud-based identity security infrastructure distributes digital encryption / decryption certificates and signature verification certificates to the certificate module of the IH client component;

[0079] 3) The data encapsulation module of the IH client component uses a local digital certificate to encrypt information such as the client device's IMEI number, user's ID number, mobile phone number, application identifier, and requested resources, and digitally signs the encrypted information to form an authorization package;

[0080] 4) The data encapsulation module of the IH client component encapsulates the authorization packet on top of the UDP request data packet, which is located at the bottom layer of the QUIC protocol;

[0081] 5) The IH client component sends a handshake connection packet to the target server;

[0082] 6) The target server's firewall blocks the handshake connection packet;

[0083] 7) The firewall first determines whether the handshake connection packet is a QUIC protocol. If not, it discards it directly; otherwise, it proceeds to the next step.

[0084] 8) The firewall parses the QUIC protocol to see if it carries an authorization packet. If not, it discards the packet; otherwise, it proceeds to the next step.

[0085] 9) After the firewall obtains the authorization packet, it first verifies whether the authorization packet has been tampered with. If it has been tampered with, it is discarded directly; otherwise, it proceeds to the next step.

[0086] 10) Decrypt the authorization package data fields to perform authorization authentication:

[0087] i. The firewall first sends the decrypted client device IMEI number, user's mobile phone number, and application identifier to the cloud identity security infrastructure for verification of the legitimacy of the client device and service. If the verification fails, the handshake connection packet is discarded directly; otherwise, proceed to the next step.

[0088] ii. The firewall sends the user's ID number, application identifier, and resource request information to the target server to verify whether the requested permissions are compliant. If the verification fails, the handshake connection packet is discarded; otherwise, proceed to the next step.

[0089] 11) The firewall allows handshake connection packets to the target AH service;

[0090] 12) The target server returns a handshake success message to the IH client component;

[0091] 13) After receiving the handshake success message, the IH client component performs specific business operations.

[0092] Example 4

[0093] This embodiment provides another application example of the method described in Embodiment 1. For example... Figure 9 As shown.

[0094] 1) After the IH client component starts, it carries the client device's IMEI number, user ID number, and mobile phone number to request a digital certificate from the cloud identity security infrastructure through VPN tunneling technology;

[0095] 2) The cloud-based identity security infrastructure distributes digital encryption / decryption certificates and signature verification certificates to the certificate module of the IH client component;

[0096] 3) The data encapsulation module of the IH client component uses a local digital certificate to encrypt information such as the terminal IMEI number, user ID number, mobile phone number, service identifier, and applied resources, and digitally signs the encrypted information to form an authorization package;

[0097] 4) The data encapsulation module of the IH client component encapsulates the authorization packet on top of the UDP request data packet, which is located at the bottom layer of the QUIC protocol;

[0098] 5) The IH client component sends a handshake connection packet to the target server;

[0099] 6) The firewall on the target server side blocks the handshake connection packet;

[0100] 7) The firewall first checks whether the handshake connection packet is a QUIC protocol. If not, it discards it directly; otherwise, it proceeds to the next step.

[0101] 8) The firewall parses the QUIC protocol to see if it carries an authorization packet. If not, it discards the packet; otherwise, proceed to the next step.

[0102] 9) After the AH firewall obtains the authorization packet, it first verifies whether the authorization packet has been tampered with. If it has been tampered with, it is discarded directly; otherwise, it proceeds to the next step.

[0103] 10) Decrypt the authorization package data fields to perform permission authentication;

[0104] i. The firewall first sends the decrypted client device IMEI number, user's mobile phone number, and application identifier to the cloud identity security infrastructure for device and service legitimacy verification. If the verification fails, the handshake connection packet is discarded; otherwise, proceed to the next step.

[0105] ii. The firewall sends the user's ID number, application identifier, and resource request information to the target server to verify whether the requested permissions are compliant. If the verification fails, the handshake connection packet is discarded; otherwise, proceed to the next step.

[0106] 11) The firewall allows the handshake packet to reach the target server, and the target server generates a trusted token value;

[0107] 12) The target server returns a handshake success message carrying a trusted token value to the IH client component;

[0108] 13) After receiving the handshake success message, the IH client component sends the Token value along with the specific business data;

[0109] 14) The firewall continuously monitors whether business data packets carry a token value; otherwise, it discards them directly.

[0110] For those skilled in the art, various corresponding changes and modifications can be made based on the above technical solutions and concepts, and all such changes and modifications should be included within the protection scope of the claims of this invention.

Claims

1. A software-defined boundary method based on QUIC, characterized in that, The specific process is as follows: (1) The IH client component requests identity credentials from the identity security infrastructure. After verifying the legitimacy of the client device, the identity security infrastructure issues identity credentials. The IH client component then downloads the identity credentials to the certificate module of the IH client component. (2) The IH client component encrypts and signs the client device information, user identity information and application identifier to form an authorization package; (3) The IH client component inserts a separate authorization packet layer below the original multiplexing, secure transport layer protocol, congestion control and loss recovery of the QUIC protocol; When the IH client component needs to send a QUIC handshake connection packet to the AH service component, it encapsulates the request data into a UDP packet, then encapsulates the authorization packet and packet identifier in the outer UDP layer, and then performs other QUIC encapsulation operations to form a QUIC handshake connection packet. (4) The AH trusted proxy on the target AH service side intercepts the QUIC handshake connection packet, first parses the protocol, and determines whether it is QUIC. If it is, proceed to the next step; otherwise, discard it directly. (5) The AH trusted proxy determines whether the QUIC handshake connection packet carries an authorization packet. If not, the QUIC handshake connection packet is discarded directly; otherwise, the next step is processed. (6) The AH trusted proxy requests the identity security infrastructure to check the legitimacy of the client device information in the authorization packet. If it is legitimate, proceed to the next step of processing; otherwise, discard the QUIC handshake connection packet directly. (7) The AH trusted proxy requests the identity security infrastructure to verify whether the IH client component has access to the service. If it does, proceed to the next step; otherwise, discard the QUIC handshake connection packet. (8) The AH trusted proxy requests the target AH service to verify whether the IH client component has access to the resource. If it does, proceed to the next step; otherwise, discard the QUIC handshake connection packet. (9) The AH trusted proxy allows the QUIC handshake connection packet to the target AH service; (10) The target AH service opens the border firewall control port, establishes a handshake connection, and returns a handshake success message to the IH client component; (11) The IH client component begins sending business data to the AH service.

2. The method according to claim 1, characterized in that, In step (2), the information of the client device includes the IMEI number of the client device.

3. A QUIC-based software-defined boundary system implementing any one of claims 1-2, characterized in that, This includes IH client components, AH trusted proxy, and AH service components; The IH client component is a software or hardware component installed on the client device, which has a certificate module and a data encapsulation module based on the HTTP3 client. The certificate module is used to store the identity credentials requested by the IH client component from the identity security infrastructure; the data encapsulation module integrates an improved HTTP3 client, which inserts a separate authorization packet layer below the original multiplexing, secure transport layer protocol, congestion control and loss recovery of the QUIC protocol; When the IH client component needs to send a QUIC handshake connection packet to the AH service component, the data encapsulation module encapsulates the request data into a UDP packet, then encapsulates the authorization packet and packet identifier in the outer UDP layer, and then performs other QUIC encapsulation operations to form a QUIC handshake connection packet, thus realizing the combination of the handshake packet and SPA authorization authentication.

4. The system according to claim 3, characterized in that, The authorization packet is located at the end of the QUIC handshake connection packet header file, occupying 1-6 bytes. When the AH trusted proxy receives the QUIC handshake connection packet, it can extract and parse the authorization packet in the header file without performing data parsing. The AH trusted proxy is used to verify the QUIC handshake connection packet in steps (4)-(8) of any of the methods described in claims 1-2, and allows it to be passed to the target AH service after successful verification.

5. The system according to claim 3, characterized in that, The IH client component also includes a status detection module, which is used to monitor the update status of the client device certificate information, whether the user liveness detection is passed, the user operation log recording, and the detection and reporting of the client device network status.

Images