WO2023010839A1 - 访问控制方法、客户端代理装置、网关设备及相关系统 - Google Patents

访问控制方法、客户端代理装置、网关设备及相关系统 Download PDF

Info

Publication number
WO2023010839A1
WO2023010839A1 PCT/CN2022/079432 CN2022079432W WO2023010839A1 WO 2023010839 A1 WO2023010839 A1 WO 2023010839A1 CN 2022079432 W CN2022079432 W CN 2022079432W WO 2023010839 A1 WO2023010839 A1 WO 2023010839A1
Authority
WO
WIPO (PCT)
Prior art keywords
client
session
message
negotiation message
gateway device
Prior art date
Application number
PCT/CN2022/079432
Other languages
English (en)
French (fr)
Inventor
陈立健
吴昊
郑睿
Original Assignee
华为技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 华为技术有限公司 filed Critical 华为技术有限公司
Priority to EP22851566.4A priority Critical patent/EP4369656A1/en
Publication of WO2023010839A1 publication Critical patent/WO2023010839A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present application relates to the technical field of computer networks, and in particular to an access control method, a client agent device, a gateway device and an access control system.
  • the zero trust architecture (also known as "zero trust security model") is different from the traditional network border security trust system.
  • the zero trust architecture emphasizes the principle of "never trust, always verify", that is, the gateway device should not trust the terminal by default. devices, regardless of whether these end devices are accessed through the company's LAN or these end devices have been authenticated before.
  • Link security is an important aspect in the zero trust architecture. It means that the data in the session established between the terminal device and the server that provides resources needs to be encrypted and transmitted to prevent security problems caused by network sniffing.
  • each session needs to carry authentication information while ensuring link security, so that the gateway device can perform authentication based on the authentication information carried in the session, and then confirm whether the session currently requested to be established has the corresponding Resource access rights, allowing or blocking the establishment of a session between the terminal device and the server.
  • the terminal device can transmit authentication information to the gateway device through the application layer field of the message.
  • the terminal device downloads the small data (cookie) to the terminal from the browser.
  • the authentication information is carried in the cookie field of the Hypertext Transfer Protocol (Hypertext Transfer Protocol, HTTP) message.
  • the application forms in the client/server (Client/Server, C/S) scenario are very rich and complex. If you want to transmit authentication information through the application layer data of the message, you need to adapt and modify multiple application protocols on the terminal device and the gateway respectively, which is very difficult to implement.
  • An embodiment of the present application provides an access control method to alleviate the problem of high performance overhead of a terminal device or a gateway device in the access control process in a zero-trust scenario.
  • an access control method is provided, which is executed by a client agent running on a terminal device.
  • the client agent device intercepts the first negotiation message, the first negotiation message comes from the first application client on the terminal device, and is used to negotiate and establish the first session, and the first session is the first application client A session between the client and the first server, and the first session meets the encryption strength requirement.
  • the client proxy device adds the authentication information corresponding to the first application client to the transport layer header of the first negotiation message to obtain a modified first negotiation message; and sends the modified message to the gateway device After the first negotiation packet.
  • the client proxy device running on the terminal device does not need to re-encrypt the session initiated by the application client on the terminal device and meets the encryption strength requirements before forwarding the session negotiation message to the gateway device.
  • Do further encrypted tunnel encapsulation but carry authentication information in the transport layer header of the session negotiation message. In this way, while meeting the requirements of link security and authentication, it saves the overhead caused by additional tunnel encryption and decryption, and helps to improve the processing performance of terminal devices and gateway devices.
  • the client proxy device determines whether the negotiated session meets the encryption strength requirement according to the protocol type of the intercepted session negotiation message, information related to the encryption strength carried, and the like.
  • the information related to the encryption strength carried in the session negotiation message includes but is not limited to the protocol version number and/or the list of cipher suite identifiers.
  • the first session meets encryption strength requirements, including:
  • the first negotiation message carries a specified protocol version number, the protocol version corresponding to the specified protocol version number implements a transmission security higher than a preset security standard, and the first session performs data transmission based on the protocol version .
  • the specified protocol version number includes Transport Layer Security (Transport Layer Security, TLS) 1.2 or TLS 1.3.
  • the first session meets the encryption strength requirements, including:
  • the first negotiation message includes a specified cipher suite identifier, the specified cipher suite identifier is used to identify a specified cipher suite, and the transmission security achieved by the specified cipher suite is higher than a preset security standard, and the first session is based on The specified encryption suite encrypts the application data.
  • the embodiment of the present application provides a simple and effective method of determining that the first session meets the encryption strength requirement according to the information carried in the session negotiation message.
  • the first negotiation packet is a TLS packet.
  • the first negotiation packet is a client hello (Client Hello) message.
  • the gateway device needs to distinguish between different situations and perform different follow-up processing for the message received from the client agent device, for example, if the received message is The packet is multiplexed after adding authentication information to the transport layer header of the negotiation packet sent by the application client. Since the packet is not encapsulated, the gateway device does not need to decapsulate it.
  • the transport layer header of the modified first negotiation message further includes indication information, and the indication information causes the gateway device not to decipher the modified first negotiation message. encapsulation.
  • the client agent device selectively adds authentication information to different positions of the transport layer header of the first negotiation message.
  • the client proxy device adds authentication information to a transport layer security option (Transport Layer Security Option, TLS Option) in a transport layer packet header.
  • TLS Option Transport Layer Security Option
  • adding the authentication information corresponding to the first application client in the transport layer header of the first negotiation message includes: adding TLS Option in the transport layer header of the first negotiation message field; the authentication information corresponding to the first application client is carried in the TLS Option field.
  • the TLS Option field conforms to a type length value (type-length-value, TLV) structure, and the type T field in the TLV structure is used to carry indication information, and the Indicating information so that the gateway device does not perform TLS decapsulation processing on the modified session negotiation message, and the value V field is used to carry the authentication information.
  • TLS Option field structure provided by the embodiment of the present application enables the TLS Option field to carry indication information and authentication information at the same time, which is a relatively efficient way of carrying information.
  • the authentication information includes a user token and/or an application token.
  • the authentication information is used by the gateway device to authenticate the identity of the access initiator during each session establishment process.
  • the authentication information further includes: a device identifier and/or address information of the first server.
  • the address information of the first server includes an Internet Protocol (Internet Protocol, IP) address and/or port number of the first server.
  • the method before sending the modified first negotiation message, the method further includes:
  • the first difference is the sequence number of the synchronization message sent by the proxy client device to the first server and the synchronization message sent by the first client.
  • the difference between the serial numbers of the text, the second difference is the confirmation number of the synchronization message sent by the proxy client device to the first server as a proxy client and the confirmation number of the synchronization message sent by the first client.
  • the client agent device adds authentication information in the first negotiation message
  • the message length of the first negotiation message after modification is changed compared with that before the modification.
  • the error rate when negotiating packets when the client proxy device adds authentication information in the first negotiation packet, it also modifies the sequence number of the first negotiation packet.
  • the method further includes:
  • the proxy device at the client side performs message forwarding in proxy mode before the first session is successfully established, and switches from proxy mode to stream mode to transmit subsequent messages of the first session after the first session is successfully established.
  • the stream mode does not need to maintain the state of two independent connections, so the client proxy device can further save processing resources, that is, save the processing resources of the terminal device.
  • transmitting subsequent packets of the first session in a stream mode includes:
  • the confirmation number of the subsequent message, so as to obtain the modified subsequent message from the first session of the first application client, and the first difference is that the proxy client device acts as a proxy client to send
  • the second difference is that the proxy client device serves as a proxy client to the The difference between the confirmation number of the synchronization message sent by the first server and the confirmation number of the synchronization message sent by the first client;
  • the fourth difference is the proxy client The difference between the confirmation number of the synchronization confirmation message sent by the terminal device as a proxy server to the first client and the confirmation number of the synchronization confirmation message sent by the first server;
  • the method further includes:
  • the second negotiation message comes from a second application client on the terminal device and is used to negotiate with a second server to establish a second session, and the second session does not meet the encryption strength Require;
  • tunnel negotiation message performs tunnel encapsulation on the second negotiation message to obtain a tunnel negotiation message, where the header of the tunnel negotiation message includes authentication information corresponding to the second application client, wherein the tunnel negotiation message is used for Negotiating to establish an encrypted tunnel between the client agent device and the gateway device;
  • the access control method provided by the embodiment of the present application is a supplement to the processing process of the above-mentioned session initiated by the application client and meeting the encryption strength requirements.
  • an additional encrypted tunnel needs to be established between the client agent device and the gateway device.
  • the client agent device encapsulates the session message through the encrypted tunnel to meet the link security requirements;
  • the tunnel packet header added by the end proxy device to the session negotiation packet transmits the authentication information to the gateway device, so as to meet the authentication requirement. Therefore, a more complete solution is provided, so that the client proxy device on the terminal device can handle various sessions initiated by various application clients.
  • the authentication information corresponding to the second application client is carried in different positions of the packet header of the tunnel negotiation packet.
  • the authentication information corresponding to the second application client carries In the application layer packet header of the tunnel negotiation packet.
  • the authentication information corresponding to the second application client is carried in the transport layer packet header of the tunnel negotiation packet.
  • the application layer message header is a hypertext transfer protocol HTTP header
  • the authentication information corresponding to the second application client is carried in the cookie field of the HTTP header .
  • the method further includes:
  • the client proxy device For a session initiated by an application client on a terminal device that does not meet the encryption strength requirements, the client proxy device transmits subsequent packets of the session through an encrypted tunnel between the client proxy device and the gateway device, thereby meeting the link security requirements .
  • the embodiment of the present application provides an access control method.
  • the gateway device receives a first negotiation message, the first negotiation message comes from the first client agent device, and is used to negotiate and establish a first session, and the first session is between the first terminal device and the first server
  • the session is specifically a session between the first application client on the first terminal device and the first server.
  • the first client agent device runs on the first terminal device, and the transport layer header of the first negotiation message carries authentication information.
  • the first negotiation packet received by the gateway device is actually the first negotiation packet modified by the client proxy device in the first aspect.
  • the gateway device initiates first authentication according to the authentication information. After the first authentication is successful, the gateway device does not perform tunnel decapsulation on the first negotiation packet, and forwards the first negotiation packet to the first server, so as to establish a first connection, and the first connection is A connection between the gateway device and the first server.
  • the gateway device When the gateway device carries authentication information in the transport layer header of the received session negotiation message, if the authentication is successful according to the authentication information carried in the transport layer header, there is no need to perform session negotiation When the packet is decapsulated, the session negotiation packet is forwarded to the server. Since tunnel decapsulation is not performed, the overhead caused by additional tunnel encryption and decryption is saved, which helps to improve the processing performance of terminal devices and gateway devices.
  • the first negotiation packet is a TLS packet.
  • the first negotiation packet is a Client Hello message.
  • the authentication information is carried in the TLS Option field of the transport layer header of the first negotiation message.
  • the header of the transport layer packet further carries indication information, and the indication information causes the gateway device not to perform the Tunnel decapsulation.
  • the TLS Option field conforms to a Type Length Value TLV structure, and the Type T field in the TLV structure is used to carry indication information, and the gateway device according to the The indication information does not perform TLS decapsulation on the modified session negotiation message, and the value V field is used to carry the authentication information.
  • the method further includes:
  • the second connection is a connection between the gateway device and the first client proxy device;
  • the gateway device authenticates the session initiator successfully
  • the application client on the terminal device and the server are transmitted through the connection between the gateway device and the first client agent device and the connection between the gateway device and the server. session packets, thus realizing session granular access control.
  • the method further includes: if the first authentication fails, the gateway device terminates establishing the second connection.
  • the method further includes:
  • the second negotiation message is from the second client agent device, and is used to negotiate and establish a second session, and the second session is a session between the second terminal device and the second server,
  • the second client proxy device runs on the second terminal device, and the transport layer header of the second negotiation message does not carry authentication information;
  • the gateway device After the gateway device receives the session negotiation message, it executes different subsequent processing procedures according to the location where the authentication information is obtained. Specifically, as a supplement to the processing of the session initiated by the above application client and meeting the encryption strength requirements, the gateway device, when the transport layer header of the received session negotiation message does not carry authentication information, from the The authentication information is obtained from the application layer packet header to initiate authentication. In the case of successful authentication, an encrypted tunnel needs to be used between the gateway device and the client agent device to achieve link security. Therefore, when the gateway device forwards packets, it needs to Packets are tunnel-encapsulated or decapsulated.
  • performing access control on the first session according to the authentication result of the first authentication process includes:
  • the third connection is the a connection between the gateway device and the second server;
  • performing access control on the second session according to the authentication result of the second authentication includes:
  • the embodiment of the present application provides a client agent device.
  • the client agent device runs on a terminal device, and the device includes a plurality of functional modules, and the plurality of functional modules interact to implement the above-mentioned first aspect and the methods in each implementation manner.
  • the multiple functional modules are implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules are combined or divided arbitrarily based on specific implementations.
  • the embodiment of the present application provides a gateway device.
  • the gateway device includes multiple functional modules, and the multiple functional modules interact to implement the methods in the above first aspect and various implementation manners thereof.
  • the multiple functional modules are implemented based on software, hardware, or a combination of software and hardware, and the multiple functional modules are combined or divided arbitrarily based on specific implementations.
  • the embodiment of the present application provides a terminal device, including a memory and a processor;
  • the memory is used to store computer instructions
  • the terminal device executes the method described in the first aspect or any possible implementation manner of the first aspect.
  • the embodiment of the present application provides a gateway device, including a memory and a processor
  • the memory is used to store computer instructions
  • the gateway device executes the method described in the second aspect or any possible implementation manner of the second aspect.
  • the embodiment of the present application provides a computer-readable storage medium, where computer instructions are stored in the computer-readable storage medium, and when the computer instructions are executed by a processor of a terminal device, the terminal device executes The access control method described in the above-mentioned first aspect or any possible implementation of the first aspect; or, when the computer instructions are executed by the processor of the gateway device, the gateway device executes the above-mentioned second aspect or the first aspect The method described in any possible implementation of the two aspects
  • the embodiment of the present application provides an access control system, including a terminal device and a gateway device, where a client agent device runs in the terminal device,
  • the client agent device is configured to intercept a first negotiation message, the first negotiation message comes from a first application client on the terminal device, and is used to negotiate and establish a first session, and the first session It is a session between the first application client and the first server, and the first session meets the encryption strength requirement; adding the first application client to the transport layer header of the first negotiation message The authentication information corresponding to the terminal to obtain the modified first negotiation message; send the modified first negotiation message to the gateway device;
  • the gateway device is configured to receive the modified first negotiation message; initiate first authentication according to the authentication information carried in the transport layer header of the modified first negotiation message; the After the first authentication is successful, the first negotiation packet is not tunnel-decapsulated, and the first negotiation packet is forwarded to the first server, so as to establish a first connection, and the first connection is the A connection between the gateway device and the first server.
  • a chip in the ninth aspect, includes programmable logic circuits and/or program instructions, and when the chip is running, the actions performed by the client agent device in the first aspect and the methods of the implementations of the first aspect are realized .
  • a chip in a tenth aspect, includes a programmable logic circuit and/or program instructions.
  • the chip When the chip is running, the actions performed by the gateway device in the above-mentioned second aspect and the methods in the implementation manners of the second aspect are realized.
  • a computer program product includes one or more computer program instructions, and when the computer program instructions are loaded and executed by a terminal device, the terminal device executes the above-mentioned first The actions performed by the terminal device in the methods of the various implementation manners of the aspect and the first aspect.
  • a computer program product includes one or more computer program instructions, and when the computer program instructions are loaded and executed by a gateway device, the gateway device executes the above-mentioned second Actions performed by the gateway device in the methods of each implementation manner of the aspect and the second aspect.
  • FIG. 1 is a schematic diagram of an access control system under a zero-trust architecture provided by an embodiment of the present application
  • Fig. 2 is a schematic diagram of carrying authentication token information through cookies under the B/S scenario provided by the embodiment of the present application;
  • FIG. 3 is a schematic diagram of transmitting authentication information through a TLS tunnel between a client agent device and a gateway device provided by an embodiment of the present application;
  • FIG. 4 is a schematic diagram of transmitting authentication information through an HTTPS tunnel between a client agent device and a gateway device provided by an embodiment of the present application;
  • FIG. 5 is a schematic diagram of carrying authentication information through an HTTP application layer header provided by an embodiment of the present application
  • FIG. 6 is a schematic diagram of an application scenario of an access control method provided by an embodiment of the present application.
  • FIG. 7 is a flowchart of an access control method provided by an embodiment of the present application.
  • Fig. 8 is the schematic diagram of the Client Hello message parsing result provided by the embodiment of the present application.
  • FIG. 9 is a schematic diagram of sequence numbers and confirmation numbers of messages that need to be recorded during the process of establishing a tripartite connection between the application client, the client proxy device, and the gateway device provided by the embodiment of the present application;
  • FIG. 10 is a detailed schematic diagram of adjustment of forwarded messages by the client agent device provided in the embodiment of the present application.
  • FIG. 11 is a flow chart of another access control method provided by the embodiment of the present application.
  • FIG. 12 is a flow chart of another access control method provided by the embodiment of the present application.
  • FIG. 13 is a flowchart of another access control method provided by the embodiment of the present application.
  • FIG. 14 is a schematic diagram of an access control method provided by an embodiment of the present application.
  • FIG. 15 is a schematic diagram of an access control method provided by an embodiment of the present application.
  • FIG. 16 is a schematic structural diagram of a terminal device provided in an embodiment of the present application.
  • FIG. 17 is another schematic structural diagram of a terminal device provided in an embodiment of the present application.
  • FIG. 18 is a schematic structural diagram of a gateway device provided in an embodiment of the present application.
  • FIG. 19 is a schematic structural diagram of another gateway device provided by an embodiment of the present application.
  • an access control system based on a zero-trust architecture usually includes a controller, a gateway device, and a terminal device, wherein a client agent device is installed in the terminal device.
  • the client agent device When a terminal device needs to access protected application resources, the client agent device will first initiate an identity authentication and access control request to the controller. After the identity authentication and access control pass, the controller will send token information to the client agent device .
  • the client proxy device then sends an access request to the gateway device, and the access request carries authentication information including the above-mentioned token information.
  • the gateway device authenticates the access initiator based on the authentication information in the access request. If the authentication passes, the gateway device establishes a connection with the server to transmit subsequent business messages between the client agent device and the server. Otherwise, closes the connection with the server. Connections between client agent devices.
  • the client proxy device needs to solve the problem of how to transmit authentication information to the gateway device, so that the gateway device can use the authentication information to identify whether the current session has the corresponding resource access rights.
  • a browser on a terminal device acts as an application client to access a web application.
  • the client proxy device carries token information in the cookie field of the HTTP protocol header by setting the browser cookie, as shown in FIG. 2 .
  • the application forms in the C/S scenario are very rich and complex.
  • plaintext applications such as File Transfer Protocol (File Transfer Protocol, FTP) applications, remote login (Telnet) applications, Secure Shell (Secure Shell, SSH) protocol applications, and Remote Desktop Protocol (Remote Desktop Protocol, RDP) applications
  • encrypted applications such as File Transfer protocol via Secure Socket Layer (FTPS) and Web sockets based on Secure Sockets Layer; such as private protocols such as desktop cloud docking and applets class applications, etc.
  • FTP File Transfer Protocol
  • Telnet Secure Shell
  • SSH Secure Shell
  • Remote Desktop Protocol Remote Desktop Protocol
  • encrypted applications such as File Transfer protocol via Secure Socket Layer (FTPS) and Web sockets based on Secure Sockets Layer
  • private protocols such as desktop cloud docking and applets class applications, etc.
  • the gateway device blocks the business traffic; if the authentication passes, the gateway device and the server that provides resources (the server that provides resources is also called a "real server" is relative to the proxy server, zero-trust
  • the gateway establishes a connection by mapping the virtual IP address as a proxy server instead of the real server to establish a connection with the terminal device), and decapsulates the tunnel traffic and sends the decapsulated business packets to the server that provides resources.
  • FIG. 3 describes a scheme for transferring authentication information between the client agent device and the gateway device through a TLS tunnel.
  • server A provides TCP service through port 7788 on IP address 10.19.13.181
  • server B provides SSH service through port 22 on IP address 10.88.0.2
  • server C through IP address Port 80 on 10.88.0.2 provides web services.
  • the above three services are all mapped to port 8443 on the virtual IP address 10.0.3.11 of the gateway device.
  • the client agent device obtains from the controller the virtual IP address and port to which the terminal device and the services allowed to be accessed by the user are mapped, as well as the corresponding real server, by initiating identity authentication and access control processes address and port number.
  • the client proxy device After the client proxy device intercepts the service packets sent by various applications running on the terminal device, it initiates the establishment of a TLS Tunnel with the gateway device.
  • the client agent device carries the token information and real server information used for authentication in the TLS extension option (Option) of the first TLS handshake message Client Hello. For example, define the TLS extension type as 2000 (this extension type is not in the default TLS option).
  • the carried data content is parsed as follows.
  • the gateway device extracts relevant authentication information for authentication to confirm whether the terminal device is allowed to access the service provided on port 22 of the IP address 10.80.0.2 carried in the TLS Option field. If the authentication fails, then close the current session between the gateway device and the client proxy device; if the authentication is successful, the gateway device will obtain the information of the real server according to the TLS Option option (that is, the IP address 10.80.0.2 and the port number 22 ), initiate a connection to the real server. Then the gateway device completes the establishment process of the TLS tunnel with the client agent device, performs TLS decapsulation and decryption on the tunnel message received through the TLS tunnel, and forwards the decapsulated and decrypted service message to the real server.
  • the gateway device completes the establishment process of the TLS tunnel with the client agent device, performs TLS decapsulation and decryption on the tunnel message received through the TLS tunnel, and forwards the decapsulated and decrypted service message to the real server.
  • Fig. 4 describes the solution of transferring token information between the client agent device and the gateway device through the HTTPS tunnel.
  • the application scenario is similar to that of Figure 3, please refer to the description in Figure 3 for details.
  • the client proxy device intercepts the service message sent by the application running on the terminal device, the client proxy device initiates a process of establishing an HTTPS tunnel with the gateway device.
  • HTTPS is also known as HTTP over TLS/SSL.
  • the client agent device carries the relevant information of the real server in the Uniform Resource Identifier (Uniform Resource Identifier, URI) field of the Connect method of the HTTP application layer. As shown in FIG.
  • Uniform Resource Identifier Uniform Resource Identifier
  • the content of the Connect field carries the IP address 10.19.13.181 of the real server currently accessed by the terminal device, the port number 7788, and the open service protocol TCP.
  • the client agent device carries the token information in the Cookie field, and the token information includes the application token "aef7-a18534f3971bdcbea25-" and/or user token information (not shown in the figure) and the like.
  • the gateway device adopts a protocol analysis process similar to that in the B/S scenario, obtains the token information carried in the header of the HTTPS tunnel message, and performs token authentication to confirm whether the terminal device is allowed to access the token information carried in the Connect field. TCP service provided by port 7788 on IP address 10.19.13.181. If the authentication fails, then close the current session between the gateway device and the client proxy device; if the token authentication is successful, then according to the information of the real server carried in the Connect field (i.e. IP address 10.19.13.181 and port number 7788), Initiate a connection to the real server. Complete the HTTPS tunnel establishment process with the client, decapsulate and decrypt the tunnel packets received through the HTTPS tunnel, and forward the decapsulated and decrypted service packets to the real server.
  • TCP service provided by port 7788 on IP address 10.19.13.181. If the authentication fails, then close the current session between the gateway device and the client proxy device; if the token authentication is successful, then according to the information
  • the client proxy device needs to establish a new tunnel connection with the gateway device.
  • the client proxy device needs to encapsulate the service message to be sent, and the gateway device needs to decapsulate it, and the encryption and decryption involved in the TLS tunnel or HTTPS tunnel itself consumes a lot of performance.
  • the application to be accessed by the application client on the terminal device itself is an encryption protocol and meets the strong encryption requirements, for example, the FTPS protocol itself is TLS encryption, in this case there is no need to do a layer of TLS tunnel encapsulation or HTTPS Tunnel encapsulation .
  • creating a tunnel will increase performance overhead; for the gateway device, parallel processing of tunnel connections with multiple client proxy devices will also bring relatively large performance overhead.
  • an embodiment of the present application provides an access control method.
  • the tunnel connection established between the client agent device and the gateway device is mainly for the consideration of link security and authentication.
  • the access control method provided by the embodiment of the present application adopts the following ideas to solve the two considerations.
  • the first aspect is how to ensure the security of network data transmission.
  • the client proxy device does not need to perform further encrypted tunnel encapsulation before forwarding the session negotiation message to the gateway device, which is convenient to save the additional tunnel encryption and decryption. overhead.
  • another layer of encrypted tunnel encapsulation such as HTTPS tunnel encapsulation, is performed to ensure link security through the tunnel.
  • the second aspect is to solve the problem of how to carry authentication information.
  • the proxy device on the client side modifies the transport layer header of the original session negotiation message to carry authentication information, thereby reusing the original session negotiation message.
  • the gateway device obtains the authentication information from the transport layer packet header of the modified session negotiation packet and performs authentication. If the currently obtained token information is illegal, the gateway device blocks the current session between the gateway device and the client agent device; if the currently obtained token information is legal, the gateway device establishes a connection with the real server and forwards the real server to the application client Subsequent service packets between terminals. Therefore, the authentication problem of the gateway device to the access initiator is solved. In this way, the client proxy device does not need to perform tunnel encapsulation on the service message, and carries the token information through the tunnel message header, which is convenient to save the overhead caused by additional tunnel encryption and decryption.
  • FIG. 6 is a schematic diagram of an application scenario of the access control method provided by the embodiment of the present application. Similar to FIG. 1 , FIG. 3 and FIG. 4 , the scenario described in FIG. 6 includes an access control system and protected application resources. Among them, the access control system includes three types of devices: controller, gateway device and terminal device.
  • the protected application resources include three servers in the protected network, where server A provides TCP services through port 7788 on IP address 10.19.13.181, server B provides SSH services through port 22 on IP address 10.88.0.2, and Server C provides web services through port 80 on IP address 10.88.0.2. According to the configuration of the controller, the above three services are all mapped to port 8443 on the virtual IP address 10.0.3.11 of the gateway device.
  • the controller is used to perform access control and identity authentication on terminal equipment and users according to the request of the client agent device, and then send authentication information and a list of resources allowed to be accessed to the client agent device; and send the legal user correspondence to the gateway device.
  • a control policy so that the gateway device controls the terminal device's access to the protected application resources according to the control policy.
  • a client agent device is installed in the terminal device. Before the terminal device accesses various applications, the client agent device also obtains from the controller the virtual IP address and port number of the gateway device to which the terminal device and the services allowed to be accessed by the user are mapped through the process of identity authentication and access control, and The address and port number of the corresponding real server.
  • the client proxy device is used to intercept the message sent by the application client on the terminal device where the client proxy device is located, and initiate the establishment of a connection with the gateway device according to the message.
  • terminal device A and terminal device B are used as examples for illustration. If there are more terminal devices, functions of other terminal devices are similar to those of terminal device A or terminal device B.
  • the client agent device A is installed in the terminal device A, and the client agent device B is installed in the terminal device B.
  • the gateway device is used to extract authentication information from the traffic sent by the client proxy device, initiate authentication, and perform corresponding actions according to the authentication result, such as blocking the connection between the gateway device and the client proxy device when the authentication fails , or establish a connection with the server when the authentication is successful, and transmit subsequent service packets between the application client and the server through the connection with the server.
  • the embodiment of the present application mainly makes the following improvements to the client agent device and the gateway device.
  • the client proxy device After the client proxy device provided in the embodiment of the present application intercepts the session negotiation message used by the application client to create a session with the server, if the session to be created meets the encryption strength requirements, in the session negotiation message Add authentication information to the transport layer header of the message to obtain the modified session negotiation message.
  • the client proxy device sends the modified session negotiation message to the gateway device, so that the gateway device authenticates the terminal device and the user according to the authentication information carried in the transport layer header of the modified session negotiation message.
  • the purpose of transmitting authentication information is realized by multiplexing the session negotiation message sent by the application client, without additionally initiating the tunnel establishment process, and the authentication information is transmitted through the session negotiation message in the tunnel establishment process initiated by the application client, thereby
  • the processing resource consumed by the additional tunnel negotiation on the terminal device and the gateway device is saved, and helps to reduce the performance overhead of the terminal device and the gateway device.
  • the gateway device After the gateway device provided in the embodiment of the present application receives the session negotiation message from the client proxy device, it determines whether the transport layer header of the session negotiation message carries authentication information. If the transport layer header of the session negotiation message carries authentication information, the gateway device initiates authentication according to the authentication information carried in the transport layer header of the session negotiation message. In the case of successful authentication, the session negotiation message is not decapsulated and forwarded. In this way, when the session to be created initiated by the application client meets the encryption strength requirements, the gateway device does not need to tunnel decapsulate the session negotiation message, and then obtain the authentication information from the application layer, thereby saving processing resources and improving authentication efficiency and processing performance.
  • the proxy device on the client side and the gateway device can switch from proxy mode to streaming mode for subsequent transmission.
  • Service messages do not need to perform tunnel transmission or proxy mode forwarding for service messages, which can save the processing of tunnel-related encapsulation and decapsulation processes on terminal devices and gateway devices, as well as possible encryption and decryption processing. Resources, thereby reducing the performance overhead of terminal devices and gateway devices, and helping to improve the overall performance of the access control system.
  • FIG. 7 is a flow chart of the access control method provided by the embodiment of the present application, including steps 701 to 704.
  • the flow chart shown in FIG. 7 mainly describes the access control method provided by the embodiment of the present application from the perspective of the client agent device in the terminal device.
  • the terminal device in the embodiment described in Fig. 7 is the terminal device A or terminal device B in Fig. 6, and correspondingly, the terminal device in Fig. 7 is the terminal device A in Fig. 6
  • the client agent device in the embodiment described in Fig. 7 is the client agent device A in the accompanying drawing 6, and in the case that the terminal device in the accompanying drawing 7 is the terminal device B in the accompanying drawing 6, Fig. 7
  • the client proxy device in the described embodiment is client proxy device B in FIG. 6 .
  • Step 701 the client proxy device intercepts a first negotiation message, the first negotiation message comes from the first application client on the terminal device, and is used to negotiate and establish a first session with the first server, wherein The first session meets encryption strength requirements.
  • the terminal device defaults to enabling the client proxy device installed on the terminal device.
  • the client proxy device intercepts the session negotiation message sent by the application client.
  • application client refers to the application client software installed on the terminal device, such as the FTP client software taking FileZilla as an example (FileZilla can be used as FTP client software or FTPS client software) terminal software), the telnet client in the command line mode that comes with the Windows series operating system, etc.
  • the first negotiation message is, for example, a session negotiation message sent when the FileZilla client initiates the creation of the first session with the FTPS server.
  • the manner in which the client agent device intercepts the session negotiation message is related to a specific operating system.
  • Netfilter is a framework provided by the Linux kernel that allows various network-related operations to be implemented in the form of custom handlers. Netfilter provides various functions and operations for packet filtering, network address translation and port translation.
  • the client agent device intercepts the session negotiation message and the subsequent service message from the application client through the Hook function added to the NetFilter.
  • the client proxy device serves as a proxy device between the application client and the gateway device, and communicates with the application client and the gateway device respectively in a proxy mode.
  • the client proxy device acts as a proxy server.
  • the client proxy device acts as a proxy client.
  • the client proxy device Before receiving the session negotiation message from the application client, the client proxy device first establishes a TCP connection with the application client through a three-way handshake process, and receives the session negotiation message through the established TCP connection.
  • the client agent device and the gateway device establish a TCP connection through a three-way handshake process, and in step 703 send a modified session negotiation message through the established TCP connection.
  • the client agent device or other components on the terminal device determine whether the session to be created corresponding to the intercepted session negotiation message meets the encryption strength requirement. For example, when the client proxy device determines whether the session to be created meets the encryption strength requirement, the client proxy device first intercepts a certain session negotiation message generated by the application client, and performs step 701a on the intercepted session negotiation message. In the steps shown, in the case that the session to be created meets the encryption strength requirement, the intercepted session negotiation message is the first negotiation message, and the session to be created is the first session.
  • the client proxy device first intercepts a message generated by the application client, and other components perform the steps shown in step 701a on the intercepted session negotiation message , when the session to be created meets the encryption strength requirement, the intercepted session negotiation message is the first negotiation message, and the session to be created is the first session.
  • Step 701a judge whether the session to be created meets the encryption strength requirement according to the intercepted session negotiation message.
  • the client proxy device after the client proxy device intercepts the session negotiation message, it performs protocol analysis on the intercepted session negotiation message, and judges the negotiated protocol according to the protocol type of the session negotiation message, information related to the encryption strength carried, etc. Whether the session meets the encryption strength requirements.
  • the information related to the encryption strength carried in the session negotiation message includes but is not limited to the protocol version number and/or the list of cipher suite identifiers.
  • the situation that the session negotiated and created by the session negotiation message satisfies the encryption strength requirement includes that the session created by the session negotiation message is an encryption application, and/or according to the encryption strength-related information carried by the session negotiation message.
  • the information determines that the transmission security of the session to be created is higher than a preset security standard and so on.
  • the first instance that a session meets the encryption strength requirement is that the intercepted session negotiation message carries a specified protocol version number, where the protocol version corresponding to the specified protocol version number achieves a higher transmission security than the preset security A specific standard, the first session performs data transmission based on the protocol version.
  • the second instance that the session meets the encryption strength requirement is that the intercepted negotiation message includes a specified cipher suite identifier, which is used to identify a specified cipher suite, and the transmission security achieved by the specified cipher suite is higher than the preset A security standard, the first session encrypts application data based on the specified cipher suite.
  • the situation that the session negotiated and created by the session negotiation message does not meet the encryption strength requirement refers to other situations except the above-mentioned situation that meets the encryption strength requirement.
  • the situation that the session negotiated and created by the session negotiation message does not meet the encryption strength requirement includes but is not limited to at least two scenarios.
  • the first scenario is that the client agent device determines that the session created by the session negotiation message is an encrypted application, but determines that the transmission security of the session to be created is lower than the preset according to the information related to the encryption strength carried in the session negotiation message Security standard;
  • the second scenario is that the client proxy device determines that the session created by the session negotiation message is a plaintext application, that is, a non-encrypted application.
  • the first negotiation packet is a Client Hello (Client Hello) message as an example for illustration.
  • the application client is an FTPS client
  • the FTPS client requests to establish a connection with the FTPS server
  • it first needs to negotiate TLS layer encryption parameters, that is, negotiate a TLS tunnel.
  • the client and server perform a handshake process to negotiate TLS layer encryption parameters.
  • the client first sends a Client Hello message to the server, and the Client Hello message carries the protocol version number and cipher suite identifier list.
  • the client agent device After the client agent device intercepts the Client Hello message, it analyzes and obtains the content carried in the Client Hello message, as shown in FIG. 8 .
  • Figure 8 shows the protocol version number and cipher suite identification list carried in the transport layer protocol header of the Client Hello message with a solid line box.
  • the protocol version number carried in the Client Hello message is TLS1.2.
  • the server After receiving the Client Hello message, the server selects a cipher suite based on the cipher suite identification list carried in the Client Hello message, and subsequently uses the protocol corresponding to the protocol version number carried in the Client Hello message and the selected cipher suite to process the service message. encryption.
  • the embodiment of the present application respectively provides a method for the client agent device to judge whether the first session meets the encryption strength requirement according to the protocol version number (method 1), and judge whether the first session meets the encryption strength requirement according to the cipher suite identification list.
  • method 1 The method of strength requirement
  • method 2 these two methods can be selected or used in combination.
  • the encryption strength requirements pre-stored by the client proxy device include a set of protocol version numbers, wherein the protocol version corresponding to the protocol version number in the set of protocol version numbers achieves a transmission security higher than a preset security standard.
  • the client agent device judges whether the protocol version number carried in the session negotiation message belongs to the protocol version number set. If the protocol version number carried in the session negotiation message belongs to the protocol version number set, determine that the session meets the encryption strength requirement; if the protocol version number carried in the session negotiation message does not belong to the protocol version number set, it is determined that the session does not meet encryption strength requirements.
  • the set of protocol version numbers included in the encryption strength requirement is ⁇ TLS 1.2, TLS 1.3 ⁇ . If the protocol version number carried in the Client Hello message is TLS 1.2, which belongs to the set of protocol version numbers, it is determined that the session to be established meets the encryption strength requirements. If the protocol version number carried in the Client Hello message is TLS 1.0 and does not belong to the set of protocol version numbers, it is determined that the session to be established does not meet the encryption strength requirements.
  • the encryption strength requirements pre-stored by the client agent device include a set of cipher suite identifiers, and the transmission security achieved by the cipher suites corresponding to the cipher suite identifiers in the cipher suite identifier set is higher than the preset security standard.
  • the client agent device judges whether the cipher suite identification list carried in the first negotiation message includes the cipher suite identifications in the cipher suite identification set. If the cipher suite identification list carried in the first negotiation message includes the cipher suite identification in the cipher suite identification set, the client proxy device determines that the first session meets the encryption strength requirement; if in the first negotiation message, The carried cipher suite identification list does not include the cipher suite identifications in the cipher suite identification set, and the client proxy device determines that the first session does not meet the encryption strength requirement.
  • the set of cipher suite IDs included in the encryption strength requirement is
  • the set includes cipher suite IDs with medium or high encryption levels.
  • the cipher suite ID list carried in the Client Hello message includes one or more cipher suite IDs in the above cipher suite ID set, it is determined that the session to be established meets the encryption strength requirement. If the cipher suite ID list carried in the Client Hello message does not include any cipher suite ID in the above cipher suite ID set, it is determined that the session to be established does not meet the encryption strength requirement.
  • the client proxy device determines that the first session satisfies the encryption strength requirement according to the first negotiation packet, and performs step 702 .
  • Step 702 the client agent device adds the authentication information corresponding to the first application client to the transport layer header of the first negotiation message to obtain the modified first negotiation message.
  • the client proxy device may reuse the original session negotiation message to carry the authentication information. Still taking the Client Hello message as an example, the client agent device adds a new TLS option (Option) field in the transport layer header of the Client Hello message, and carries authentication information in the newly added TLS Option field.
  • the authentication information includes, but is not limited to, one of several items of information shown in Table 1, or a combination of at least two items of information among these several items of information.
  • the authentication information also includes a time stamp, an IP address of the terminal device, a current working status of the terminal device, or a security scanning result, etc., which will not be listed here.
  • the gateway device in order for the gateway device to carry authentication information in the header of the transport layer message, it is distinguished from the solution shown in Figure 3 and confirms that the session negotiation message sent by the client agent device meets the requirements of the session to be created.
  • the client proxy device In the case of a negotiation packet, instruct the gateway device not to tunnel decapsulate the first negotiation packet in a default or explicit manner.
  • the default mode is that as long as the transport layer header of the session negotiation message carries authentication information, it means that the session to be created meets the encryption strength requirement, and the gateway device does not tunnel decapsulate the first negotiation message. If the session to be created does not meet the encryption strength requirement, the client proxy device carries the authentication information in the application layer header of the tunnel message after performing tunnel encapsulation on the session negotiation message.
  • the client proxy device when the session to be created satisfies the encryption strength requirement, the client proxy device carries indication information in addition to the authentication information in the transport layer header of the first negotiation message.
  • the indication information causes the gateway device not to decapsulate the modified first negotiation packet.
  • the specific position of the indication information in the header of the transport layer message is not limited here.
  • the embodiment of the present application also provides a way of carrying indication information.
  • the TLS Option field conforms to the TLV structure.
  • the type T field in the TLV structure is used to carry indication information
  • the indication information enables the gateway device not to perform TLS decapsulation processing on the modified session negotiation message
  • the value V field is used to carry the Authentication information.
  • Step 703 the proxy device of the client sends the modified first negotiation message to the gateway device.
  • the client proxy device after the client proxy device intercepts the session negotiation message of the session initiated by the first application client and meets the encryption strength requirement, it adds authentication information to the transport layer header of the session negotiation message to obtain the modified session negotiation message, and send the modified session negotiation message to the gateway device, so that the gateway device can authenticate the terminal device and the user according to the authentication information carried in the transport layer header of the session negotiation message.
  • the purpose of transmitting authentication information is achieved by multiplexing the original session negotiation message of the application client between the client agent device and the gateway device.
  • the client The agent device and the gateway device do not need to establish an additional encrypted tunnel, which saves the processing resources consumed by the additional tunnel negotiation on the terminal device and the gateway device, and helps to reduce the performance overhead of the terminal device and the gateway device.
  • the gateway device authenticates the session initiator according to the modified first negotiation message sent in step 703, and if the authentication succeeds, the client proxy device executes steps 704 to 705.
  • Step 704 the client agent device receives the negotiation success message sent by the gateway device, and the negotiation success message indicates that the first session is established successfully.
  • the gateway device After the gateway device successfully authenticates the terminal device and the user according to the authentication information carried in the modified session negotiation message sent in step 703, it sends a message to the client agent device through the TCP connection between the gateway device and the client agent device.
  • a negotiation success message is sent to complete the TLS handshake with the client proxy device.
  • the client proxy device sends a negotiation success message to the application client through the TCP connection with the first application client, thereby completing the TLS handshake with the first application client.
  • the session between the first application client and the first server is substantially successfully established, and the first application client and the first server can start to transmit service packets through the created session, and the client proxy device executes after step 704 Step 705.
  • Step 705 the client agent device forwards the subsequent service packets of the first session.
  • the gateway device successfully authenticates the terminal device and the user according to the authentication information carried in the modified session negotiation message, the client proxy device does not need to establish an additional encrypted tunnel to transmit the second session between the first application client and the gateway device.
  • Subsequent service packets of a session save the processing resources consumed by the terminal device and gateway device for performing tunnel encapsulation, or decapsulation process, and possible encryption and decryption processing, thereby reducing the cost of terminal device and gateway device
  • the performance overhead helps to improve the overall performance of the access control system.
  • the follow-up business message of the first session includes: the FTPS client software sends a file download request to the FTPS server, and the download request carries parameters such as file name and download path, and the FTPS server responds to the FTPS client software with the requested resource file; or FTPS
  • the client software sends a file upload request to the FTPS server, and the upload request carries parameters such as file size and upload path, and the FTPS server responds to the FTPS client software with the results of file upload success or failure, etc.
  • the client proxy device relays and forwards subsequent service packets of the session created between the application client and the server.
  • the proxy device on the client side may transmit subsequent packets of the session between the application client and the server in various ways, and this embodiment of the present application only uses two ways for illustration.
  • the client proxy device continues to transmit subsequent packets of the first session in proxy mode.
  • the client proxy device works in proxy mode between the application client and the gateway device, and the client proxy device maintains the TCP connection with the application client and the TCP connection between the gateway device . Since the two TCP connections are established through an independent three-way handshake process, the sequence numbers and acknowledgment numbers in the packets transmitted in the two TCP connections are independent of each other.
  • an implementation manner for the client proxy device to transmit the follow-up message of the session between the application client and the server is that the client proxy device continues to communicate between the application client and the gateway device through these two TCP connections respectively. The business message is transmitted.
  • the client proxy device performs transport layer analysis on the service message sent by the application client to obtain the transport layer load, and then based on the state information related to the TCP connection between the gateway devices maintained by the client proxy device, the parsed A transport layer header is added to the transport layer payload to obtain a new service message, and then the new service message is sent to the gateway device through the TCP connection with the gateway device.
  • the principle of service message transmission in the opposite direction is similar, and will not be described here.
  • the client proxy device streams subsequent packets of the first session. Specifically, forwarding subsequent packets of the first session from the first application client to the gateway device, and forwarding the first session from the gateway device to the first application client Subsequent packets of the first session from the gateway device respond to the subsequent packets of the first session from the first application client.
  • the client proxy device can multiplex the packets sent by the application client without tunnel encapsulation. This means that after the authentication is successful, in the forwarding process of the subsequent service message, the service message (post-forwarded message) forwarded to the gateway device by the client agent device is different from the service message sent by the application client for one forwarding process.
  • the data carried in the message received by the end is the same, only the message sequence (SYN) number and acknowledgment (ACK) number may be different.
  • the client proxy device switches from proxy mode to stream mode, as long as the sequence number and By adjusting the confirmation number, the application client and the server can correctly reassemble the service message without interrupting the session. It is not necessary to still maintain the proxy mode to work between the application client and the gateway device.
  • the client proxy device In order to obtain the difference between the sequence number and the confirmation number before and after the packet forwarded by the client proxy device required for stream mode forwarding, the client proxy device needs to record the SYN message during two independent three-way handshakes when working in proxy mode.
  • the sequence number and confirmation number of the message, and the sequence number of the SYN+ACK message in order to adjust the sequence number and confirmation number of the subsequent message according to the sequence number difference and confirmation number difference of the corresponding message in the two three-way handshake process .
  • Accompanying drawing 9 is a schematic diagram of sequence numbers and confirmation numbers of messages that need to be recorded during the process of establishing a tripartite connection between the application client, the client proxy device, and the gateway device.
  • the client agent device records the serial number and confirmation number of the SYN message sent by the application client, the serial number and the confirmation number of the SYN message sent by the client agent device as the proxy client, and the SYN message sent by the server. + the serial number of the ACK message (the serial number of the SYN+ACK message sent by the server is equal to the serial number of the SYN packet sent by the client proxy device as the proxy client), and the SYN+ACK sent by the client proxy device as the proxy server
  • the serial number of the message (the confirmation number of the SYN+ACK message sent by the client proxy device as a proxy server is equal to the serial number of the SYN message sent by the application client).
  • the proxy device at the client side determines the difference between the serial number and the confirmation number of the message before and after forwarding.
  • SEQ_REQ_OFFSET to represent the sequence number difference before and after the client proxy device forwards the message from the application client
  • the value of SEQ_REQ_OFFSET is the sequence number of the SYN packet sent by the client proxy device as a proxy client and the SYN sent by the application client The difference between the sequence numbers of the packages.
  • ACK_REQ_OFFSET represents the difference between the confirmation numbers before and after the client proxy device forwards the message from the application client
  • the value of ACK_REQ_OFFSET is the confirmation number of the SYN packet sent by the client proxy device as the proxy client and the SYN sent by the application client The difference between the acknowledgment numbers of the packages.
  • ACK_REQ_OFFSET PC_SYN_ACK - C_SYN_ACK
  • SEQ_RESP_OFFSET to represent the sequence number difference before and after the client proxy device forwards the message from the server
  • the value of SEQ_RESP_OFFSET is the sequence number of the SYN+ACK message sent by the client proxy device as a proxy server and the SYN sent by the server + The difference between the sequence numbers of the ACK packets.
  • SEQ_RESP_OFFSET PS_SYN + ACK_SEQ - S_SYN + ACK_SEQ
  • ACK_RESP_OFFSET represents the difference between the confirmation numbers before and after the client proxy device forwards the message from the server. The difference between the confirmation numbers of ACK packets.
  • the confirmation number of the SYN+ACK message sent by the client agent device as a proxy server is equal to the serial number of the SYN message sent by the application client, and at the same time, the confirmation number of the SYN+ACK message sent by the server is equal to the serial number of the client agent.
  • client agent device uses the above difference value to adjust the serial number and confirmation number of the service message sent by the application client (referred to as “client service message") during the stream mode message forwarding process, and The sequence number and confirmation number of the server's service message in response to the client service message (referred to as “server service message”) are adjusted.
  • FIG. 10 is a detailed schematic diagram of the adjustment of the forwarded message by the client proxy device provided by the embodiment of the present application.
  • FIG. 10 from left to right are the application client, the client proxy device and the gateway device. Wherein the application client and the client proxy device are located in the terminal device.
  • the application client in FIG. 10 is located in terminal device A or terminal device B in FIG. 6 , or is the application client in FIG. 8 or 9 , such as the aforementioned FTPS client FileZilla.
  • the client proxy device in FIG. 10 is the client proxy device A or client proxy device B in FIG. 6 , or the client proxy device in FIG. 8 or FIG. 9 .
  • the gateway device in FIG. 10 is the gateway device in FIG. 6 , FIG. 7 or FIG. 8 .
  • the client proxy device adjusts the message sent by the application client after the three-way handshake.
  • the serial number of the message sent by the application client (represented by TCP_packet A) is represented by C_SEQ, and the confirmation number is represented by C_ACK.
  • the client proxy device adjusts the sequence number and acknowledgment number of TCP_packet A to obtain the message with TCP_packet B.
  • the client proxy device forwards the serial number C_SEQ of TCP_packet A with the sequence number difference SEQ_REQ_OFFSET before and after the client proxy device forwards the message from the application client, and the offset caused by increasing the length of the TLS option field (marked as TLS_OptionLen) Add up to get the serial number of TCP_packet B. That is, the value of the serial number of TCP_packet B is C_SEQ+SEQ_REQ_OFFSET+TLS_OptionLen.
  • the client proxy device adds the acknowledgment number C_ACK of TCP_packet A to the acknowledgment number difference ACK_REQ_OFFSET before and after the client proxy device forwards the message from the application client to obtain the acknowledgment number of TCP_packet B. That is, the value of the confirmation number of TCP_packet B is C_ACK+ACK_REQ_OFFSET.
  • the process of the client proxy device adjusting the message sent by the gateway device after the three-way handshake will be described.
  • the sequence number of the message (represented by TCP_packet C) sent by the gateway device is represented by S_SEQ
  • the confirmation number is represented by S_ACK.
  • the client proxy device adjusts the sequence number and confirmation number of TCP_packet C to obtain a message with TCP_packet D.
  • the client agent device adds the sequence number S_SEQ of TCP_packet C to the sequence number difference SEQ_RESP_OFFSET before and after the above-mentioned client agent device forwards the message from the server, to obtain the sequence number of TCP_packet D. That is, the value of the serial number of TCP_packet D is S_SEQ+SEQ_RESP_OFFSET.
  • the client proxy device adds the acknowledgment number S_ACK of TCP_packet C to the difference ACK_REQ_OFFSET before and after the client proxy device forwards the message from the application client, and then subtracts the offset caused by the length of the TLS option field (record TLS_OptionLen), get the confirmation number of TCP_packet D. That is, the value of the confirmation number of TCP_packet B is S_ACK+ACK_RESP_OFFSET-TLS_OptionLen.
  • Figure 11 is a flow chart of the access control method provided by the embodiment of the present application, including steps 111 to 115.
  • Both Fig. 11 and Fig. 7 describe the access control method provided by the embodiment of the present application from the perspective of the client agent device.
  • Figure 7 takes the first negotiation message sent by the first application client on the terminal device as an example, and the access control method when the session to be created meets the encryption strength requirements
  • the accompanying drawing 11 takes the second negotiation message sent by the second application client on the terminal device as an example to illustrate the access control method in the case that the session to be created does not meet the encryption strength requirements, as a reference to the accompanying drawing
  • the application scenario of Fig. 11 is similar to that of Fig. 7 and will not be repeated here.
  • Step 111 the client agent device intercepts the second negotiation message, the second negotiation message comes from the second application client on the terminal device, and is used to negotiate and establish a second session with the second server, the second The second session does not meet the encryption strength requirements.
  • the client proxy device or other components determine whether the session to be created meets the encryption strength requirement. For example, in the case that the client proxy device determines whether the session to be created meets the encryption strength requirement, the client proxy device intercepts the session negotiation message generated by the application client, and executes the session negotiation message shown in step 111a on the session negotiation message. A step of. In the case that other components determine whether the session to be created meets the encryption strength requirement, after other components perform the steps shown in step 111a on the intercepted session negotiation message, the negotiation of the session to be created that does not meet the encryption strength requirement The message is sent to the client proxy device.
  • the second negotiation message is, for example, a session negotiation message sent when the telnet client initiates creating a second session with the telnet server.
  • Step 111a judging whether the session to be created meets the encryption strength requirement according to the intercepted session negotiation message.
  • the user enters a command in the telnet client, such as "telnet 192.168.10.132", where 192.168.10.132 is the IP address of the telnet server.
  • the telnet client establishes a TCP connection with the telnet server through a three-way handshake, and then prompts the user to enter the user name and password to log in to the telnet server.
  • the user can enter control commands in the telnet client, such as the ls command used to display the directory list.
  • the second negotiation packet is a SYN packet.
  • the client proxy device determines according to the second negotiation message that the session created through negotiation is a non-encrypted application, and in this case, the encryption requirement is not met.
  • the client agent device judges that the second session does not meet the encryption strength requirement according to the second negotiation message, and then executes step 112 .
  • Step 112 the client proxy device performs tunnel encapsulation on the second negotiation message to obtain a tunnel negotiation message, and the header of the tunnel negotiation message includes authentication information corresponding to the second application client.
  • the tunnel negotiation message is used to negotiate and establish an encrypted tunnel between the client agent device and the gateway device.
  • Step 113 the client agent device sends the tunnel negotiation packet to the gateway device.
  • the client proxy device and the gateway device perform tunnel negotiation, and negotiate to establish an encrypted tunnel between the client proxy device and the gateway device.
  • the TLS tunnel or the HTTPS tunnel shown in Fig. 3 or Fig. 4 the client agent device carries authentication information in the TLS Option field of the Client Hello message.
  • the client proxy device carries authentication information in the Connect field and the cookie field of the application layer message header
  • the authentication information is carried in the tunnel negotiation message, so that the gateway device can use the authentication information carried in the tunnel negotiation message to authenticate the terminal device and the user;
  • the service packets of the telnet client and the service packets returned by the telnet server meet the link security requirements.
  • the client proxy device After the client proxy device sends the tunnel negotiation message, it receives a tunnel establishment success message correspondingly sent by the gateway device, and the tunnel establishment success message indicates that the encrypted tunnel is established successfully.
  • Step 114 after the encrypted tunnel is established successfully, the client agent device transmits subsequent packets of the second session through the encrypted tunnel.
  • the client proxy device sends subsequent packets of the second session from the second application client to the gateway device through the encrypted tunnel.
  • the client agent device intercepts the subsequent message of the second session from the second application client
  • the encrypted tunnel established through negotiation in step 114 performs the encryption on the second session from the second application client.
  • Subsequent packets of the second session are encapsulated to obtain tunnel packets, and the tunnel packets are sent to the gateway device.
  • the gateway device decapsulates the tunnel packet after receiving the tunnel packet, and sends the decapsulated packet to the second server.
  • the client proxy device receives subsequent packets of the second session from the gateway device through the encrypted tunnel.
  • the client agent device receives the tunnel message from the gateway device, decapsulates the received tunnel message to obtain the subsequent message of the second session from the second server, and sends the The second application client sends the decapsulated subsequent packet of the second session from the gateway device.
  • step 111 is basically similar to step 701 in accompanying drawing 7, and the authentication information process involved in step 112 is also similar to the authentication information involved in step 702 in accompanying drawing 7, please refer to the above-mentioned The relevant description of step 701 and step 702 in the embodiment will not be repeated here.
  • the client proxy device intercepts the session negotiation message of the session initiated by the second application client that does not meet the encryption strength requirements, it negotiates with the gateway device to establish an additional encrypted tunnel.
  • the tunnel negotiation message carries the authentication information, so that the gateway device can use the authentication information carried in the tunnel negotiation message to authenticate the terminal device and the user.
  • the encrypted tunnel established through the negotiation encapsulates the application client and server The business packets in clear text form between them are guaranteed to meet the link security requirements.
  • Figure 12 is a flow chart of the access control method provided by the embodiment of the present application, including steps 121 to 126.
  • the flow chart shown in FIG. 12 mainly describes the access control method provided by the embodiment of the present application from the perspective of a gateway device.
  • the gateway device in the embodiment described in Fig. 12 is the gateway device in the embodiment described in Fig. 6 to Fig. 11 .
  • the gateway device in Fig. 12 cooperates with the terminal device or server in the embodiment described in Fig. 6 to Fig. 11 to implement access control to the terminal device.
  • Step 121 the gateway device receives a first negotiation message, the first negotiation message comes from the proxy device of the first client, and is used to negotiate and establish a first session, and the first session is between the first terminal device and the first server In the session between, the first client proxy device runs on the first terminal device, and the transport layer header of the first negotiation message carries authentication information.
  • the gateway device after receiving the first negotiation message, the gateway device first determines whether the transport layer header of the first negotiation message carries authentication information. For example, the gateway device performs protocol analysis on the first negotiation message, and tries to obtain the authentication information in the transport layer header of the first negotiation message. For example, when the first negotiation message is a Client Hello message, the gateway device judges whether there is a TLS Option in the transport layer header of the Client Hello message. authentication information.
  • the gateway device judges whether there is a TLS Option in the transport layer header of the Client Hello message. authentication information.
  • the description of the authentication information please refer to the description in step 702 of FIG. 7 , and the description will not be repeated here.
  • the gateway device executes step 122 .
  • Step 122 the gateway device initiates first authentication according to the authentication information.
  • an authentication method is that the gateway device compares the authentication information obtained from the transport layer header of the first negotiation message with the control policy corresponding to the legal user issued by the previous controller, and determines that the first Whether the originator (user and terminal device) of the negotiation message is allowed to access the requested service.
  • each policy in the control policy corresponding to the legal user includes a matching condition and an action
  • the matching condition includes one or more of the following: a token of a legal user, an identifier of a legal terminal device, the legal user can The token of the application used and the address information of the servers that the legitimate user is allowed to access.
  • Actions include one or more of the following: allow access, bill, and limit traffic.
  • another authentication method is that the gateway device sends the authentication information obtained from the header of the transport layer packet of the first negotiation packet to the controller, and receives the authentication result returned by the controller.
  • the controller dynamically determines the authentication result according to the stored policy and other authentication-related information, such as the network topology state and the state of each related resource (such as the current working state of the first server, etc.).
  • the gateway device performs step 123 , step 125 and step 126 .
  • the gateway device performs step 124.
  • Step 123 the gateway device does not perform tunnel decapsulation on the first negotiation packet, and forwards the first negotiation packet to the first server, so as to establish a first connection, and the first connection is the gateway device connection with the first server.
  • not performing tunnel decapsulation on the first negotiation message refers to not removing the tunnel header of the first negotiation message, which is also called “skip tunnel decapsulation” or “omit tunnel decapsulation”. ".
  • the gateway device does not tunnel decapsulate the first negotiation packet according to the indication information carried in the first negotiation packet.
  • the indication information please refer to the description in step 702 of the related embodiment of FIG. 7 , and details will not be described here.
  • forwarding the first negotiation packet to the first server at least includes: the gateway device directly forwarding the first negotiation packet to the first server; or, the gateway device deleting the authentication information from the first negotiation packet Afterwards, the first negotiation packet with the deleted authentication information is forwarded to the first server. Since the authentication information is carried in the header of the transport layer, only deleting the authentication information does not require tunnel decapsulation.
  • the gateway device directly forwards the Client Hello message carrying the authentication information in the TLS Option field to the first server in step 123, or removes the TLS Option field from the Client Hello message, Send the Client Hello message with the TLS Option field removed to the first server.
  • the gateway device after step 123, in addition to establishing the above-mentioned first connection, the gateway device also establishes a connection between the gateway device and the first client proxy device.
  • the gateway device and the first client proxy device The connection between the devices is simply referred to as the second connection. Execute step 125 to step 126.
  • Step 125 after the first authentication is successful, the second connection is successfully established.
  • Step 126 the gateway device transmits subsequent packets of the first session through the first connection and the second connection. Specifically, the gateway device receives the subsequent packets of the first session sent by the proxy device of the first client through the second connection, and forwards the packets from the first session to the first server through the first connection. a subsequent message of the first session of the first client proxy device;
  • Step 124 the gateway device terminates establishing the second connection. That is, the gateway device closes the connection between the gateway device and the first client proxy device for transmitting the first negotiation packet.
  • the gateway device successfully authenticates the terminal device and the user according to the authentication information carried in the modified session negotiation message, there is no need to establish an additional encrypted tunnel between the first client agent device and the gateway device to
  • the transmission of the subsequent service packets of the first session saves the processing resources consumed by the terminal device and the gateway device for performing the tunnel encapsulation or decapsulation process, as well as the encryption and decryption processing that may be involved, thereby reducing the cost of the terminal device and the gateway device.
  • the performance overhead of the gateway device helps to improve the overall performance of the access control system.
  • the gateway device relays and forwards subsequent service packets of the session created between the first application client and the server.
  • the gateway device forwards packets in proxy mode.
  • the proxy mode is basically similar to the proxy mode when the proxy device on the client side forwards messages. Please refer to the related description of step 705 in the embodiment shown in FIG.
  • Figure 13 is a flow chart of the access control method provided by the embodiment of the present application, including steps 131 to 135. Both Figure 13 and Figure 12 describe the access control method provided by the embodiment of the present application from the perspective of a gateway device.
  • the difference between Fig. 13 and Fig. 12 is that Fig. 12 illustrates the access control method when the authentication information is carried in the transport layer header of the session negotiation message, while Fig. 13 illustrates the session negotiation
  • the access control method in the case that the header of the transport layer of the message does not carry the authentication information is described as an optional supplement to the embodiment described in FIG. 12 .
  • the gateway device receives a second negotiation message from the proxy device of the second client, and is used for negotiating and establishing a second session with the second server.
  • the second client proxy device runs on the second terminal device, and the transport layer header of the second negotiation message does not carry authentication information.
  • the second terminal device in Figure 13 and the first terminal in Figure 12 can be the same terminal device or different terminal devices, the second client agent device in Figure 13 and the first client agent device in Figure 12 can be the same client agent device or different client agents device.
  • the gateway device uses a method similar to that in step 121 to determine that the header of the transport layer packet of the second negotiation packet does not carry authentication information.
  • the gateway device performs protocol analysis on the second negotiation message, and confirms whether the session negotiation message is a predetermined protocol or a predetermined message format. For example, when the second negotiation message is a Client Hello message, the gateway device tries to obtain the authentication information carried in it from the TLS Option field of the Client Hello message. If there is no TLS Option field in the Client Hello message, it is determined that the Client Hello message does not carry authentication information.
  • the transport layer header of the second negotiation message does not carry authentication information, it means that the client proxy device failed to multiplex the session negotiation message to transmit the authentication information.
  • the session negotiation message actually The above is the message sent by the client proxy device to initiate the creation of an additional encrypted tunnel.
  • the gateway device performs step 132 .
  • step 131 is basically similar to that of accompanying drawing 121, and the implementation process of step 132 is also similar to that of accompanying drawing 122.
  • step 121 and step 122 are also similar to that of accompanying drawing 122.
  • Step 132 the gateway device obtains the authentication information from the application layer header of the second negotiation message, and initiates the second authentication according to the authentication information obtained from the application layer header of the second negotiation message .
  • the application layer message header includes but not limited to the HTTP message header.
  • the application layer message header may also be a message header of other encrypted applications.
  • the client proxy device carries the address information of the real server in the Connect field of the HTTP header, and carries the token information in the Cookie field
  • the gateway device uses the data read from the Connect field and the Cookie field as authentication information.
  • step 122 in FIG. 12 For details about the authentication process, please refer to the description of step 122 in FIG. 12 , which will not be described in detail here.
  • the gateway device performs step 133 , step 134 and step 135 ; if the second authentication fails, the gateway device performs step 136 .
  • Step 133 the gateway device decapsulates the second negotiation message through the tunnel, and sends the decapsulated message to the second server, so as to establish a third connection, the third connection is between the gateway device and a connection between the second servers.
  • Step 134 the gateway device establishes an encrypted tunnel between the gateway device and the second client agent device.
  • Step 135 the gateway device transmits subsequent packets of the second session through the encrypted tunnel and the third connection.
  • the gateway device receives a subsequent packet of the second session subsequently sent by the proxy device of the second client through the encrypted tunnel.
  • the gateway device decapsulates the received tunnel to obtain subsequent packets of the second session from the second client proxy device, and forwards the packets from the second session to the second server through the third connection. Subsequent messages of the second session of the second client proxy device.
  • the gateway device receives the subsequent packet of the second session from the second server through the third connection, wherein the subsequent packet of the second session from the second server responds to the Subsequent packets of the second session with the second client proxy device. After performing tunnel encapsulation on the subsequent packets of the second session from the second server, the gateway device sends the encapsulated tunnel packets to the second client agent device.
  • Step 136 the gateway device terminates establishing the encrypted tunnel with the second client agent device.
  • the gateway device when the gateway device fails to obtain the authentication information from the packet header of the session negotiation packet, the gateway device obtains the authentication information from the application layer packet header of the session negotiation packet actually used as the tunnel negotiation packet. to obtain authentication information. In the case of successful authentication, the gateway device transmits the clear text service message between the application client and the server through an additional encrypted tunnel established between the client agent device and the client device, so as to ensure that the link security requirements are met.
  • FIG. 14 is a schematic diagram of the access control method provided by the embodiment of the present application.
  • FIG. 14 illustrates the interaction process among the application client, the client agent device, the gateway device, the server, and the controller when the session to be created meets the encryption strength requirement in the form of a sequence diagram.
  • Figure 14, Figure 7, and Figure 12 describe the access control method in the same scenario, that is, when the session to be created meets the encryption strength requirements from different angles, these embodiments can be referred to each other, similar details Detailed description will not be repeated.
  • the FTPS client on the terminal device initiates session creation to the FTPS server.
  • the session negotiation packet sent by the FTPS client is a Client Hello message.
  • the client proxy device on the same terminal device determines that the negotiated session meets the encryption strength requirements according to the information related to the encryption strength carried in the Client Hello message, such as the protocol version number and/or the cipher suite identification list, the Client Hello message A new TLS Option field is added in , and the authentication information is carried in the TLS Option field.
  • the client proxy device sends a Client Hello message carrying authentication information in the TLS Option field to the gateway device.
  • the gateway device parses the received Client Hello message, extracts the authentication information from the TLS Option field, and interacts with the controller according to the authentication information to complete the authentication. If the authentication fails, the gateway device terminates establishing a connection with the client agent device. The client proxy device then closes the connection with the FTPS client. If the authentication is successful, the gateway device establishes a connection with the FTPS server and completes the TLS handshake with the client proxy device, and the client proxy device then completes the TLS handshake with the FTPS client. The proxy device at the client side records the information needed to adjust the sequence number and confirmation number of the subsequent service message, and switches from the proxy mode to the streaming mode.
  • the client agent device intercepts the FTPS service message sent by the FTPS client (referred to as “client FTPS service message”), and adjusts the serial number and confirmation number of the client FTPS service message to obtain the adjusted client FTPS message.
  • Service message which sends the adjusted FTPS service message of the client to the gateway device.
  • the gateway device forwards the adjusted client FTPS service packet to the FTPS server.
  • the client proxy device receives the FTPS service message (referred to as "server FTPS service message") of the FTPS server response forwarded by the gateway device, adjusts the serial number and confirmation number of the server FTPS service message, and obtains the adjusted FTPS service message.
  • the FTPS service message of the server sends the adjusted FTPS service message of the FTPS server to the FTPS client.
  • FIG. 15 is a schematic diagram of the access control method provided by the embodiment of the present application.
  • FIG. 15 illustrates the interaction process among the application client, the client agent device, the gateway device, the server, and the controller in the case that the session to be created does not meet the encryption strength requirement in the form of a sequence diagram.
  • Accompanying drawing 15, accompanying drawing 11, and accompanying drawing 13 describe the access control method in the same scenario, that is, when the session to be created does not meet the encryption strength requirements from different angles, so these embodiments can be referred to each other, similar The details are not repeated in detail.
  • the telnet client on the terminal device initiates session creation to the telnet server.
  • the session negotiation packet sent by the telnet client is a SYN packet.
  • the client proxy device on the same terminal device determines, according to the session negotiation message, that the session to be created is a non-encrypted application and does not meet the encryption requirements.
  • the client agent device performs tunnel negotiation with the gateway device, and negotiates to establish an HTTPS tunnel, so as to encrypt service packets to ensure link security.
  • the client agent device carries authentication information in the Connect field and the cookie field of the HTTP header of the tunnel negotiation message (as shown in FIG. 5 ).
  • the gateway device parses the received tunnel negotiation message, extracts the authentication information from the Connect field and the cookie field of the tunnel negotiation message, and interacts with the controller according to the authentication information to complete the authentication process. If the authentication fails, the gateway device terminates establishing a connection with the client proxy device. The client proxy device then closes the connection with the telnet client. If the authentication is successful, the gateway device establishes a connection with the telnet server, and the gateway device completes the process of establishing a tunnel with the client proxy device.
  • the client agent device intercepts the telnet service message sent by the telnet client (referred to as “client telnet service message”), performs HTTPS tunnel encapsulation on the client telnet service message, and sends the encapsulated tunnel message to the gateway device.
  • the gateway device receives the tunnel message sent by the client proxy device through the HTTPS encrypted tunnel, and decapsulates the received tunnel message to obtain the client telnet service message, and forwards the decapsulated client telnet service message to the telnet server. arts.
  • the gateway device receives the telnet service message from the telnet server (referred to as "server telnet service message”), wherein the server telnet service message responds to the client telnet service message. After the gateway device performs tunnel encapsulation on the server telnet service message, it sends the encapsulated tunnel message to the telnet client agent device.
  • the client proxy device receives the tunnel message from the gateway device through the encrypted tunnel, and decapsulates the received tunnel message to obtain the server telnet service message.
  • the client agent sends the decapsulated server telnet service message to the telnet client.
  • Figure 16 is a schematic structural diagram of a terminal device provided by an embodiment of the present application.
  • the terminal device shown in FIG. 16 includes a memory 162 and at least one processor 161 .
  • the processor 161 realizes the method in the above-mentioned embodiment by reading the instruction stored in the memory 162 to generate the client proxy device, or, the processor 161 may also generate the client proxy device through the internally stored instruction to realize the above-mentioned embodiment method in .
  • the processor 161 realizes the method in the above-mentioned embodiment by reading the instruction stored in the memory 162
  • the memory 162 stores the instruction for implementing the client agent device in the above-mentioned embodiment of the present application.
  • the client proxy device generated by the terminal device with the structure shown in FIG. 16 implements the functions of the client proxy device in the solutions described in the above embodiments.
  • Carrying authentication information does not require further encrypted tunnel encapsulation, which is convenient to save the overhead caused by additional tunnel encryption and decryption.
  • the client agent device executes the functions of the client agent device described in the related embodiments in Fig. 6, Fig. 7, Fig. 9, Fig. 10, Fig. 11, Fig. 14 or Fig. 15, and cooperates with the gateway device to reduce Performance overhead of end devices and gateway devices during access control.
  • Memory 162 includes but not limited to random access memory (random access memory, RAM), read-only memory (read-only memory, ROM), erasable programmable read-only memory (erasable programmable read-only memory, EPROM), Flash memory, or optical memory, etc.
  • the code of the operating system is stored in the memory 162 .
  • the client agent device generated by the terminal device performs the following operations:
  • first negotiation message comes from a first application client on the terminal device and is used to negotiate and establish a first session, where the first session is between the first application client and a session between first servers, and the first session meets encryption strength requirements;
  • the client agent device adds the authentication information corresponding to the first application client to the transport layer header of the first negotiation message to obtain the detailed process of the modified first negotiation message,
  • the client agent device adds the authentication information corresponding to the first application client to the transport layer header of the first negotiation message to obtain the detailed process of the modified first negotiation message.
  • the terminal device shown in FIG. 16 further includes a network interface 163 .
  • the network interface 163 can be a wired interface, such as a fiber distributed data interface (Fiber Distributed Data Interface, FDDI), Gigabit Ethernet (Gigabit Ethernet, GE) interface; the network interface 163 can also be a wireless interface.
  • the network interface 163 is used for sending a message to the gateway device or receiving a message sent by the gateway device in the embodiment shown in Fig. 6 , 7 , 8 , 9 , 10 or Fig. 11 .
  • the terminal device shown in FIG. 16 further includes a bus 164, and the processor 161 and memory 162 are usually connected to each other through the bus 164, and may also be connected to each other in other ways.
  • the protection system further includes an input-output interface 165, which is used for connecting with an input device and receiving identity information input by the user through the input device.
  • Input devices include, but are not limited to, keyboards, touch screens, microphones, and the like.
  • the input and output interface 165 is also used to connect with an output device, and output log or statistical information related to the access control of the processor 161 , such as which applications fail to authenticate users, which applications succeed in user authentication, and so on.
  • Output devices include, but are not limited to, monitors, printers, and the like.
  • the client proxy device on the terminal device provided by the embodiment of the present application intercepts the session negotiation message of the session initiated by the application client and meets the encryption strength requirement, it adds authentication information to the transport layer header of the session negotiation message To obtain the modified session negotiation message, send the modified session negotiation message to the gateway device, so that the gateway device can authenticate the terminal device and the user according to the authentication information carried in the transport layer header of the session negotiation message .
  • the purpose of transmitting authentication information is achieved by multiplexing the original session negotiation message of the application client between the client agent device and the gateway device.
  • the client The agent device and the gateway device do not need to establish an additional encrypted tunnel, which saves the processing resources consumed by the additional tunnel negotiation on the terminal device and the gateway device, and helps to reduce the performance overhead of the terminal device and the gateway device.
  • FIG. 17 is a schematic structural diagram of a client agent device provided by an embodiment of the present application.
  • the client proxy device with the structure shown in FIG. 17 implements the functions of the client proxy device in the solutions described in the above embodiments.
  • the client proxy device forwards the session negotiation message to the gateway device, before forwarding the session negotiation message to the gateway device.
  • the authentication information is carried in the header of the transport layer, and there is no need for further encrypted tunnel encapsulation, which is convenient to save the overhead caused by additional tunnel encryption and decryption.
  • the client proxy device is the function of the client proxy device described in the related embodiments of FIG. 6, FIG. 7, FIG. 9, FIG. 10, FIG. 11, FIG. 14 or FIG. Reduce the performance overhead of terminal devices and gateway devices in the access control process.
  • the client agent device includes a processing module 171 and a sending module 172 .
  • the processing module 171 is configured to intercept a first negotiation message, the first negotiation message comes from a first application client on the terminal device, and is used to negotiate and establish a first session, and the first session is the A session between the first application client and the first server, and the first session satisfies the encryption strength requirement; adding the corresponding information of the first application client to the transport layer header of the first negotiation message authentication information to obtain the modified first negotiation packet.
  • a sending module 172 configured to send the modified first negotiation message to the gateway device.
  • the processing module 171 adds the authentication information corresponding to the first application client to the transport layer header of the first negotiation message to obtain the detailed process of the modified first negotiation message, or sends the first negotiation message to the gateway device
  • the detailed process of the modified first negotiation message please refer to the previous descriptions of the related embodiments in Figs.
  • the sending module 172 is further configured to transmit subsequent packets of the first session in stream mode after the first session is established successfully.
  • the processing module 171 is further configured to intercept a second negotiation message, the second negotiation message is from the second application client on the terminal device, and is used to negotiate with the second server to establish a second session, the second session does not meet the encryption strength requirements; tunnel encapsulation is performed on the second negotiation message to obtain a tunnel negotiation message, and the message header of the tunnel negotiation message includes the corresponding Authentication information, wherein the tunnel negotiation message is used to negotiate and establish an encrypted tunnel between the client agent device and the gateway device.
  • the sending module 172 is further configured to send the tunnel negotiation message to the gateway device.
  • FIG. 18 is a schematic structural diagram of a gateway device provided by an embodiment of the present application.
  • the gateway device with the structure shown in FIG. 18 implements the functions of the gateway device in the solutions described in the above embodiments.
  • the gateway device shown in Figure 18 performs the function of the gateway device described in any one of the embodiments shown in Figure 6, Figure 12, Figure 13, Figure 14 or Figure 15, and cooperates with the client agent device to reduce the Performance overhead of end devices and gateway devices during access control.
  • the gateway device shown in FIG. 18 includes a memory 182 and at least one processor 181 .
  • the processor 181 implements the methods in the foregoing embodiments by reading instructions stored in the memory 182, or, the processor 181 may implement the methods in the foregoing embodiments through internally stored instructions.
  • the processor 181 implements the methods in the above embodiments by reading the instructions stored in the memory 182
  • the memory 182 stores the instructions for implementing the methods provided in the above embodiments of the present application.
  • At least one processor 181 is one or more CPUs, or a single-core CPU, or a multi-core CPU.
  • the memory 182 includes, but is not limited to, RAM, ROM, EPROM, flash memory, or optical memory. Instructions of the operating system are stored in the memory 182 .
  • the gateway device After the program instructions stored in the memory 182 are read by the at least one processor 181, the gateway device performs the following operations:
  • the first negotiation message is from a first client proxy device and is used to negotiate and establish a first session, where the first session is a session between a first terminal device and a first server,
  • the first client proxy device runs on the first terminal device, and the transport layer header of the first negotiation message carries authentication information;
  • the first negotiation packet is not tunnel-decapsulated, and the first negotiation packet is forwarded to the first server so as to establish a first connection, and the first connection is A connection between the gateway device and the first server.
  • the gateway device obtaining the authentication information carried in the transport layer header of the first negotiation message, please refer to the previous description of the related embodiment in FIG. 12 , and the description will not be repeated here.
  • the gateway device shown in FIG. 18 further includes a network interface 183 .
  • the network interface 183 can be a wired interface, such as FDDI, GE interface; the network interface 183 can also be a wireless interface.
  • the network interface 183 is used to receive the message sent by the client proxy device in the embodiment shown in accompanying drawing 6, Fig. 12, Fig. 13, Fig. 14 or Fig. 15, or send a message to the client proxy device, or receive a message from the server The message sent, or the message sent to the server.
  • the processor 181 reads the program instructions in the memory 182, for other functions that the gateway device can perform, please refer to the descriptions in the foregoing method embodiments.
  • the terminal device shown in FIG. 18 further includes a bus 184.
  • the processor 181 and memory 182 are usually connected to each other through the bus 184, and may also be connected to each other in other ways.
  • the gateway device provided by the embodiment of the present application successfully authenticates the terminal device and the user according to the authentication information carried in the received session negotiation message, there is no need to establish an additional encrypted tunnel between the client agent device and the gateway device to transmit the session
  • the subsequent business messages of the session between the application client and the server created by the negotiation message save time spent on the terminal device and the gateway device for performing tunnel encapsulation or decapsulation process, and possible encryption and decryption processing. Consumed processing resources, thereby reducing the performance overhead of terminal devices and gateway devices, and helping to improve the overall performance of the access control system.
  • FIG. 19 is a schematic structural diagram of a gateway device provided by an embodiment of the present application.
  • the gateway device with the structure shown in FIG. 19 implements the functions of the gateway device in the solutions described in the above embodiments.
  • the gateway device shown in Figure 19 executes the function of the gateway device described in any one of the embodiments shown in Figure 6, Figure 12, Figure 13, Figure 14 or Figure 15, and cooperates with the client agent device to reduce the Performance overhead of end devices and gateway devices during access control.
  • the gateway device includes a receiving module 191 , a processing module 192 and a sending module 193 .
  • the receiving module 191 is configured to receive a first negotiation message, the first negotiation message is from the proxy device of the first client, and is used to negotiate and establish a first session, and the first session is between the first terminal device and the first For a session between servers, the first client proxy device runs on the first terminal device, and the transport layer header of the first negotiation message carries authentication information;
  • a processing module 192 configured to initiate a first authentication according to the authentication information
  • the sending module 193 is configured to forward the first negotiation message to the first server without performing tunnel decapsulation on the first negotiation message after the first authentication succeeds, so as to establish a first connection
  • the first connection is a connection between the gateway device and the first server.
  • the gateway device obtaining the authentication information carried in the transport layer header of the first negotiation message, please refer to the previous description of the related embodiment in FIG. 12 , and the description will not be repeated here.
  • processing module 192 is further configured to establish a second connection after the first authentication is successful, and the second connection is between the gateway device and the first client agent device connect;
  • the receiving module 191 is further configured to receive the subsequent message of the first session sent by the proxy device of the first client through the second connection;
  • the sending module 193 is further configured to forward the subsequent message of the first session from the first client proxy device to the first server through the first connection;
  • the receiving module 191 is further configured to receive subsequent packets of the first session from the first server through the first connection;
  • the sending module 193 is further configured to forward the subsequent packet of the first session from the first server to the first client proxy device.
  • gateway device shown in FIG. 19 can perform, please refer to the descriptions in the previous method embodiments.
  • the gateway device provided by the embodiment of the present application successfully authenticates the terminal device and the user according to the authentication information carried in the received session negotiation message, there is no need to establish an additional encrypted tunnel between the client agent device and the gateway device to transmit the session
  • the subsequent business messages of the session between the application client and the server created by the negotiation message save time spent on the terminal device and the gateway device for performing tunnel encapsulation or decapsulation process, and possible encryption and decryption processing. Consumed processing resources, thereby reducing the performance overhead of terminal devices and gateway devices, and helping to improve the overall performance of the access control system.
  • each functional module in each embodiment of the present application may be integrated into one processing module, each module may exist separately physically, or two or more modules may be integrated into one module.
  • each module in FIG. 19 can be implemented in the form of hardware or in the form of software functional units.
  • the above processing module 192 may be implemented by a software function module generated by at least one processor 181 in FIG. 18 after reading the program code stored in the memory.
  • the above-mentioned modules in FIG. 19 may also be implemented by different hardware in the gateway device.
  • the processing module 192 is implemented by a part of processing resources (such as a core in a multi-core processor) in at least one processor 191 in FIG. 18
  • the sending module 191 and the receiving module 193 are processed resources (such as other cores in a multi-core processor) by the network interface 183 of the accompanying drawing 18 and at least one processor 181 in the remaining part, or adopt FPGA or coprocessor etc. programmable device to complete.
  • the above-mentioned functional modules can also be realized by a combination of software and hardware.
  • the receiving module 191 and the sending module 193 are realized by hardware programmable devices, and the processing module 192 is generated after the CPU reads the program code stored in the memory.
  • Software function modules are implemented by a part of processing resources (such as a core in a multi-core processor) in at least one processor 191 in FIG. 18
  • the embodiment of the present application also provides an access control system, including at least one terminal device (as shown in FIG. 16 or FIG. 17 ) and a gateway device (as shown in FIG. 18 or FIG. 19 ).
  • an access control system including at least one terminal device (as shown in FIG. 16 or FIG. 17 ) and a gateway device (as shown in FIG. 18 or FIG. 19 ).
  • a gateway device as shown in FIG. 18 or FIG. 19 .
  • accompanying drawing 6 accompanying drawing 14 or drawing 15 for the schematic diagram of the access control system.
  • a computer program product refers to computer readable program code stored on a computer readable medium.
  • the computer readable medium may be a computer readable signal medium or a computer readable storage medium.
  • Computer readable storage media include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or devices, or any suitable combination of the foregoing.
  • the computer readable storage medium is random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM) or portable read only memory (CD-ROM).

Abstract

本申请实施例公开了一种访问控制方法、客户端代理装置、网关设备及相关系统，用以缓解零信任场景下终端设备或网关设备在访问控制过程中性能开销大的问题。该访问控制方法由运行于终端设备上的客户端代理装置执行。客户端代理装置截获第一协商报文，第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是所述第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求。客户端代理装置在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文；向网关设备发送修改后的第一协商报文。

Description

访问控制方法、客户端代理装置、网关设备及相关系统
本申请要求于2021年7月31日提交中国国家知识产权局、申请号为202110876797.1、申请名称为“认证方法、客户端代理装置、网关设备及认证系统”的中国专利申请、以及于2021年9月3日提交中国国家知识产权局、申请号为202111029935.9、申请名称为“访问控制方法、客户端代理装置、网关设备及相关系统”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及计算机网络技术领域，尤其涉及一种访问控制方法、客户端代理装置、网关设备及一种访问控制系统。
背景技术
零信任架构(也被称为“零信任安全模型”)不同于传统的网络边界安全信任体系，零信任架构强调“永不信任，始终验证”的原则，即默认情况下网关设备不应信任终端设备，无论这些终端设备是通过公司局域网接入的或者这些终端设备此前已经被验证过。链路安全是零信任架构中的重要方面，是指需要保证终端设备与提供资源的服务器之间所建立的会话中的数据是加密传输的，防止因网络嗅探而带来的安全问题。
零信任架构中，每条会话在保证链路安全的同时，还需要携带鉴权信息，以便于网关设备依据会话中携带的鉴权信息进行鉴权，进而确认当前请求建立的会话是否具有相应的资源访问权限，从而允许或者阻断终端设备与服务器之间建立会话。
终端设备可以通过报文的应用层字段向网关设备传递鉴权信息，例如在浏览器/服务器(Browser/Server，B/S)场景下，终端设备通过对浏览器下载到终端的小数据(cookie)的设置，在超文本传输协议(Hypertext Transfer Protocol，HTTP)报文的cookie字段中携带鉴权信息。然而，在客户端/服务器(Client/Server，C/S)场景下应用形态是非常丰富、复杂的。如果想通过报文的应用层数据传递鉴权信息，那么需要在终端设备和网关上分别对多种应用协议分别进行适配和修改，实施难度很大。
为了屏蔽各种应用的差异，有研究提出在终端设备和网关设备之间建立隧道，终端设备通过在报文上封装的隧道头来携带鉴权信息。但这种方案需要终端设备和网关设备之间建立额外的隧道，终端设备对所有应用报文进行隧道封装，网关设备需要对所有隧道报文进行解封装。由于隧道相关的封装、解封装过程、以及可能涉及到的加解密都是非常消耗处理资源的，因此给终端设备和网关设备都带来较大性能开销。
发明内容
本申请实施例提供一种访问控制方法，用以缓解零信任场景下终端设备或网关设备在访问控制过程中性能开销大的问题。
第一方面，提供了一种访问控制方法，由运行于终端设备上的客户端代理装置执行。客户端代理装置截获第一协商报文，所述第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求。所述客户端代理装置在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文；向网关设备发送修改后的第一协商报文。
在本申请实施例中，运行于终端设备上的客户端代理装置对于本终端设备上的应用客户端发起的、满足加密强度要求的会话，在向网关设备转发会话协商报文之前，不需要再做进一步的加密隧道封装，而是在该会话协商报文的传输层报文头中携带鉴权信息。这样在满足链路安全性和鉴权两方面需求的情况下，节省了因额外隧道加解密带来的开销，有助于提升终端设备和网关设备的处理性能。
可选地，在一种可能的实现方式中，客户端代理装置根据截获的会话协商报文的协议类型、携带的与加密强度有关的信息等等，确定所协商的会话是否满足加密强度要求。会话协商报文携带的与加密强度有关的信息包括但不限于协议版本号和/或加密套件标识列表等。
例如，第一会话满足加密强度要求，包括：
所述第一协商报文中携带指定协议版本号，所述指定协议版本号对应的协议版本实现的传输安全性高于预设安全性标准，所述第一会话基于所述协议版本进行数据传输。例如，其中指定协议版本号包括传输层安全(Transport Layer Security,TLS)1.2或TLS 1.3。
又例如，第一会话满足加密强度要求，包括：
所述第一协商报文包括指定加密套件标识，所述指定加密套件标识用于标识指定加密套件，所述指定加密套件实现的传输安全性高于预设安全性标准，所述第一会话基于所述指定加密套件对应用数据进行加密。
本申请实施例提供了一种根据会话协商报文中携带的信息，确定第一会话满足加密强度要求的方式，这种方式简单有效。
可选地，在一种可能的实现方式中，所述第一协商报文是TLS报文。例如，第一协商报文是客户端你好(Client Hello)消息。
可选地，在一种可能的实现方式中，网关设备对于从客户端代理装置接收到的报文，需要区分不同情况进行不同的后续处理，例如如果接收到的报文是客户端代理装置在应用客户端发送的协商报文的传输层报文头添加鉴权信息后复用的报文，由于该报文未经封装，因此网关设备无需进行解封装。为了便于网关设备的处理，所述修改后的第一协商报文的传输层报文头还包括指示信息，所述指示信息使得所述网关设备不对所述修改后的第一协商报文进行解封装。
可选地，客户端代理装置选择性地在第一协商报文的传输层报文头的不同位置添加鉴权信息。在一种可能的实现方式中，客户端代理装置在传输层报文头的传输层安全选项(Transport Layer Security Option，TLS Option)中添加鉴权信息。例如在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息，包括：在所述第一协商报文的传输层报文头中增加TLS Option字段；在所述TLS Option字段中携带所述第一应用客户端对应的鉴权信息。
可选地，在一种可能的实现方式中，所述TLS Option字段符合类型长度值(type-length-value,TLV)结构，所述TLV结构中的类型T字段用于携带指示信息，所述指示信息以使所述网关设备不对所述修改后的会话协商报文进行TLS解封装处理，所述值V字段用于携带所述鉴权信息。本申请实施例提供的这种TLS Option字段结构使得TLS Option字段能同时携带指示信息和鉴权信息，是一种较为高效的信息携带方式。
可选地，在一种可能的实现方式中，所述鉴权信息包括用户令牌和/或应用令牌。所述鉴权信息用于网关设备在每次会话建立过程中对访问发起方的身份进行鉴权。
可选地，在一种可能的实现方式中，所述鉴权信息还包括：设备标识和/或所述第一服务器的地址信息。例如，第一服务器的地址信息包括所述第一服务器的互联网协议(Internet Protocol，IP)地址和/或端口号。
可选地，在一种可能的实现方式中，在发送所述修改后的第一协商报文之前，还包括：
根据第一差值以及所述TLS Option字段的长度值修改所述第一协商报文的序列号，根据第二差值修改所述第一协商报文的确认号，从而获得所述修改后的第一协商报文，其中，所述第一差值是所述代理客户端装置作为代理客户端向所述第一服务器发送的同步报文的序列号与所述第一客户端发送的同步报文的序列号之差，所述第二差值是所述代理客户端装置作为代理客户端向所述第一服务器发送的所述同步报文的确认号与所述第一客户端发送的所述同步报文的确认号之差。
由于客户端代理装置在第一协商报文中增加了鉴权信息，因此修改后的第一协商报文的报文长度与修改之前相比发生的改变，为了降低网关设备解析修改后的第一协商报文时的差错率，客户端代理装置在第一协商报文中增加鉴权信息时，还修改第一协商报文的序列号。
可选地，在一种可能的实现方式中，所述向网关设备发送修改后的第一协商报文之后，所述方法还包括：
所述第一会话建立成功后，以流模式传输所述第一会话的后续报文。
本申请实施例客户端代理装置在第一会话建立成功之前以代理模式进行报文转发，在第一会话建立成功后，从代理模式转换为流模式传输第一会话的后续报文。流模式与代理模式相比，客户端代理装置无需维护两个独立连接的状态，因此能够进一步节省客户端代理装置上处理资源，即节省终端设备的处理资源。
可选地，在一种可能的实现方式中，以流模式传输所述第一会话的后续报文，包括：
根据第一差值修改所述来自于所述第一应用客户端的所述第一会话的后续报文的序列号，根据第二差值修改来自于所述第一应用客户端的所述第一会话的后续报文的确认号，从而获得修改后的来自于所述第一应用客户端的所述第一会话的后续报文，所述第一差值是所述代理客户端装置作为代理客户端向所述第一服务器发送的同步报文的序列号与所述第一客户端发送的同步报文的序列号之差，所述第二差值是所述代理客户端装置作为代理客户端向所述第一服务器发送的所述同步报文的确认号与所述第一客户端发送的所述同步报文的确认号之差；
向所述网关设备发送所述修改后的来自于所述第一应用客户端的所述第一会话的后续报文；
根据第三差值修改所述来自于所述网关设备的所述第一会话的后续报文的序列号，根据第四差值以及所述TLS Option字段的长度值修改所述来自于所述网关设备的所述第一会话的后续报文的确认号，从而获得修改后的来自于所述网关设备的所述第一会话的后续报文，其中，所述第三差值是所述代理客户端装置作为代理服务器向所述第一客户端发送的同步确认报文的序列号与所述第一服务器发送的同步确认报文的序列号之差，所述第四差值是所述代理客户端装置作为代理服务器向所述第一客户端发送的同步确认报文的确认号与所述第一服务器发送的同步确认报文的确认号之差；
向所述网关设备发送所述修改后的来自于所述网关设备的所述第一会话的后续报文。
可选地，在一种可能的实现方式中，所述方法还包括：
截获第二协商报文，所述第二协商报文来自于所述终端设备上的第二应用客户端、且用于与第二服务器协商建立第二会话，所述第二会话不满足加密强度要求；
对所述第二协商报文进行隧道封装得到隧道协商报文，所述隧道协商报文的报文头包括所述第二应用客户端对应的鉴权信息，其中所述隧道协商报文用于协商建立所述客户端代理装置与所述网关设备之间的加密隧道；
向所述网关设备发送所述隧道协商报文。
本申请实施例提供的访问控制方法，作为对上述应用客户端发起的、满足加密强度要求的会话的处理过程的补充，客户端代理装置对于本终端设备上的应用客户端发起的、不满足加密强度要求的会话，需要在客户端代理装置和网关设备之间建立额外的加密隧道，一方面客户端代理装置通过加密隧道对会话报文进行封装以满足链路安全性需求，另一方面通过客户端代理装置在会话协商报文上添加的隧道报文头来向网关设备传递鉴权信息，从而满足鉴权需求。从而提供了更为完善的方案，使得终端设备上的客户端代理装置能够处理各种应用客户端发起的各类会话。
可选地，第二应用客户端对应的鉴权信息被携带在隧道协商报文的报文头的不同位置上，在一种可能的实现方式中，第二应用客户端对应的鉴权信息携带在所述隧道协商报文的应用层报文头中。在其他实现方式中，第二应用客户端对应的鉴权信息携带在所述隧道协商报文的传输层报文头中。
可选地，在一种可能的实现方式中，所述应用层报文头是超文本传输协议HTTP头，所述第二应用客户端对应的鉴权信息携带在所述HTTP头的cookie字段中。
可选地，在一种可能的实现方式中，所述向所述网关设备发送隧道协商报文之后，所述方法还包括：
所述加密隧道建立成功后，通过所述加密隧道传输所述第二会话的后续报文。
对于终端设备上的应用客户端发起的、不满足加密强度要求的会话，客户端代理装置通过客户端代理装置和网关设备之间的加密隧道传输会话的后续报文，从而满足链路安全性需求。
第二方面，本申请实施例提供了一种访问控制方法。网关设备接收第一协商报文，所述第一协商报文来自于第一客户端代理装置、用于协商建立第一会话，所述第一会话是第一终端设备与第一服务器之间的会话，具体是第一终端设备上的第一应用客户端与第一服务器之间的会话。第一客户端代理装置运行于所述第一终端设备上，所述第一协商报文的传输层报文头中携带鉴权信息。网关设备接收的第一协商报文实际上是第一方面中客户端代理装置修改后的第一协商报文。网关设备根据所述鉴权信息发起第一鉴权。第一鉴权成功后，网关设备不对所述第一协商报文进行隧道解封装，向所述第一服务器转发所述第一协商报文，以便于建立第一连接，所述第一连接是所述网关设备与所述第一服务器之间的连接。
网关设备在接收到的会话协商报文的传输层报文头中携带鉴权信息的情况下，在根据传输层报文头中携带的鉴权信息鉴权成功的情况下，在无需对会话协商报文进行解封装的情况下向服务器转发会话协商报文。由于不进行隧道解封装，节省了因额外隧道加解密带来的开销，有助于提升终端设备和网关设备的处理性能。
可选地，在第二方面的一种可能的实现方式中，第一协商报文是TLS报文。例如第一协商报文是Client Hello消息。
可选地，在第二方面的一种可能的实现方式中，所述鉴权信息携带在所述第一协商报文的传输层报文头的传输层安全选项TLS Option字段中。
可选地，在第二方面的一种可能的实现方式中，所述传输层报文头中还携带指示信息，所述指示信息使得所述网关设备不对所述第一协商报文进行所述隧道解封装。
可选地，在第二方面的一种可能的实现方式中，所述TLS Option字段符合类型长度值TLV结构，所述TLV结构中的类型T字段用于携带指示信息，所述网关设备根据所述指示信息不对所述修改后的会话协商报文进行TLS解封装，所述值V字段用于携带所述鉴权信息。
可选地，在第二方面的一种可能的实现方式中，所述方法还包括：
在所述第一鉴权成功后，成功建立第二连接，所述第二连接是所述网关设备与所述第一客户端代理装置之间的连接；
通过所述第二连接接收所述第一客户端代理装置发送的所述第一会话的后续报文，通过所述第一连接向所述第一服务器转发所述来自于所述第一客户端代理装置的所述第一会话的后续报文；
通过所述第一连接接收来自于所述第一服务器的所述第一会话的后续报文；通过所述第二连接，向所述第一客户端代理装置转发所述来自于所述第一服务器的所述第一会话的后续报文。
网关设备在对会话发起方鉴权成功的情况下，通过网关设备与所述第一客户端代理装置之间的连接、以及网关设备与服务器之间的连接传输终端设备上的应用客户端和服务器之间的会话报文，从而实现了会话粒度的访问控制。
可选地，在第二方面的一种可能的实现方式中，所述方法还包括：如果所述第一鉴权失败，则网关设备终止建立所述第二连接。
可选地，在第二方面的一种可能的实现方式中，所述方法还包括：
接收第二协商报文，所述第二协商报文来自于第二客户端代理装置、用于协商建立第二会话，所述第二会话是第二终端设备与第二服务器之间的会话，所述第二客户端代理装置运行于所述第二终端设备上，所述第二协商报文的传输层报文头中未携带鉴权信息；
从所述第二协商报文应用层报文头中获取所述鉴权信息，并根据从所述第二协商报文应用层报文头中获取的鉴权信息发起第二鉴权；
根据所述第二鉴权的鉴权结果，对所述第二会话进行访问控制。
本申请实施例提供的访问控制方法，网关设备接收到会话协商报文之后，根据获取鉴权 信息的位置不同，执行不同的后续处理过程。具体地，作为对上述应用客户端发起的、满足加密强度要求的会话的处理过程的补充，网关设备在接收到的会话协商报文的传输层报文头未携带鉴权信息的情况下，从应用层报文头中获取鉴权信息从而发起鉴权。在鉴权成功的情况下，网关设备与客户端代理装置之间需要通过加密隧道实现链路安全性，因此网关设备在进行报文转发时，需要对网关设备与客户端代理装置之间传输的报文进行隧道封装或者解封装。
可选地，在第二方面的一种可能的实现方式中，所述根据所述第一鉴权过程的鉴权结果，对所述第一会话进行访问控制，包括：
如果所第二鉴权成功，则对所述第二协商报文进行隧道解封装，向所述第二服务器发送解封装得到的报文，以便于建立第三连接，所述第三连接是所述网关设备与所述第二服务器之间的连接；
建立所述网关设备与所述第二客户端代理装置之间的加密隧道；
通过所述加密隧道和所述第三连接传输所述第二会话的后续报文。
可选地，在第二方面的一种可能的实现方式中，所述根据所述第二鉴权的鉴权结果，对所述第二会话进行访问控制，包括：
如果所述第二鉴权失败，则终止建立与所述第二客户端代理装置之间的加密隧道。
第三方面，本申请实施例提供了一种客户端代理装置。该客户端代理装置运行于终端设备上，该装置包括多个功能模块，所述多个功能模块相互作用，实现上述第一方面及其各实施方式中的方法。可选地，所述多个功能模块基于软件、硬件或软件和硬件的结合实现，且所述多个功能模块基于具体实现进行任意组合或分割。
第四方面，本申请实施例提供了一种网关设备。该网关设备包括多个功能模块，所述多个功能模块相互作用，实现上述第一方面及其各实施方式中的方法。可选地，所述多个功能模块基于软件、硬件或软件和硬件的结合实现，且所述多个功能模块基于具体实现进行任意组合或分割。
第五方面，本申请实施例提供了一种终端设备，包括存储器和处理器；
所述存储器用于存储计算机指令；
所述计算机指令被所述处理器读取后，使得所述终端设备执行上述第一方面或第一方面的任意一种可能的实现方式所述的方法。
第六方面，本申请实施例提供了一种网关设备，包括存储器和处理器；
所述存储器用于存储计算机指令；
所述计算机指令被所述处理器读取后，使得所述网关设备设备执行上述第二方面或第二方面的任意一种可能的实现方式所述的方法。
第七方面，本申请实施例提供了一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被终端设备的处理器执行时，使得所述终端设备执行上述第一方面或第一方面的任意一种可能的实现方式所述的访问控制方法；或者，所述计算机指令被网关设备的处理器执行时，使得所述网关设备执行上述第二方面或第二方面的任意一种可能的实现方式所述的方法
第八方面，本申请实施例提供了一种访问控制系统，包括终端设备和网关设备，所述终端设备中运行客户端代理装置，
所述客户端代理装置，用于截获第一协商报文，所述第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是所述第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求；在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文；向所述网关设备发送修改后的第一协商报文；
所述网关设备，用于接收所述修改后的第一协商报文；根据所述修改后的第一协商报文的传输层报文头中携带的鉴权信息发起第一鉴权；所述第一鉴权成功后，不对所述第一协商报文进行隧道解封装，向所述第一服务器转发所述第一协商报文，以便于建立第一连接，所 述第一连接是所述网关设备与所述第一服务器之间的连接。
第九方面，提供了一种芯片，芯片包括可编程逻辑电路和/或程序指令，当芯片运行时，实现上述第一方面及第一方面的各实施方式的方法中客户端代理装置执行的动作。
第十方面，提供了一种芯片，芯片包括可编程逻辑电路和/或程序指令，当芯片运行时，实现上述第二方面及第二方面的各实施方式的方法中网关设备执行的动作。
第十一方面，提供了一种计算机程序产品，所述计算机程序产品包括一个或多个计算机程序指令，当所述计算机程序指令被终端设备加载并运行时，使得所述终端设备执行上述第一方面及第一方面的各实施方式的方法中终端设备执行的动作。
第十二方面，提供了一种计算机程序产品，所述计算机程序产品包括一个或多个计算机程序指令，当所述计算机程序指令被网关设备加载并运行时，使得所述网关设备执行上述第二方面及第二方面的各实施方式的方法中网关设备执行的动作。
附图说明
为了更清楚地说明本申请实施例的技术方案，下面将对实施例描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的零信任架构下的访问控制系统的示意图；
图2为本申请实施例提供的B/S场景下通过cookie携带鉴权令牌信息的示意图；
图3为本申请实施例提供的客户端代理装置和网关设备之间通过TLS隧道传递鉴权信息的示意图；
图4为本申请实施例提供的客户端代理装置和网关设备之间通过HTTPS隧道传递鉴权信息的示意图；
图5为本申请实施例提供的通过HTTP应用层报文头携带鉴权信息的示意图；
图6为本申请实施例提供的访问控制方法的应用场景示意图；
图7为本申请实施例提供的一种访问控制方法的流程图；
图8为本申请实施例提供的Client Hello消息解析结果的示意图；
图9为本申请实施例提供的应用客户端、客户端代理装置、网关设备三方连接建立过程中所需记录的报文的序列号和确认号的示意图；
图10为本申请实施例提供的客户端代理装置对所转发的报文进行调整的详细示意图；
图11为本申请实施例提供的另一种访问控制方法的流程图；
图12为本申请实施例提供的另一种访问控制方法的流程图；
图13为本申请实施例提供的另一种访问控制方法的流程图；
图14为本申请实施例提供的访问控制方法的示意图；
图15为本申请实施例提供的访问控制方法的示意图；
图16为本申请实施例提供的一种终端设备的一种结构示意图；
图17为本申请实施例提供的一种终端设备的另一种结构示意图；
图18为本申请实施例提供的一种网关设备的结构示意图；
图19为本申请实施例提供的另一种网关设备的结构示意图。
具体实施方式
如图1所示，基于零信任架构的访问控制系统中通常包括控制器、网关设备和终端设备，其中终端设备中安装有客户端代理装置。当终端设备需要访问受保护的应用资源时，客户端代理装置会先向控制器发起身份鉴权和访问控制请求，身份鉴权和访问控制通过之后控制器将向客户端代理装置发送令牌信息。客户端代理装置再向网关设备发送访问请求，并在访问请求中携带包括上述令牌信息的鉴权信息。网关设备基于访问请求中的鉴权信息对访问发起方进行鉴权，如果鉴权通过，则网关设备建立与服务器连接以传输客户端代理装置和服务器之间的后续业务报文，否则，关闭与客户端代理装置之间的连接。
在不同场景中，客户端代理装置都需要解决如何向网关设备传递鉴权信息的问题，以便 网关设备使用鉴权信息鉴别当前会话是否有相应的资源访问权限。
如图1所示，在B/S场景下，终端设备上的浏览器作为应用客户端访问Web应用。在这种场景下，客户端代理装置通过对浏览器cookie的设置，在HTTP协议头的cookie字段中携带令牌信息，如图2所示。
如图1所示，与B/S场景不同，在C/S场景下应用形态是非常丰富、复杂的。如以文件传输协议(File Transfer protocol，FTP)应用、远程登录(Telnet)应用、安全外壳(Secure Shell，SSH)协议应用、远程桌面协议(Remote Desktop Protocol，RDP)应用为例的明文类应用；如以基于安全套接层的文件传输协议(File Transfer protocol via Secure Socket Layer，FTPS)、网络套接字(Web sockets)为例的加密类应用；如以桌面云对接，小程序为例的私有协议类应用等。如果想通过报文的应用层报文头携带鉴权信息，那么需要在终端设备上对多种应用协议进行适配和修改。相应地在网关设备上也要对协议层进行对应的适配和修改以便于网关设备能够解析和识别出终端设备发送的报文中携带的鉴权信息。因此这种方案的实施难度较高，是不切实际的。
针对通过协议层适配来传递鉴权信息这一方案存在的实施难度高的问题，有研究提出如果在客户端同零信任网关之间建立隧道，将鉴权信息封装在隧道报文的报文头中。这样便不需要针对于不同的应用做协议层适配，也可以传递用于鉴权的令牌信息。具体地，客户端代理装置获取来自于同属于一个终端设备的应用客户端的业务报文后，会发起同网关设备之间的隧道建立过程，将鉴权信息封装到隧道中(下面会详细介绍针对不同隧道，如何携带鉴权信息)。网关设备在获取隧道报文时，会先进行解封装隧道报文头，从中提取相关鉴权信息并进行鉴权。如果鉴权失败，网关设备阻断该业务流量；如果鉴权通过，网关设备和提供资源的服务器(提供资源的服务器也被称为“真实服务器”，是相对于代理服务器而言的，零信任网关通过映射虚拟IP地址作为一个代理服务器，替代真实服务器与终端设备建立连接)建立连接，并对隧道流量解封装后将解封装得到的业务报文发往提供资源的服务器。通过上述过程满足C/S场景下的链路安全和实时鉴权的需求。
图3描述了客户端代理装置和网关设备之间通过TLS隧道传递鉴权信息的方案。假设受保护网络中存在三个服务器，其中，服务器A通过IP地址10.19.13.181上的7788端口提供TCP服务，服务器B通过IP地址10.88.0.2上的22端口提供SSH服务，以及服务器C通过IP地址10.88.0.2上的80端口提供Web服务。根据控制器的配置，上述三项服务均被映射为网关设备的虚拟IP地址10.0.3.11上的8443端口。客户端代理装置在终端设备访问各种应用之前，通过发起身份鉴权和访问控制过程从控制器获得本终端设备和用户允许访问的各服务被映射的虚拟IP地址和端口，以及对应的真实服务器的地址和端口号。
客户端代理装置截取终端设备上运行的各种应用发送的业务报文后，发起建立与网关设备间的TLS Tunnel。客户端代理装置将用于鉴权的令牌信息和真实服务器信息携带在首个TLS握手报文Client Hello的TLS扩展选项(Option)中。例如，定义TLS扩展类型为2000(该扩展类型不在默认的TLS选项中)。携带的数据内容解析后如下所示。
Figure PCTCN2022079432-appb-000001
网关设备提取相关的鉴权信息进行鉴权，以确认是否允许终端设备访问TLS Option字段中携带的IP地址10.80.0.2上22端口提供的服务。如果鉴权失败，则关闭网关设备与客户 端代理装置之间的当前会话；如果鉴权成功，网关设备则根据TLS Option选项中获取的真实服务器的信息(即IP地址10.80.0.2和端口号22)，发起同真实服务器的连接。然后网关设备完成与客户端代理装置之间的TLS隧道建立过程，将后续通过TLS隧道接收到的隧道报文进行TLS解封装及解密后，向真实服务器转发解封装及解密得到的业务报文。
图4描述了客户端代理装置和网关设备之间通过HTTPS隧道传递令牌信息的方案。应用场景与附图3类似，具体请参见附图3中的说明。客户端代理装置截取终端设备上运行的应用发送的业务报文后，客户端代理装置发起与网关设备间的HTTPS隧道建立过程。HTTPS也被称为HTTP over TLS/SSL。客户端代理装置将真实服务器的相关信息携带在HTTP应用层的Connect方法的统一资源标志符(Uniform Resource Identifier，URI)字段中。如图5所示，例如Connect字段的内容携带终端设备当前访问的真实服务器的IP地址10.19.13.181，端口号7788，开放的服务协议TCP。客户端代理装置将令牌信息携带在Cookie字段中，令牌信息包括应用token“aef7-a18534f3971bdcbea25-”、和/或用户token信息(图中未示出)等。
网关设备采用类似于B/S场景中的协议解析流程，获取HTTPS隧道报文的报文头中携带的令牌信息，并进行令牌鉴权，以确认是否允许终端设备访问Connect字段中携带的IP地址10.19.13.181上7788端口提供的TCP服务。如果鉴权失败，则关闭网关设备与客户端代理装置之间当前会话；如果令牌鉴权成功，则根据Connect字段中携带的真实服务器的信息(即IP地址10.19.13.181和端口号7788)，发起同真实服务器的连接。完成同客户端的HTTPS隧道建立过程，将后续通过HTTPS隧道接收到的隧道报文解封装并解密后，向真实服务器转发解封装及解密得到的业务报文。
如图3或图4所示的方案在C/S场景下，客户端代理装置均需要和网关设备之间建立新的隧道连接。客户端代理装置需要对待发送的业务报文进行封装，网关设备需要进行解封装，而本身TLS隧道或HTTPS隧道涉及的加解密是非常消耗性能的。如果终端设备上的应用客户端所要访问的应用本身就是加密协议且满足强加密要求，例如FTPS协议本身已经是TLS加密，在这种情况下完全没有必要再做一层TLS隧道封装或HTTPS Tunnel封装。对于客户端代理装置而言，创建隧道会加大性能开销；对于网关设备而言，并行处理与多个客户端代理装置之间的隧道连接，也带来较大的性能开销。
针对图3或图4所示方案存在的性能开销大的问题，本申请实施例提供了一种访问控制方法。在图3或图4所示的方案中，客户端代理装置和网关设备之间建立的隧道连接主要是出于链路安全性和鉴权两方面的考虑。本申请实施例提供的访问控制方法采用以下思路来解决这两方面的考虑。
第一方面是如何保障网络数据传输的安全性。客户端代理装置针对应用客户端发起的、满足加密强度要求的会话，在向网关设备转发会话协商报文之前，不需要再做进一步的加密隧道封装，这样便于节省因额外隧道加解密带来的开销。可选地，对于应用客户端发起的、不满足加密强度要求的会话，则再做一层加密隧道封装，例如HTTPS隧道封装，通过隧道来保证链路安全性。
第二方面是为了解决如何携带鉴权信息的问题。针对本身满足加密要求的待创建会话，客户端代理装置通过修改原有的会话协商报文的传输层报文头以携带鉴权信息，从而复用原有会话协商报文。网关设备从修改后的会话协商报文的传输层报文头中获取鉴权信息并对进行鉴权。如果当前获取的令牌信息非法，网关设备阻断网关设备与客户端代理装置之间的当前会话；如果当前获取的令牌信息合法，网关设备建立同真实服务器的连接，转发真实服务器与应用客户端之间的后续业务报文。从而解决网关设备对访问发起方的鉴权问题。这样客户端代理装置不需要对业务报文进行隧道封装，通过隧道报文头来携带令牌信息，这样便于节省因额外隧道加解密带来的开销。
下面结合各个附图对本申请实施例技术方案的主要实现原理、具体实施方式及其对应能够达到的有益效果进行详细的阐述。
附图6是本申请实施例提供的访问控制方法的应用场景的示意图。与附图1、附图3和附图4类似地，附图6所述的场景中包括访问控制系统以及受保护的应用资源。其中访问控 制系统包括控制器、网关设备和终端设备三类设备。受保护的应用资源包括受保护网络中的三个服务器，其中，服务器A通过IP地址10.19.13.181上的7788端口提供TCP服务，服务器B通过IP地址10.88.0.2上的22端口提供SSH服务，以及服务器C通过IP地址10.88.0.2上的80端口提供Web服务。根据控制器的配置，上述三项服务均被映射为网关设备的虚拟IP地址10.0.3.11上的8443端口。
控制器用于根据客户端代理装置的请求对终端设备和用户进行访问控制和身份鉴权后，向客户端代理装置下发鉴权信息以及允许访问的资源列表；以及向网关设备下发合法用户对应的控制策略，以便于网关设备根据该控制策略控制终端设备对于受保护的应用资源的访问。
终端设备中安装有客户端代理装置。客户端代理装置在终端设备访问各种应用之前，通过身份鉴权和访问控制过程还从控制器获得本终端设备和用户允许访问的各服务被映射的网关设备的虚拟IP地址和端口号，以及对应的真实服务器的地址和端口号。客户端代理装置用于截获本客户端代理装置所在的终端设备上应用客户端发送的报文，根据报文发起建立与网关设备之间的连接。
本申请实施例仅以终端设备A和终端设备B这两个终端设备为例进行说明，在有更多终端设备的情况下，其他终端设备的功能与终端设备A或终端设备B类似。终端设备A中安装客户端代理装置A，终端设备B中安装客户端代理装置B。
网关设备用于从客户端代理装置发送的流量中提取鉴权信息，发起鉴权，根据鉴权结果执行对应的动作，例如在鉴权失败时阻断网关设备与客户端代理装置之间的连接，或者在鉴权成功时与服务器建立连接，通过与服务器之间的连接传输应用客户端与服务器之间的后续业务报文。
本申请实施例主要对客户端代理装置和网关设备进行了以下改进。
本申请实施例中提供的客户端代理装置在截获到应用客户端用于创建与服务器之间的会话的会话协商报文后，针对待创建的会话满足加密强度要求的情况，在该会话协商报文的传输层报文头中添加鉴权信息以得到修改后的会话协商报文。客户端代理装置向网关设备发送修改后的会话协商报文，以便于网关设备根据修改后的会话协商报文传输层报文头中携带的鉴权信息对终端设备和用户进行鉴权。这样通过复用应用客户端发送的会话协商报文实现传递鉴权信息的目的，无需额外发起隧道建立过程，通过应用客户端发起的隧道建立过程中的会话协商报文来传递鉴权信息，从而节省了终端设备和网关设备上进行额外隧道协商所耗费的处理资源，有助于降低终端设备和网关设备的性能开销。
本申请实施例中提供的网关装置接收到来自于客户端代理装置的会话协商报文后，确定会话协商报文的传输层报文头中是否携带鉴权信息。如果会话协商报文的传输层报文头中携带鉴权信息，则网关设备根据会话协商报文的传输层报文头中携带的鉴权信息发起鉴权。在鉴权成功的情况下，不对会话协商报文进行解封装而转发。这样对于应用客户端发起的待创建的会话满足加密强度要求的情况，网关设备无需对会话协商报文进行隧道解封装，再从应用层获取鉴权信息，从而能够节约处理资源，提高鉴权效率和处理性能。
可选地，针对应用客户端和服务器之间待创建的会话满足加密强度要求的情况，在鉴权成功之后，客户端代理装置和网关设备之间可以从代理模式切换为以流模式传输后续的业务报文，无需对业务报文执行隧道传输或者代理模式转发，能够节省了终端设备和网关设备上用于执行隧道相关的封装、解封装过程、以及可能涉及到的加解密处理所耗费的处理资源，从而降低了终端设备和网关设备的性能开销，有助于提高访问控制系统的整体性能。
附图7是本申请实施例提供的访问控制方法的流程图，包括步骤701至步骤704。附图7所示的流程图主要从终端设备中客户端代理装置的角度对本申请实施例提供的访问控制方法进行说明。可选地，附图7所描述的实施例中的终端设备是附图6中的终端设备A或者终端设备B，相应地，在附图7中的终端设备是附图6的终端设备A的情况下，图7所描述的实施例中的客户端代理装置是附图6中的客户端代理装置A，在附图7中的终端设备是附图6的终端设备B的情况下，图7所描述的实施例中的客户端代理装置是附图6中的客户端代理装置B。
步骤701，客户端代理装置截获第一协商报文，所述第一协商报文来自于终端设备上的第一应用客户端，且用于协商建立与第一服务器之间的第一会话，其中第一会话满足加密强度要求。
在零信任C/S场景下，终端设备默认开启本终端设备安装的客户端代理装置，在终端设备中的应用客户端发起连接时，客户端代理装置截获应用客户端发送的会话协商报文。
在本申请实施例中，“应用客户端”是指安装在终端设备上的应用客户端软件，例如以FileZilla为例的FTP客户端软件(FileZilla即可以作为FTP客户端软件，也可以作为FTPS客户端软件)，Windows系列操作系统自带的命令行方式的telnet客户端等等。在本申请实施例中，第一协商报文例如是FileZilla客户端发起与FTPS服务器创建第一会话时，发送的会话协商报文。
可选地，客户端代理装置截获会话协商报文的方式与具体的操作系统有关。例如，Netfilter是Linux内核提供的一个框架，允许以自定义处理程序的形式实现各种与网络相关的操作。Netfilter为数据包过滤、网络地址转换和端口转换提供了各种功能和操作。在Linux操作系统中，客户端代理装置通过在NetFilter加入的Hook函数截获来自于应用客户端的会话协商报文以及后续的业务报文。
客户端代理装置作为应用客户端与网关设备之间的代理设备，以代理模式分别与应用客户端和网关设备进行通信。对于应用客户端而言，客户端代理装置作为代理服务器的角色。对于网关设备而言，客户端代理装置作为代理客户端的角色。客户端代理装置在接收到来自于应用客户端的会话协商报文之前，先与应用客户端通过三次握手过程建立TCP连接，通过建立的TCP连接接收会话协商报文。同理在步骤702之前，客户端代理装置与网关设备通过三次握手过程建立TCP连接，在步骤703中通过建立的TCP连接发送修改后的会话协商报文。
可选地，由客户端代理装置或者终端设备上的其他组件确定截获到的会话协商报文对应的待创建的会话是否满足加密强度要求。例如，在由客户端代理装置确定待创建会话是否满足加密强度要求的情况下，客户端代理装置首先截获应用客户端产生的某个会话协商报文，对截获的会话协商报文执行步骤701a所示的步骤，在待创建会话满足加密强度要求的情况下，截获的会话协商报文为第一协商报文，待创建的会话为第一会话。
在由其他组件确定第一会话是否满足加密强度要求的情况下，客户端代理装置首先截获应用客户端产生的某个报文，由其他组件对截获的会话协商报文执行步骤701a所示的步骤，在待创建会话满足加密强度要求的情况下，截获的会话协商报文是第一协商报文，待创建的会话为第一会话。
步骤701a，根据截获的会话协商报文判断待创建的会话是否满足加密强度要求。
可选地，客户端代理装置截获到会话协商报文之后，对截获的会话协商报文进行协议解析，根据会话协商报文的协议类型、携带的与加密强度有关的信息等等，判断所协商的会话是否满足加密强度要求。会话协商报文携带的与加密强度有关的信息包括但不限于协议版本号和/或加密套件标识列表。
在本申请实施例中，会话协商报文所协商创建的会话满足加密强度要求的情况包括会话协商报文所创建的会话是加密应用、和/或根据会话协商报文携带的与加密强度有关的信息确定待创建的会话的传输安全性高于预设安全性标准等等。
更具体地，会话满足加密强度要求的第一个实例是，截获的会话协商报文中携带指定协议版本号，其中所述指定协议版本号对应的协议版本实现的传输安全性高于预设安全性标准，所述第一会话基于所述协议版本进行数据传输。
会话满足加密强度要求的第二个实例是，截获的协商报文包括指定加密套件标识，所述指定加密套件标识用于标识指定加密套件，所述指定加密套件实现的传输安全性高于预设安全性标准，所述第一会话基于所述指定加密套件对应用数据进行加密。
在本申请实施例中，会话协商报文所协商创建的会话不满足加密强度要求的情况指的是除了上述满足加密强度要求的情况之外的其他情况。例如会话协商报文所协商创建的会话不满足加密强度要求的情况包括但不限于至少两种场景。第一种场景是客户端代理装置确定出 会话协商报文所创建的会话是加密应用、但是根据会话协商报文携带的与加密强度有关的信息确定待创建的会话的传输安全性低于预设安全性标准；第二种场景是客户端代理装置确定出会话协商报文所创建的会话是明文类应用，即非加密应用。
在本实施例中以第一协商报文为客户端你好(Client Hello)消息为例进行举例说明。当应用客户端为FTPS客户端时，当FTPS客户端请求与FTPS服务器建立连接时，先要协商TLS层加密参数，即协商TLS隧道。遵循现有的TLS标准，客户端和服务器之间执行握手过程来协商TLS层加密参数，在握手过程中，客户端首先向服务器发送Client Hello消息，Client Hello消息中携带协议版本号和加密套件标识列表。
客户端代理装置截获到Client Hello消息之后，解析获得Client Hello消息中携带的内容，如图8所示。图8用实线框指出了Client Hello消息的传输层协议头中携带协议版本号和加密套件标识列表，在图8所示的例子中，Client Hello消息中携带协议版本号是TLS1.2。服务器接收到Client Hello消息后，基于Client Hello消息中携带的加密套件标识列表中选择加密套件，后续使用Client Hello消息中携带的协议版本号对应的协议、以及选择出的加密套件对业务报文进行加密。
本申请实施例分别给出的客户端代理装置根据协议版本号判断所述第一会话是否满足加密强度要求的方式(方式一)，以及根据根据加密套件标识列表判断所述第一会话是否满足加密强度要求的方式(方式二)，这两种方式可以择一选用也可以结合使用。
方式一
客户端代理装置预先保存的加密强度要求包括协议版本号集合，其中协议版本号集合中的协议版本号对应的协议版本实现的传输安全性高于预设安全性标准。
客户端代理装置判断所述会话协商报文中携带的协议版本号是否属于所述协议版本号集合。如果所述会话协商报文中携带的协议版本号属于所述协议版本号集合，确定所述会话满足加密强度要求；如果所述会话协商报文中携带的协议版本号不属于所述协议版本号集合，确定所述会话不满足加密强度要求。
例如，加密强度要求包括的协议版本号集合是{TLS 1.2，TLS 1.3}，如果Client Hello消息中携带协议版本号是TLS 1.2，属于协议版本号集合，则确定待建立的会话满足加密强度要求。如果Client Hello消息中携带协议版本号是TLS 1.0，不属于协议版本号集合，则确定待建立的会话不满足加密强度要求。
方式二
客户端代理装置预先保存的加密强度要求包括加密套件标识集合，所述加密套件标识集合中的加密套件标识对应的加密套件实现的传输安全性高于预设安全性标准。
客户端代理装置判断所述第一协商报文中携带的加密套件标识列表是否包括加密套件标识集合中的加密套件标识。如果所述第一协商报文中携带的加密套件标识列表包括加密套件标识集合中的加密套件标识，客户端代理装置确定所述第一会话满足加密强度要求；如果所述第一协商报文中携带的加密套件标识列表不包括加密套件标识集合中的加密套件标识，客户端代理装置确定所述第一会话不满足加密强度要求。
例如，加密强度要求包括的加密套件标识集合是
{TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA，
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
……}，
该集合中包括了加密等级为中级或高级的加密套件标识。
如果Client Hello消息中携带的加密套件标识列表中包括上述加密套件标识集合中的一个或多个加密套件标识，则确定待建立的会话满足加密强度要求。如果Client Hello消息中携带的加密套件标识列表中不包括上述加密套件标识集合中的任意一个加密套件标识，则确定待建立的会话不满足加密强度要求。
客户端代理装置根据第一协商报文确定第一会话满足加密强度要求，执行步骤702。
步骤702，客户端代理装置在所述第一协商报文的传输层报文头中添加第一应用客户端 对应的鉴权信息以得到修改后的第一协商报文。
在应用客户端与服务器待建立的会话满足加密强度要求的情况下，说明该会话本身就是有加密机制的，可以保证链路安全性，在这种情况下客户端代理装置无需与网关设备之间建立额外加密隧道来保证链路安全性。为了传递鉴权信息，客户端代理装置可以复用原有的会话协商报文来携带鉴权信息。仍以Client Hello消息为例，客户端代理装置在Client Hello消息的传输层报文头中增加新的TLS选项(Option)字段，在新增的TLS Option字段中携带鉴权信息。一种具体的实施方式，鉴权信息包括但不限于表1所示的几项信息之一，或者这几项信息中至少两项信息的组合。
表1
Figure PCTCN2022079432-appb-000002
可选地，鉴权信息还包括时间戳、终端设备的IP地址、终端设备的当前工作状态、或安全扫描结果等等，在这里不再一一列举。
可选地，为了网关设备在传输层报文头中携带鉴权信息的情况下，与附图3所示的方案相区分，确认客户端代理装置发送的会话协商报文是在待创建会话满足加密强度要求的情况下复用的会话协商报文，或是额外封装得到的隧道报文，以便于在复用会话协商报文的情况下不再进行解封装，客户端代理装置在复用会话协商报文的情况下，采用默认或明示的方式指示网关设备不对所述第一协商报文进行隧道解封装。
例如，默认方式是，只要会话协商报文的传输层报文头中携带鉴权信息，则说明待创建会话满足加密强度要求，网关设备不对所述第一协商报文进行隧道解封装。如果待创建会话不满足加密强度要求，则客户端代理装置对会话协商报文进行隧道封装后，在隧道报文的应用层报文头中携带鉴权信息。
例如，明示方式是，客户端代理装置在待创建会话满足加密强度要求的情况下，在除了在第一协商报文的传输层报文头中携带鉴权信息，还携带指示信息。指示信息使得网关设备不对所述修改后的第一协商报文进行解封装。这里不对指示信息在传输层报文头中的具体位置进行限定。
一种具体的实施方式，本申请实施例还提供了一种携带指示信息的方式是在鉴权信息携带在TLS Option字段中的情况下，TLS Option字段符合TLV结构。其中TLV结构中的类型T字段用于携带指示信息，所述指示信息以使所述网关设备不对所述修改后的会话协商报文进行TLS解封装处理，所述值V字段用于携带所述鉴权信息。
步骤703，客户端代理装置向网关设备发送修改后的第一协商报文。
本申请实施例客户端代理装置截获到第一应用客户端发起的满足加密强度要求的会话的会话协商报文后，在会话协商报文的传输层报文头中添加鉴权信息以得到修改后的会话协商报文，向网关设备发送修改后的会话协商报文，以便于网关设备根据会话协商报文传输层报文头中携带的鉴权信息对终端设备和用户进行鉴权。这样，客户端代理装置和网关设备之间通过复用应用客户端原本的会话协商报文来实现传递鉴权信息的目的，这样在同时保证连接安全性和传递鉴权信息的前提下，客户端代理装置和网关设备无需建立额外的加密隧道，节省了终端设备和网关设备上进行额外隧道协商所耗费的处理资源，有助于降低终端设备和网关设备的性能开销。
可选地，在网关设备根据步骤703发送的修改后的第一协商报文对会话发起方进行鉴权，如果鉴权成功，则客户端代理装置执行步骤704至步骤705。
步骤704，客户端代理装置接收所述网关设备发送的协商成功报文，所述协商成功报文 指示所述第一会话建立成功。
网关设备根据步骤703中发送的修改后的会话协商报文中携带的鉴权信息对终端设备和用户鉴权成功之后，通过网关设备与客户端代理装置之间的TCP连接向客户端代理装置发送协商成功报文，从而完成与客户端代理装置之间的TLS握手。客户端代理装置通过与第一应用客户端之间的TCP连接向应用客户端发送协商成功报文，从而完成与第一应用客户端之间的TLS握手。这样第一应用客户端和第一服务器之间的会话实质上创建成功，第一应用客户端和第一服务器之间可以开始通过创建的会话传输业务报文，客户端代理装置在步骤704之后执行步骤705。
步骤705，客户端代理装置转发所述第一会话的后续业务报文。
如果网关设备根据修改后的会话协商报文中携带的鉴权信息对终端设备和用户鉴权成功，客户端代理装置无需建立额外的加密隧道来传输第一应用客户端和网关设备之间的第一会话的后续的业务报文，节省了终端设备和网关设备上用于执行隧道封装、或解封装过程、以及可能涉及到的加解密处理所耗费的处理资源，从而降低了终端设备和网关设备的性能开销，有助于提高访问控制系统的整体性能。
仍以前面FTPS客户端软件为例对第一会话的后续业务报文进行举例说明。第一会话的后续业务报文包括：FTPS客户端软件向FTPS服务器发送文件下载请求，下载请求中携带文件名以及下载路径等参数，FTPS服务器向FTPS客户端软件回应所请求的资源文件；或者FTPS客户端软件向FTPS服务器发送文件上传请求，上传请求中携带文件大小以及上传路径等参数，FTPS服务器向FTPS客户端软件回应文件上传成功或失败的结果等等。
客户端代理装置中继转发应用客户端与服务器之间所创建的会话的后续业务报文。可选地，客户端代理装置可以采用多种不同方式传输应用客户端与服务器之间会话的后续报文，本申请实施例仅以两种方式进行举例说明。
方式一
客户端代理装置继续以代理模式传输所述第一会话的后续报文。
参考前面所提及的，客户端代理装置以代理模式工作于应用客户端和网关设备之间，客户端代理装置分别维护与应用客户端之间的TCP连接，以及于网关设备之间的TCP连接。由于这两个TCP连接是通过独立的三次握手过程建立的，因此这两个TCP连接中传输的报文中的序列号和确认号是相互独立的。在步骤705之后，客户端代理装置传输应用客户端与服务器之间会话的后续报文的一种实现方式是，客户端代理装置分别通过这两个TCP连接继续对应用客户端和网关设备之间的业务报文进行传输。例如，客户端代理装置对应用客户端发送的业务报文进行传输层解析，获得传输层载荷，然后基于客户端代理装置维护的与网关设备之间的TCP连接相关的状态信息，在解析得到的传输层载荷上添加传输层报文头获得新的业务报文，再通过与网关设备之间的TCP连接向网关设备发送新的业务报文。相反方向的业务报文传输原理类似，在这里不再展开描述。
方式二
客户端代理装置以流模式，所述第一会话的后续报文。具体地，向所述网关设备转发来自于所述第一应用客户端的所述第一会话的后续报文，以及向所述第一应用客户端转发来自于所述网关设备的所述第一会话的后续报文，其中所述来自于所述网关设备的所述第一会话的后续报文响应于所述来自于所述第一应用客户端的所述第一会话的后续报文。
正如前面所提及的，在应用客户端与服务器之间待创建的会话满足加密强度要求的情况下，客户端代理装置可以复用应用客户端发送的报文而无需隧道封装。这就意味着在鉴权成功之后，客户端代理装置在后续业务报文的转发过程中，针对一次转发过程来说，向网关设备转发的业务报文(转发后的报文)与从应用客户端接收的报文(转发前的报文)所携带的数据是相同的，仅仅是报文序列(SYN)号和确认(ACK)号可能存在差异。可选地，基于这种考虑，为了进一步节省客户端代理装置上处理资源，在鉴权成功后，客户端代理装置从代理模式转换为流模式，只要在转发时对后续报文的序列号和确认号进行调整，就可以使得应用客户端和服务器在会话不中断的情况下对业务报文进行正确的重组。而不必仍然维持以代 理模式工作于应用客户端和网关设备之间。
为了得到实现流模式转发所需要的客户端代理装置转发报文时前后序列号和确认号的差值，客户端代理装置需要记录以代理模式工作时两个独立的三次握手过程中，SYN报文的顺序号和确认号、以及SYN+ACK报文的顺序号，以便于根据两个三次握手过程中相应报文的顺序号差值和确认号差值来调整后续报文的序列号和确认号。附图9是应用客户端、客户端代理装置、网关设备三方连接建立过程中所需记录的报文的序列号和确认号的示意图。
如图9所示，客户端代理装置记录应用客户端发送的SYN报文的序列号和确认号、客户端代理装置作为代理客户端发出的SYN报文的序列号和确认号、服务器发出的SYN+ACK报文的序列号(服务器发出的SYN+ACK报文的序列号等同于客户端代理装置作为代理客户端发出的SYN包的序列号)，客户端代理装置作为代理服务器发出的SYN+ACK报文的序列号(客户端代理装置作为代理服务器发出的SYN+ACK报文的确认号等同于应用客户端发出的SYN报文的序列号)。
客户端代理装置根据上述记录的信息，确定出转发前后报文的序列号差值和确认号差值。
例如，以SEQ_REQ_OFFSET代表客户端代理装置转发来自于应用客户端的报文前后的序列号差值，SEQ_REQ_OFFSET的值为客户端代理装置作为代理客户端发出的SYN包的序列号和应用客户端发出的SYN包的序列号之差。
SEQ_REQ_OFFSET＝PC_SYN_SEQ-C_SYN_SEQ
例如，以ACK_REQ_OFFSET代表客户端代理装置转发来自于应用客户端的报文前后的确认号差值，ACK_REQ_OFFSET的值为客户端代理装置作为代理客户端发出的SYN包的确认号和应用客户端发出的SYN包的确认号之差。
ACK_REQ_OFFSET＝PC_SYN_ACK-C_SYN_ACK
例如，以SEQ_RESP_OFFSET代表客户端代理装置转发来自于服务器的报文前后的序列号差值，SEQ_RESP_OFFSET的值为客户端代理装置作为代理服务器发出的SYN+ACK报文的序列号与服务端发出的SYN+ACK报文的序列号之差。
SEQ_RESP_OFFSET＝PS_SYN+ACK_SEQ-S_SYN+ACK_SEQ
例如，以ACK_RESP_OFFSET代表客户端代理装置转发来自于服务器的报文前后的确认号差值，ACK_RESP_OFFSET的值为客户端代理装置作为代理服务器发出的SYN+ACK报文的确认号与服务器发出的SYN+ACK报文的确认号之差。
ACK_RESP_OFFSET＝PS_SYN+ACK_ACK-S_SYN+ACK_ACK＝C_SYN_SEQ-PC_SYN_SEQ
由于客户端代理装置作为代理服务器发出的SYN+ACK报文的确认号等同于应用客户端发出的SYN报文的序列号，同时，服务器发出的SYN+ACK报文的确认号等同于客户端代理装置作为代理客户端发出的SYN包的序列号。因此ACK_RESP_OFFSET的值为应用客户端发出的SYN报文的序列号与客户端代理装置作为代理客户端发出的SYN包的序列号之差。
进一步，客户端代理装置在流模式报文转发过程中使用上述差值对应用客户端发送的业务报文(简称为“客户端业务报文”)的序列号和确认号进行调整，对来自于服务器的、响应于客户端业务报文的业务报文(简称为“服务器业务报文”)的序列号和确认号进行调整。图10是本申请实施例提供的客户端代理装置对所转发的报文进行调整的详细示意图。
在附图10中，从左至右方向依次是应用客户端，客户端代理装置和网关设备。其中应用客户端和客户端代理装置位于终端设备中。
可选地，图10中的应用客户端位于附图6中终端设备A或终端设备B中，或者是附图8或附图9中的应用客户端，例如前面提及的FTPS客户端FileZilla。
图10中的客户端代理装置是附图6中客户端代理装置A或客户端代理装置B，或者附图8或附图9中的客户端代理装置。
图10中的网关设备是附图6、附图7或附图8中的网关设备。
参照附图10，首先以从左到右的方向，对客户端代理装置对应用客户端发送的三次握手之后的报文进行调整的过程进行说明。假定应用客户端发送的报文(用TCP_packet A表示)的序列号用C_SEQ表示，确认号用C_ACK表示。假定客户端代理装置对TCP_packet A的序列 号和确认号调整后得到的报文用TCP_packet B表示。
客户端代理装置将TCP_packet A的序列号C_SEQ与上述客户端代理装置转发来自于应用客户端的报文前后的序列号差值SEQ_REQ_OFFSET、以及增加TLS选项字段的长度引发的偏移量(记为TLS_OptionLen)相加，得到TCP_packet B的序列号。即TCP_packet B的序列号的取值为C_SEQ+SEQ_REQ_OFFSET+TLS_OptionLen。
客户端代理装置将TCP_packet A的确认号C_ACK与上述客户端代理装置转发来自于应用客户端的报文前后的确认号差值ACK_REQ_OFFSET相加，得到TCP_packet B的确认号。即TCP_packet B的确认号的取值为C_ACK+ACK_REQ_OFFSET。
接下来以从右到左的方向，对客户端代理装置对网关设备发送的三次握手之后的报文进行调整的过程进行说明。假定网关设备发送的报文(用TCP_packet C表示)的序列号用S_SEQ表示，确认号用S_ACK表示。假定客户端代理装置对TCP_packet C的序列号和确认号调整后得到的报文用TCP_packet D表示。
客户端代理装置将TCP_packet C的序列号S_SEQ与上述客户端代理装置转发来自于服务器的报文前后的序列号差值SEQ_RESP_OFFSET相加，得到TCP_packet D的序列号。即TCP_packet D的序列号的取值为S_SEQ+SEQ_RESP_OFFSET。
客户端代理装置将TCP_packet C的确认号S_ACK与上述客户端代理装置转发来自于应用客户端的报文前后的确认号差值ACK_REQ_OFFSET相加,再减去TLS选项字段的长度引发的偏移量(记为TLS_OptionLen)，得到TCP_packet D的确认号。即TCP_packet B的确认号的取值为S_ACK+ACK_RESP_OFFSET-TLS_OptionLen。
表2对附图9和附图10中的一些符号进行简单说明。
表2
Figure PCTCN2022079432-appb-000003
附图11是本申请实施例提供的访问控制方法的流程图，包括步骤111至步骤115。附图11和附图7都是从客户端代理装置的角度对本申请实施例提供的访问控制方法进行描述。附图11与附图7的不同之处是附图7以终端设备上的第一应用客户端发送的第一协商报文为例，对待创建的会话满足加密强度要求的情况下的访问控制方法进行说明，而附图11以终端 设备上的第二应用客户端发送的第二协商报文为例，对待创建的会话不满足加密强度要求的情况下的访问控制方法进行说明，作为对附图7所描述的实施例的可选补充。附图11的应用场景与附图7类似，在这里不再重复。
步骤111，客户端代理装置截获第二协商报文，所述第二协商报文来自于终端设备上的第二应用客户端，且用于协商建立与第二服务器之间的第二会话，第二会话不满足加密强度要求。
与步骤701类似地，可选地，客户端代理装置或者其他组件来确定待创建的会话是否满足加密强度要求的步骤。例如，在由客户端代理装置确定待创建的会话是否满足加密强度要求的情况下，客户端代理装置截获应用客户端产生的会话协商报文，并对其中的会话协商报文执行步骤111a所示的步骤。在由其他组件确定待创建的会话是否满足加密强度要求的情况下，其他组件对截获的的会话协商报文执行步骤111a所示的步骤后，将不满足加密强度要求的待创建的会话的协商报文发送给客户端代理装置。
在本申请实施例中，第二协商报文例如是telnet客户端发起与telnet服务器创建第二会话时，发送的会话协商报文。
步骤111a，根据截获的会话协商报文判断待创建的会话是否满足加密强度要求。
用户在telnet客户端中输入命令，例如“telnet 192.168.10.132”,其中192.168.10.132是telnet服务器的IP地址。telnet客户端与telnet服务器通过三次握手建立TCP连接，然后提示用户输入用户名和密码来登录telnet服务器。登录成功后，用户可以在telnet客户端中输入控制命令，例如显示目录列表所用的命令ls等等。第二协商报文是SYN报文。
在本申请实施例中，客户端代理装置根据第二协商报文确定所协商创建的会话是非加密应用，这种情况下不满足加密要求。
在本申请实施中，客户端代理装置根据第二协商报文判断第二会话不满足加密强度要求，则执行步骤112。
步骤112，客户端代理装置对第二协商报文进行隧道封装得到隧道协商报文，所述隧道协商报文的报文头包括所述第二应用客户端对应的鉴权信息。该隧道协商报文用于协商建立所述客户端代理装置与所述网关设备之间的加密隧道。
步骤113，客户端代理装置向所述网关设备发送所述隧道协商报文。
可选地，在待创建的第二会话不满足加密强度要求的情况下，客户端代理装置与网关设备进行隧道协商，协商建立客户端代理装置与网关设备之间的加密隧道。例如附图3或附图4所示的TLS隧道或HTTPS隧道。如果客户端代理装置与网关设备之间建立TLS隧道，则客户端代理装置在Client Hello消息的TLS Option字段中携带鉴权信息。如果客户端代理装置与网关设备之间建立HTTPS隧道，则客户端代理装置在应用层报文头的Connect字段和cookie字段中携带鉴权信息
一方面通过隧道协商报文来携带鉴权信息，以便于网关设备利用隧道协商报文中携带的鉴权信息对终端设备和用户进行鉴权，另一方面，通过协商建立的加密隧道封装来自于telnet客户端的业务报文以及telnet服务器返回的业务报文，以满足链路安全要求。
客户端代理装置发送隧道协商报文后，接收所述网关设备对应发送的隧道建立成功报文，所述隧道建立成功报文指示所述加密隧道建立成功。
步骤114，加密隧道建立成功后，客户端代理装置通过所述加密隧道传输所述第二会话的后续报文。
一方面，客户端代理装置通过所述加密隧道向所述网关设备发送来自于所述第二应用客户端的所述第二会话的后续报文。具体地，客户端代理装置截获到来自于所述第二应用客户端的所述第二会话的后续报文后，根据步骤114协商建立的加密隧道对来自于所述第二应用客户端的所述第二会话的后续报文进行封装得到隧道报文，向网关设备发送隧道报文。可选地，网关设备接收到隧道报文后对隧道报文解封装，向第二服务器发送解封装得到的报文。
另一方面，客户端代理装置通过所述加密隧道接收来自于所述网关设备的所述第二会话的后续报文。具体地，客户端代理装置接收来自于网关设备的隧道报文，对接收到的隧道报 文进行解封装得到来自于所述第二服务器的所述第二会话的后续报文，向所述第二应用客户端发送解封装得到的所述来自于所述网关设备的所述第二会话的后续报文。
步骤111的实现过程与附图7中的步骤701基本类似，步骤112中涉及的鉴权信息程与附图7中的步骤702中涉及的鉴权信息也有类似之处，类似之处请参照上述实施例中步骤701和步骤702的相关说明，在这里不再重复说明。
本申请实施例提供的访问控制方法，客户端代理装置截获到第二应用客户端发起的不满足加密强度要求的会话的会话协商报文后，与网关设备协商建立额外的加密隧道，一方面通过隧道协商报文来携带鉴权信息，以便于网关设备利用隧道协商报文中携带的鉴权信息对终端设备和用户进行鉴权，另一方面，通过协商建立的加密隧道封装应用客户端与服务器之间的明文形式的业务报文，保证满足链路安全要求。
附图12是本申请实施例提供的访问控制方法的流程图，包括步骤121至步骤126。附图12所示的流程图主要从网关设备的角度对本申请实施例提供的访问控制方法进行说明。可选地，附图12所描述的实施例中的网关设备是附图6至附图11所描述的实施例中的网关设备。附图12中的网关设备与附图6至附图11所描述的实施例中的终端设备或者服务器相配合，实现对终端设备的访问控制。
步骤121，网关设备接收第一协商报文，所述第一协商报文来自于第一客户端代理装置、用于协商建立第一会话，所述第一会话是第一终端设备与第一服务器之间的会话，所述第一客户端代理装置运行于第一终端设备上，所述第一协商报文的传输层报文头中携带鉴权信息。
可选地，网关设备接收到第一协商报文后，首先判断第一协商报文的传输层报文头中是否携带鉴权信息。例如，网关设备对第一协商报文进行协议解析，尝试获取第一协商报文的传输层报文头中的鉴权信息。例如，当第一协商报文是Client Hello消息时，网关设备判断Client Hello消息的传输层报文头中是否存在TLS Option，如果存在TLS Option，则从Client Hello消息的TLS Option字段中获取其中携带的鉴权信息。关于鉴权信息的说明请参照附图7步骤702中的说明，在这里不重复说明。
在第一协商报文的传输层报文头中携带鉴权信息的情况下，则网关设备执行步骤122。
步骤122，网关设备根据所述鉴权信息发起第一鉴权。
鉴权实现方式有多种，本申请实施例仅以其中两种进行简单介绍。基于鉴权实现细节的调整和修改，可以得到其他多种鉴权实现方式。
可选地，一种鉴权方式是网关设备将从第一协商报文的传输层报文头中获取的鉴权信息与此前控制器下发的合法用户对应的控制策略进行比较，判断该第一协商报文的发起方(用户和终端设备)是否允许访问所请求的服务。
可选地，合法用户对应的控制策略中的每条策略中包括匹配条件和动作，匹配条件中包括以下一项或多项：一个合法用户的令牌、合法终端设备的标识、该合法用户可使用的应用的令牌以及该合法用户允许访问的服务器的地址信息。动作包括以下一项或多项：允许访问、计费和限流等。
可选地，另一种鉴权方式是网关设备向控制器发送从第一协商报文的传输层报文头中获取的鉴权信息，接收控制器返回的鉴权结果。控制器根据存储的策略以及其他鉴权相关信息，例如网络拓扑状态，各相关的资源的状态(例如第一服务器当前的工作状态等等)，动态地确定鉴权结果。
如果根据上述合法用户对应的控制策略确定该第一协商报文的发起方不允许访问所请求的服务，则确定鉴权失败，如果根据上述合法用户对应的控制策略确定该第一协商报文的发起方允许访问所请求的服务，则确定鉴权成功。
如果所述第一鉴权成功，则网关设备执行步骤123、步骤125和步骤126。
可选地，如果所述第一鉴权失败，则网关设备执行步骤124。
步骤123，网关设备不对所述第一协商报文进行隧道解封装，向所述第一服务器转发所述第一协商报文，以便于建立第一连接，所述第一连接是所述网关设备与所述第一服务器之间的连接。
在本实施例中，不对所述第一协商报文进行隧道解封装是指不去除第一协商报文的隧道报文头，也被称为“跳过隧道解封装”或者“省略隧道解封装”。
可选地，在本申请实施例中，网关设备根据第一协商报文中携带的指示信息，不对第一协商报文进行隧道解封装。关于指示信息的作用和携带方式，请参照附图7相关实施例步骤702中的描述，在这里不再详述。
可选地，向所述第一服务器转发所述第一协商报文至少包括：网关设备直接向第一服务器转发第一协商报文；或者，网关设备从第一协商报文中删除鉴权信息后，向第一服务器转发已删除鉴权信息的第一协商报文。由于鉴权信息是承载在传输层报文头中的，仅删除鉴权信息并不需要进行隧道解封装。
仍以第一协商报文是Client Hello消息为例，网关设备在步骤123中直接向第一服务器转发TLS Option字段中携带鉴权信息的Client Hello消息，或者从Client Hello消息中去除TLS Option字段，向第一服务器发送已去除TLS Option字段的Client Hello消息。
可选地，在步骤123之后，网关设备除了建立上述第一连接之外，还建立网关设备与第一客户端代理装置之间的连接，在本实施例中将网关设备与第一客户端代理装置之间的连接简称为第二连接。执行步骤125至步骤126。
步骤125，在第一鉴权成功后，成功建立第二连接。
步骤126，网关设备通过第一连接和第二连接传输第一会话的后续报文。具体地，网关设备通过所述第二连接接收所述第一客户端代理装置发送的所述第一会话的后续报文，通过所述第一连接向所述第一服务器转发所述来自于所述第一客户端代理装置的所述第一会话的后续报文；
通过所述第一连接接收来自于所述第一服务器的所述第一会话的后续报文；通过所述第二连接，向所述第一客户端代理装置转发所述来自于所述第一服务器的所述第一会话的后续报文。
步骤124，网关设备终止建立第二连接。即网关设备关闭网关设备与第一客户端代理装置之间的用于传输第一协商报文的连接。
在本申请实施例中如果网关设备根据修改后的会话协商报文中携带的鉴权信息对终端设备和用户鉴权成功，第一客户端代理装置和网关设备之间无需建立额外的加密隧道来传输第一会话的后续的业务报文，节省了终端设备和网关设备上用于执行隧道封装、或解封装过程、以及可能涉及到的加解密处理所耗费的处理资源，从而降低了终端设备和网关设备的性能开销，有助于提高访问控制系统的整体性能。
网关设备中继转发第一应用客户端与服务器之间所创建的会话的后续业务报文。可选地，网关设备以代理模式进行报文转发。代理模式与客户端代理装置转发报文时的代理模式原理基本类似，请参照附图7所示的实施例中步骤705的相关描述，在这里不再展开详述。
附图13是本申请实施例提供的访问控制方法的流程图，包括步骤131至步骤135。附图13与附图12都是从网关设备的角度对本申请实施例提供的访问控制方法进行描述。附图13与附图12的不同之处是附图12是对会话协商报文的传输层报文头中携带鉴权信息的情况下的访问控制方法进行说明，而附图13是对会话协商报文的传输层报文头中未携带鉴权信息的情况下的访问控制方法进行说明，作为对附图12所描述的实施例的可选补充。
步骤131，网关设备接收第二协商报文，所述第二协商报文来自于第二客户端代理装置，用于协商建立与第二服务器的第二会话。所述第二客户端代理装置运行于第二终端设备上，所述第二协商报文的传输层报文头中未携带鉴权信息。
可选地，由于一个终端设备上的客户端代理装置能够完成本终端上运行的多个应用客户端的零信任相关功能，因此附图13中的第二终端设备与附图12中的第一终端设备可以是同一终端设备也可以是不同终端设备，附图13中的第二客户端代理装置与附图12中的第一客户端代理装置可以是同一客户端代理装置也可以是不同客户端代理装置。
可选地，网关设备采用与步骤121中类似的方法确定第二协商报文的传输层报文头中未携带鉴权信息。网关设备对第二协商报文进行协议解析，确认该会话协商报文的是否是预定 协议或预定报文格式。例如当第二协商报文是Client Hello消息时，网关设备尝试从Client Hello消息的TLS Option字段中获取其中携带的鉴权信息。如果Client Hello消息中不存在TLS Option字段，则确定Client Hello消息未携带鉴权信息。
如果所述第二协商报文的传输层报文头中未携带鉴权信息，这说明客户端代理装置未能复用会话协商报文传递鉴权信息，在这种情况下会话协商报文实际上是客户端代理装置发起创建额外加密隧道而发送的报文。
如果所述第二协商报文的传输层报文头中未携带鉴权信息，则网关设备执行步骤132。
步骤131的实现过程与附图121基本类似，步骤132的实现过程与附图122也有类似之处，类似之处请参照上述实施例中步骤121和步骤122的相关说明，在这里不再重复说明。
步骤132，网关设备从所述第二协商报文应用层报文头中获取鉴权信息，并根据从所述第二协商报文应用层报文头中获取的鉴权信息发起第二鉴权。
可选地，在本申请实施例中应用层报文头包括但不限于HTTP报文头。当然应用层报文头也可以是其他加密应用的报文头。
例如，以应用层报文头是HTTPS报文头为例，客户端代理装置将真实服务器的地址信息携带在HTTP报文头的Connect字段中，将令牌信息携带在Cookie字段中的情况下，网关设备将从Connect字段以及Cookie字段中读取的数据作为鉴权信息。
关于鉴权过程的细节请参照附图12中步骤122的描述，在这里不再详述。
如果所述第一鉴权过程成功，则网关设备执行步骤133、步骤134和步骤135；如果所述第二鉴权失败，则网关设备执行步骤136。
步骤133，网关设备对所述第二协商报文进行隧道解封装，向所述第二服务器发送解封装得到的报文，以便于建立第三连接，所述第三连接是所述网关设备与所述第二服务器之间的连接。
步骤134，网关设备建立网关设备与所述第二客户端代理装置之间的加密隧道。
步骤135，网关设备通过所述加密隧道和所述第三连接传输所述第二会话的后续报文。
具体地，网关设备通过所述加密隧道接收所述第二客户端代理装置后续发送的第二会话的后续报文。网关设备对接收到的隧道进行解封装以获得来自于所述第二客户端代理装置的所述第二会话的后续报文，通过所述第三连接向所述第二服务器转发所述来自于所述第二客户端代理装置的所述第二会话的后续报文。
网关设备通过第三连接接收来自于所述第二服务器的所述第二会话的后续报文，其中所述来自于所述第二服务器的所述第二会话的后续报文响应于所述来自于所述第二客户端代理装置的所述第二会话的后续报文。网关设备对所述来自于所述第二服务器的所述第二会话的后续报文进行隧道封装后，向所述第二客户端代理装置发送封装获得的隧道报文。
步骤136，网关设备终止建立与所述第二客户端代理装置之间的加密隧道。
本申请实施例提供的访问控制方法，网关设备未能从会话协商报文的报文头中获取鉴权信息的情况下，从实际作为隧道协商报文的会话协商报文的应用层报文头中获取鉴权信息。在鉴权成功的情况下，网关设备通过与客户端代理装置之间额外建立的加密隧道传输应用客户端与服务器之间的明文形式的业务报文，保证满足链路安全要求。
附图14是本申请实施例提供的访问控制方法的示意图。图14以时序图的方式对待创建的会话满足加密强度要求的情况下，应用客户端、客户端代理装置、网关设备、服务器、控制器之间的交互过程进行说明。附图14与附图7、附图12分别以不同的角度，对同一场景、即待创建的会话满足加密强度要求的情况下的访问控制方法进行描述，这些实施例可以相互参照，类似的细节不重复详述。
如附图14所示，终端设备上的FTPS客户端向FTPS服务器发起创建会话。FTPS客户端发送的会话协商报文为Client Hello消息。同一终端设备上的客户端代理装置根据Client Hello消息中携带的与加密强度有关的信息，如协议版本号和/或加密套件标识列表，确定所协商的会话满足加密强度要求时，在Client Hello消息中新增TLS Option字段，在TLS Option字段中携带鉴权信息。客户端代理装置向网关设备发送TLS Option字段中携带鉴权信息的 Client Hello消息。
网关设备对接收到的Client Hello消息进行解析，从TLS Option字段中提取鉴权信息，根据鉴权信息与控制器交互从而完成鉴权。如果鉴权失败，则网关设备终止建立与客户端代理装置之间的连接。客户端代理装置继而关闭与FTPS客户端之间的连接。如果鉴权成功，则网关设备建立与FTPS服务器之间的连接以及完成与客户端代理装置之间的TLS握手，客户端代理装置继而完成与FTPS客户端之间的TLS握手。客户端代理装置记录对后续业务报文的序列号和确认号进行调整所需的信息，从代理模式切换为流模式。
客户端代理装置截获FTPS客户端发送的FTPS业务报文(简称为“客户端FTPS业务报文”)，对客户端FTPS业务报文的序列号和确认号进行调整后得到调整后的客户端FTPS业务报文，向网关设备发送调整后的客户端FTPS业务报文。网关设备向FTPS服务器转发调整后的客户端FTPS业务报文。
客户端代理装置接收网关设备转发的FTPS服务器响应的FTPS业务报文(简称为“服务器FTPS业务报文”)，对服务器FTPS业务报文的序列号和确认号进行调整后，得到调整后的FTPS服务器FTPS业务报文，向FTPS客户端发送调整后的FTPS服务器FTPS业务报文。
附图15是本申请实施例提供的访问控制方法的示意图。图15以时序图的方式对待创建的会话不满足加密强度要求的情况下，应用客户端、客户端代理装置、网关设备、服务器、控制器之间的交互过程进行说明。附图15与附图11、附图13分别以不同的角度，对同一场景、即待创建的会话不满足加密强度要求的情况下的访问控制方法进行描述，因此这些实施例可以相互参照，类似的细节不重复详述。
如附图15所示，终端设备上的telnet客户端向telnet服务器发起创建会话。telnet客户端发送的会话协商报文为SYN报文。同一终端设备上的客户端代理装置根据会话协商报文确定出待创建的会话是非加密应用，不满足加密要求。客户端代理装置与网关设备进行隧道协商，协商建立HTTPS隧道，以便于对业务报文加密以保障链路安全。客户端代理装置在隧道协商报文HTTP头的Connect字段和cookie字段中携带鉴权信息(如附图5所示)。
网关设备对接收到的隧道协商报文进行解析，从隧道协商报文的Connect字段和cookie字段中提取鉴权信息，根据鉴权信息与控制器交互从而完成鉴权过程。如果鉴权失败，则网关设备终止建立与客户端代理装置之间的连接。客户端代理装置继而关闭与telnet客户端之间的连接。如果鉴权成功，则网关设备建立与telnet服务器之间的连接，以及网关设备完成与客户端代理装置之间的隧道建立过程。
客户端代理装置截获telnet客户端发送的telnet业务报文(简称为“客户端telnet业务报文”)，对客户端telnet业务报文进行HTTPS隧道封装后向网关设备发送封装得到的隧道报文。
网关设备通过HTTPS加密隧道接收客户端代理装置发送的隧道报文，并对接收到的隧道报文进行解封装后得到客户端telnet业务报文，向telnet服务器转发解封装得到的客户端telnet业务报文。
网关设备接收来自于telnet服务器的telnet业务报文(简称为“服务器telnet业务报文”)，其中服务器telnet业务报文响应于客户端telnet业务报文。网关设备对服务器telnet业务报文进行隧道封装后，向telnet客户端代理装置发送封装获得的隧道报文。
客户端代理装置通过加密隧道接收来自于所述网关设备的隧道报文，并对接收到的隧道报文进行解封装后得到服务器telnet业务报文。客户端代理向telnet客户端发送解封装得到的服务器telnet业务报文。
附图16是本申请实施例提供的一种终端设备的结构示意图。图16所示的终端设备包括存储器162和至少一个处理器161。
可选地，处理器161通过读取存储器162中保存的指令生成客户端代理装置实现上述实施例中的方法，或者，处理器161也可以通过内部存储的指令生成客户端代理装置实现上述实施例中的方法。在处理器161通过读取存储器162中保存的指令实现上述实施例中的方法的情况下，存储器162中保存实现本申请上述实施例中客户端代理装置的指令。
具有附图16所示结构的终端设备生成的客户端代理装置实现上述实施例描述的方案中客户端代理装置的功能。该客户端代理装置针对图16的终端设备中的应用客户端发起的、满足加密强度要求的会话，在向网关设备转发会话协商报文之前，在该会话协商报文的传输层报文头中携带鉴权信息，不需要再做进一步的加密隧道封装，这样便于节省因额外隧道加解密带来的开销。可选地，该客户端代理装置执行图6、图7、图9、图10、图11、图14或图15相关实施例中描述的客户端代理装置的功能，与网关设备相互配合，降低访问控制过程中终端设备和网关设备的性能开销。
存储器162包括但不限于是随机存取存储器(random access memory，RAM)、只读存储器(read-only memory，ROM)、可擦除可编程只读存储器(erasable programmable read-only memory，EPROM)、快闪存储器、或光存储器等。存储器162中保存有操作系统的代码。
存储器162中存储的程序指令被所述至少一个处理器161读取后，终端设备生成的客户端代理装置执行以下操作：
截获第一协商报文，所述第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是所述第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求；
在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文；
向网关设备发送修改后的第一协商报文。
可选地，客户端代理装置在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文的详细过程，向网关设备发送修改后的第一协商报文的详细过程请参照前面附图7、8、9、10相关实施例的描述，在这里不再重复描述。
可选地，对于终端设备中的应用客户端发起的、不满足加密强度要求的会话的情况，终端设备对会话协商报文的处理过程请参照前面附图11以及相关实施例的描述，在这里不再重复描述。
可选地，附图16所示的终端设备还包括网络接口163。网络接口163可以是有线接口，例如光纤分布式数据接口(Fiber Distributed Data Interface，FDDI)、千兆以太网(Gigabit Ethernet，GE)接口；网络接口163也可以是无线接口。网络接口163用于在附图6、7、8、9、10或图11所示的实施例中向网关设备发送报文或接收网关设备发送的报文。
可选地，附图16所示的终端设备还包括总线164，上述处理器161、存储器162通常通过总线164相互连接，也可以采用其他方式相互连接。
可选地，防护系统还包括输入输出接口165，输入输出接口165用于与输入设备连接，接收用户通过输入设备输入的身份信息。输入设备包括但不限于键盘、触摸屏、麦克风等等。输入输出接口165还用于与输出设备连接，输出处理器161的访问控制相关的日志或统计信息，例如哪些应用的用户鉴权失败、哪些应用的用户鉴权成功等等。输出设备包括但不限于显示器、打印机等等。
本申请实施例提供的终端设备上的客户端代理装置截获到应用客户端发起的满足加密强度要求的会话的会话协商报文后，在会话协商报文的传输层报文头中添加鉴权信息以得到修改后的会话协商报文，向网关设备发送修改后的会话协商报文，以便于网关设备根据会话协商报文传输层报文头中携带的鉴权信息对终端设备和用户进行鉴权。这样，客户端代理装置和网关设备之间通过复用应用客户端原本的会话协商报文来实现传递鉴权信息的目的，这样在同时保证连接安全性和传递鉴权信息的前提下，客户端代理装置和网关设备无需建立额外的加密隧道，节省了终端设备和网关设备上进行额外隧道协商所耗费的处理资源，有助于降低终端设备和网关设备的性能开销。
图17是本申请实施例提供的一种客户端代理装置的结构示意图。具有图17所示结构的客户端代理装置实现上述各实施例描述的方案中客户端代理装置的功能。客户端代理装置针对图17所示的客户端代理装置所在的终端设备中的应用客户端发起的、满足加密强度要求的会话，在向网关设备转发会话协商报文之前，在该会话协商报文的传输层报文头中携带鉴权 信息，不需要再做进一步的加密隧道封装，这样便于节省因额外隧道加解密带来的开销。可选地，该客户端代理装置是图6、图7、图9、图10、图11、图14或图15相关实施例中描述的客户端代理装置的功能，与网关设备相互配合，能够降低访问控制过程中终端设备和网关设备的性能开销。
该客户端代理装置包括处理模块171、发送模块172。
处理模块171，用于截获第一协商报文，所述第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是所述第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求；在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文。
发送模块172，用于向网关设备发送修改后的第一协商报文。
处理模块171在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文的详细过程，或向网关设备发送修改后的第一协商报文的详细过程请参照前面附图7、8、9、10、图14相关实施例的描述，在这里不再重复描述。
可选地，发送模块172，还用于所述第一会话建立成功后，以流模式传输所述第一会话的后续报文。
可选地，处理模块171，还用于截获第二协商报文，所述第二协商报文来自于所述终端设备上的第二应用客户端、且用于与第二服务器协商建立第二会话，所述第二会话不满足加密强度要求；对所述第二协商报文进行隧道封装得到隧道协商报文，所述隧道协商报文的报文头包括所述第二应用客户端对应的鉴权信息，其中所述隧道协商报文用于协商建立所述客户端代理装置与所述网关设备之间的加密隧道。
相应地，发送模块172，还用于向所述网关设备发送所述隧道协商报文。
可选地，对于终端设备中的应用客户端发起的、不满足加密强度要求的会话的情况，终端设备对会话协商报文的处理更多详细过程请参照前面附图11、图15以及相关实施例的描述，在这里不再重复描述。
图18是本申请实施例提供的一种网关设备的结构示意图。具有附图18所示结构的网关设备实现上述实施例描述的方案中网关设备的功能。可选地，图18所示的网关设备执行图6、图12、图13、图14或图15所示任意一个实施例中描述的网关设备的功能，与客户端代理装置相互配合，能够降低访问控制过程中终端设备和网关设备的性能开销。
附图18所示的网关设备包括存储器182和至少一个处理器181。
可选地，处理器181通过读取存储器182中保存的指令实现上述实施例中的方法，或者，处理器181也可以通过内部存储的指令实现上述实施例中的方法。在处理器181通过读取存储器182中保存的指令实现上述实施例中的方法的情况下，存储器182中保存实现本申请上述实施例提供的方法的指令。
可选地，至少一个处理器181是一个或多个CPU，或者是单核CPU，也可以是多核CPU。
存储器182包括但不限于是RAM、ROM、EPROM、快闪存储器、或光存储器等。存储器182中保存有操作系统的指令。
存储器182中存储的程序指令被所述至少一个处理器181读取后，网关设备执行以下操作：
接收第一协商报文，所述第一协商报文来自于第一客户端代理装置、用于协商建立第一会话，所述第一会话是第一终端设备与第一服务器之间的会话，所述第一客户端代理装置运行于所述第一终端设备上，所述第一协商报文的传输层报文头中携带鉴权信息；
根据所述鉴权信息发起第一鉴权；
所述第一鉴权成功后，不对所述第一协商报文进行隧道解封装，向所述第一服务器转发所述第一协商报文，以便于建立第一连接，所述第一连接是所述网关设备与所述第一服务器之间的连接。
可选地，网关设备获取第一协商报文的传输层报文头中携带鉴权信息的详细过程，请参照前面附图12相关实施例的描述，在这里不再重复描述。
可选地，对于网关设备接收到终端设备发送的会传输层报文头中未携带鉴权信息的话协商报文的处理过程请参照前面附图13以及相关实施例的描述，在这里不再重复描述。
可选地，附图18所示的网关设备还包括网络接口183。网络接口183可以是有线接口，例如FDDI，GE接口；网络接口183也可以是无线接口。网络接口183用于在附图6、图12、图13、图14或图15所示的实施例中接收客户端代理装置发送的报文，或者向客户端代理装置发送报文、或者接收服务器发送的报文、或者向服务器发送报文。
处理器181读取存储器182中的程序指令后，网关设备能够执行的其他功能请参照前面各个方法实施例中的描述。
可选地，附图18所示的终端设备还包括总线184，上述处理器181、存储器182通常通过总线184相互连接，也可以采用其他方式相互连接。
本申请实施例提供的网关设备如果根据接收到的会话协商报文中携带的鉴权信息对终端设备和用户鉴权成功，客户端代理装置和网关设备之间无需建立额外的加密隧道来传输会话协商报文所创建的应用客户端与服务器之间的会话的后续的业务报文，节省了终端设备和网关设备上用于执行隧道封装、或解封装过程、以及可能涉及到的加解密处理所耗费的处理资源，从而降低了终端设备和网关设备的性能开销，有助于提高访问控制系统的整体性能。
图19是本申请实施例提供的一种网关设备的结构示意图。具有图19所示结构的网关设备实现上述实施例描述的方案中网关设备的功能。可选地，图19所示的网关设备执行图6、图12、图13、图14或图15所示任意一个实施例中描述的网关设备的功能，与客户端代理装置相互配合，能够降低访问控制过程中终端设备和网关设备的性能开销。
该网关设备包括接收模块191、处理模块192和发送模块193。
接收模块191，用于接收第一协商报文，所述第一协商报文来自于第一客户端代理装置、用于协商建立第一会话，所述第一会话是第一终端设备与第一服务器之间的会话，所述第一客户端代理装置运行于所述第一终端设备上，所述第一协商报文的传输层报文头中携带鉴权信息；
处理模块192，用于根据所述鉴权信息发起第一鉴权；
发送模块193，用于所述第一鉴权成功后，不对所述第一协商报文进行隧道解封装，向所述第一服务器转发所述第一协商报文，以便于建立第一连接，所述第一连接是所述网关设备与所述第一服务器之间的连接。
可选地，网关设备获取第一协商报文的传输层报文头中携带鉴权信息的详细过程，请参照前面附图12相关实施例的描述，在这里不再重复描述。
可选地，所述处理模块192，还用于在所述第一鉴权成功后，建立第二连接，所述第二连接是所述网关设备与所述第一客户端代理装置之间的连接；
所述接收模块191，还用于通过所述第二连接接收所述第一客户端代理装置发送的所述第一会话的后续报文；
所述发送模块193，还用于通过所述第一连接向所述第一服务器转发所述来自于所述第一客户端代理装置的所述第一会话的后续报文；
所述接收模块191，还用于通过所述第一连接接收来自于所述第一服务器的所述第一会话的后续报文；
所述发送模块193，还用于向所述第一客户端代理装置转发所述来自于所述第一服务器的所述第一会话的后续报文。
可选地，对于网关设备接收到终端设备发送的会传输层报文头中未携带鉴权信息的话协商报文的处理过程请参照前面附图13以及相关实施例的描述，在这里不再重复描述。
附图19所示的网关设备能够执行的其他功能请参照前面各个方法实施例中的描述。
本申请实施例提供的网关设备如果根据接收到的会话协商报文中携带的鉴权信息对终端设备和用户鉴权成功，客户端代理装置和网关设备之间无需建立额外的加密隧道来传输会话协商报文所创建的应用客户端与服务器之间的会话的后续的业务报文，节省了终端设备和网关设备上用于执行隧道封装、或解封装过程、以及可能涉及到的加解密处理所耗费的处理资 源，从而降低了终端设备和网关设备的性能开销，有助于提高访问控制系统的整体性能。
附图17或图19所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。在本申请各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。例如，附图19中的各个模块既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。例如，采用软件实现时，上述处理模块192可以是由附图18中的至少一个处理器181读取存储器中存储的程序代码后，生成的软件功能模块来实现。图19中上述各个模块也可以由网关设备中的不同硬件分别实现，例如处理模块192由附图18中至少一个处理器191中的一部分处理资源(例如多核处理器中的一个核)实现，而发送模块191和接收模块193由附图18的网络接口183和中至少一个处理器181中的其余部分处理资源(例如多核处理器中的其他核)，或者采用FPGA、或协处理器等可编程器件来完成。显然上述功能模块也可以采用软件硬件相结合的方式来实现，例如接收模块191和发送模块193由硬件可编程器件实现，而处理模块192是由CPU读取存储器中存储的程序代码后，生成的软件功能模块。
本申请实施例还提供了一种访问控制系统，包括至少一个终端设备(如附图16或附图17所示)和网关设备(如附图18或附图19所示)。该访问控制系统的示意图请参考附图6、附图14或图15。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
本领域普通技术人员将会理解，本申请的各个方面、或各个方面的可能实现方式可以被具体实施为计算机程序产品。计算机程序产品是指存储在计算机可读介质中的计算机可读程序代码。
计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质包括但不限于电子、磁性、光学、电磁、红外或半导体系统、设备或者装置，或者前述的任意适当组合。如计算机可读存储介质为随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM)或便携式只读存储器(CD-ROM)。
显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的范围。这样，倘若本申请的这些修改和变型属于本发明权利要求的范围之内，则本发明也意图包括这些改动和变型在内。

Claims (47)

  1. 一种访问控制方法，其特征在于，由运行于终端设备上的客户端代理装置执行，所述方法包括：
    截获第一协商报文，所述第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是所述第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求；
    在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文；
    向网关设备发送修改后的第一协商报文。
  2. 根据权利要求1所述的方法，其特征在于，所述第一会话满足加密强度要求，包括：
    所述第一协商报文中携带指定协议版本号，所述指定协议版本号对应的协议版本实现的传输安全性高于预设安全性标准，所述第一会话基于所述协议版本进行数据传输。
  3. 根据权利要求2所述的方法，其特征在于，所述指定协议版本号包括传输层安全TLS 1.2或TLS 1.3。
  4. 根据权利要求1-3任一项所述的方法，其特征在于，所述第一会话满足加密强度要求，包括：
    所述第一协商报文包括指定加密套件标识，所述指定加密套件标识用于标识指定加密套件，所述指定加密套件实现的传输安全性高于预设安全性标准，所述第一会话基于所述指定加密套件对应用数据进行加密。
  5. 根据权利要求1至4任一所述的方法，其特征在于，所述第一协商报文是TLS报文。
  6. 根据权利要求5所述的方法，其特征在于，所述第一协商报文是客户端你好Client Hello消息。
  7. 根据权利要求1-6任一项所述的方法，其特征在于，所述修改后的第一协商报文的传输层报文头还包括指示信息，所述指示信息使得所述网关设备不对所述修改后的第一协商报文进行解封装。
  8. 根据权利要求1-6任一项所述的方法，其特征在于，所述在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息，包括：
    在所述第一协商报文的传输层报文头中增加传输层安全选项TLS Option字段；
    在所述TLS Option字段中携带所述第一应用客户端对应的鉴权信息。
  9. 根据权利要求8所述的方法，其特征在于，所述TLS Option字段符合类型长度值TLV结构，所述TLV结构中的类型T字段用于携带指示信息，所述指示信息以使所述网关设备不对所述修改后的会话协商报文进行TLS解封装处理，所述值V字段用于携带所述鉴权信息。
  10. 根据权利要求1-9任一项所述的方法，其特征在于，所述鉴权信息包括用户令牌和/或应用令牌。
  11. 根据权利要求10所述的方法，其特征在于，所述鉴权信息还包括：
    设备标识和/或所述第一服务器的地址信息，所述第一服务器的地址信息包括所述第一服务器的互联网协议IP地址和/或端口号。
  12. 根据权利要求8所述的方法，其特征在于，在发送所述修改后的第一协商报文之前，还包括：
    根据第一差值以及所述TLS Option字段的长度值修改所述第一协商报文的序列号，根据第二差值修改所述第一协商报文的确认号，从而获得所述修改后的第一协商报文，其中，所述第一差值是所述代理客户端装置作为代理客户端向所述第一服务器发送的同步报文的序列号与所述第一客户端发送的同步报文的序列号之差，所述第二差值是所述代理客户端装置作为代理客户端向所述第一服务器发送的所述同步报文的确认号与所述第一客户端发送的所述 同步报文的确认号之差。
  13. 根据权利要求1至11任一所述的方法，其特征在于，所述向网关设备发送修改后的第一协商报文之后，所述方法还包括：
    所述第一会话建立成功后，以流模式传输所述第一会话的后续报文。
  14. 根据权利要求1至13任一所述的方法，其特征在于，所述方法还包括：
    截获第二协商报文，所述第二协商报文来自于所述终端设备上的第二应用客户端、且用于与第二服务器协商建立第二会话，所述第二会话不满足加密强度要求；
    对所述第二协商报文进行隧道封装得到隧道协商报文，所述隧道协商报文的报文头包括所述第二应用客户端对应的鉴权信息，其中所述隧道协商报文用于协商建立所述客户端代理装置与所述网关设备之间的加密隧道；
    向所述网关设备发送所述隧道协商报文。
  15. 根据权利要求14所述的方法，其特征在于，所述第二应用客户端对应的鉴权信息携带在所述隧道协商报文的应用层报文头中。
  16. 一种访问控制方法，其特征在于，由网关设备执行，所述方法包括：
    接收第一协商报文，所述第一协商报文来自于第一客户端代理装置、用于协商建立第一会话，所述第一会话是第一终端设备与第一服务器之间的会话，所述第一客户端代理装置运行于所述第一终端设备上，所述第一协商报文的传输层报文头中携带鉴权信息；
    根据所述鉴权信息发起第一鉴权；
    所述第一鉴权成功后，不对所述第一协商报文进行隧道解封装，向所述第一服务器转发所述第一协商报文，以便于建立第一连接，所述第一连接是所述网关设备与所述第一服务器之间的连接。
  17. 根据权利要求16所述的方法，其特征在于，所述第一协商报文是传输层安全TLS报文。
  18. 根据权利要求17所述的方法，其特征在于，所述第一协商报文是客户端你好Client Hello消息。
  19. 根据权利要求17或18所述的方法，其特征在于，所述鉴权信息携带在所述第一协商报文的传输层报文头的传输层安全选项TLS Option字段中。
  20. 根据权利要求16-19任一项所述的方法，其特征在于，所述传输层报文头中还携带指示信息，所述指示信息使得所述网关设备不对所述第一协商报文进行所述隧道解封装。
  21. 根据权利要求19所述的方法，其特征在于，所述TLS Option字段符合类型长度值TLV结构，所述TLV结构中的类型T字段用于携带指示信息，所述网关设备根据所述指示信息不对所述修改后的会话协商报文进行TLS解封装，所述值V字段用于携带所述鉴权信息。
  22. 根据权利要求16-21任一项所述的方法，其特征在于，所述方法还包括：
    在所述第一鉴权成功后，建立第二连接，所述第二连接是所述网关设备与所述第一客户端代理装置之间的连接；
    通过所述第二连接接收所述第一客户端代理装置发送的所述第一会话的后续报文，通过所述第一连接向所述第一服务器转发所述来自于所述第一客户端代理装置的所述第一会话的后续报文；
    通过所述第一连接接收来自于所述第一服务器的所述第一会话的后续报文，通过所述第二连接，向所述第一客户端代理装置转发所述来自于所述第一服务器的所述第一会话的后续报文。
  23. 一种客户端代理装置，其特征在于，所述客户端代理装置运行于终端设备上，所述客户端代理装置包括：
    处理模块，用于截获第一协商报文，所述第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是所述第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求；在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文；
    发送模块，用于向网关设备发送修改后的第一协商报文。
  24. 根据权利要求23所述的客户端代理装置，其特征在于，所述第一会话满足加密强度要求，包括：
    所述第一协商报文中携带指定协议版本号，所述指定协议版本号对应的协议版本实现的传输安全性高于预设安全性标准，所述第一会话基于所述协议版本进行数据传输。
  25. 根据权利要求24所述的客户端代理装置，其特征在于，所述指定协议版本号包括传输层安全TLS 1.2或TLS 1.3。
  26. 根据权利要求23-25任一项所述的客户端代理装置，其特征在于，所述第一会话满足加密强度要求，包括：
    所述第一协商报文包括指定加密套件标识，所述指定加密套件标识用于标识指定加密套件，所述指定加密套件实现的传输安全性高于预设安全性标准，所述第一会话基于所述指定加密套件对应用数据进行加密。
  27. 根据权利要求23-26任一所述的客户端代理装置，其特征在于，所述第一协商报文是TLS报文。
  28. 根据权利要求27所述的客户端代理装置，其特征在于，所述第一协商报文是客户端你好Client Hello消息。
  29. 根据权利要求23-28任一项所述的客户端代理装置，其特征在于，所述修改后的第一协商报文的传输层报文头还包括指示信息，所述指示信息使得所述网关设备不对所述修改后的第一协商报文进行解封装。
  30. 根据权利要求23-28任一项所述的客户端代理装置，其特征在于，
    所述处理模块，用于在所述第一协商报文的传输层报文头中增加传输层安全选项TLS Option字段；在所述TLS Option字段中携带所述第一应用客户端对应的鉴权信息。
  31. 根据权利要求30所述的方法，其特征在于，所述TLS Option字段符合类型长度值TLV结构，所述TLV结构中的类型T字段用于携带指示信息，所述指示信息以使所述网关设备不对所述修改后的会话协商报文进行TLS解封装处理，所述值V字段用于携带所述鉴权信息。
  32. 根据权利要求23-31任一项所述的客户端代理装置，其特征在于，所述鉴权信息包括用户令牌和/或应用令牌。
  33. 根据权利要求23-32任一项所述的客户端代理装置，其特征在于，
    所述发送模块，还用于所述第一会话建立成功后，以流模式传输所述第一会话的后续报文。
  34. 根据权利要求23-33任一项所述的客户端代理装置，其特征在于，
    所述处理单元，还用于截获第二协商报文，所述第二协商报文来自于所述终端设备上的第二应用客户端、且用于与第二服务器协商建立第二会话，所述第二会话不满足加密强度要求；对所述第二协商报文进行隧道封装得到隧道协商报文，所述隧道协商报文的报文头包括所述第二应用客户端对应的鉴权信息，其中所述隧道协商报文用于协商建立所述客户端代理装置与所述网关设备之间的加密隧道；
    所述发送单元，还用于向所述网关设备发送所述隧道协商报文。
  35. 根据权利要求34所述的客户端代理装置，其特征在于，所述第二应用客户端对应的鉴权信息携带在所述隧道协商报文的应用层报文头中。
  36. 一种网关设备，其特征在于，包括：
    接收模块，用于接收第一协商报文，所述第一协商报文来自于第一客户端代理装置、用于协商建立第一会话，所述第一会话是第一终端设备与第一服务器之间的会话，所述第一客户端代理装置运行于所述第一终端设备上，所述第一协商报文的传输层报文头中携带鉴权信息；
    处理模块，用于根据所述鉴权信息发起第一鉴权；
    发送模块，用于所述第一鉴权成功后，不对所述第一协商报文进行隧道解封装，向所述 第一服务器转发所述第一协商报文，以便于建立第一连接，所述第一连接是所述网关设备与所述第一服务器之间的连接。
  37. 根据权利要求36所述的网关设备，其特征在于，所述第一协商报文是传输层安全TLS报文。
  38. 根据权利要求37所述的网关设备，其特征在于，所述第一协商报文是Client Hello消息。
  39. 根据权利要求37或38所述的网关设备，其特征在于，所述鉴权信息携带在所述第一协商报文的传输层报文头的传输层安全选项TLS Option字段中。
  40. 根据权利要求36-39任一项所述的网关设备，其特征在于，所述传输层报文头中还携带指示信息，所述指示信息使得所述网关设备不对所述第一协商报文进行所述隧道解封装。
  41. 根据权利要求39所述的网关设备，其特征在于，所述TLS Option字段符合类型长度值TLV结构，所述TLV结构中的类型T字段用于携带指示信息，所述网关设备根据所述指示信息不对所述修改后的会话协商报文进行TLS解封装，所述值V字段用于携带所述鉴权信息。
  42. 根据权利要求36-41任一项所述的网关设备，其特征在于，
    所述处理模块，还用于在所述第一鉴权成功后，建立第二连接，所述第二连接是所述网关设备与所述第一客户端代理装置之间的连接；
    所述接收模块，还用于通过所述第二连接接收所述第一客户端代理装置发送的所述第一会话的后续报文；
    所述发送模块，还用于通过所述第一连接向所述第一服务器转发所述来自于所述第一客户端代理装置的所述第一会话的后续报文；
    所述接收模块，还用于通过所述第一连接接收来自于所述第一服务器的所述第一会话的后续报文；
    所述发送模块，还用于向所述第一客户端代理装置转发所述来自于所述第一服务器的所述第一会话的后续报文。
  43. 一种终端设备，其特征在于，包括：存储器和处理器；
    所述存储器用于存储计算机指令；
    所述计算机指令被所述处理器读取后，使得所述终端设备执行如权利要求1至15任一所述的访问控制方法。
  44. 一种网关设备，其特征在于，包括：存储器和处理器；
    所述存储器用于存储计算机指令；
    所述计算机指令被所述处理器读取后，使得所述网关设备执行如权利要求16至22任一所述的访问控制方法。
  45. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被终端设备的处理器执行时，使得所述终端设备执行如权利要求1-15任一项所述的访问控制方法。
  46. 一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机指令，所述计算机指令被网关设备的处理器执行时，使得所述网关设备执行如权利要求16-22任一项所述的访问控制方法。
  47. 一种访问控制系统，其特征在于，包括终端设备和网关设备，所述终端设备中运行客户端代理装置，
    所述客户端代理装置，用于截获第一协商报文，所述第一协商报文来自于所述终端设备上的第一应用客户端、用于协商建立第一会话，所述第一会话是所述第一应用客户端与第一服务器之间的会话，且所述第一会话满足加密强度要求；在所述第一协商报文的传输层报文头中添加所述第一应用客户端对应的鉴权信息以得到修改后的第一协商报文；向所述网关设备发送修改后的第一协商报文；
    所述网关设备，用于接收所述修改后的第一协商报文；根据所述修改后的第一协商报文 的传输层报文头中携带的鉴权信息发起第一鉴权；所述第一鉴权成功后，不对所述第一协商报文进行隧道解封装，向所述第一服务器转发所述第一协商报文，以便于建立第一连接，所述第一连接是所述网关设备与所述第一服务器之间的连接。
PCT/CN2022/079432 2021-07-31 2022-03-04 访问控制方法、客户端代理装置、网关设备及相关系统 WO2023010839A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP22851566.4A EP4369656A1 (en) 2021-07-31 2022-03-04 Access control method, client proxy apparatus, gateway device, and related system

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN202110876797.1 2021-07-31
CN202110876797 2021-07-31
CN202111029935.9 2021-09-03
CN202111029935.9A CN115694862A (zh) 2021-07-31 2021-09-03 访问控制方法、客户端代理装置、网关设备及相关系统

Publications (1)

Publication Number Publication Date
WO2023010839A1 true WO2023010839A1 (zh) 2023-02-09

Family

ID=85060096

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/079432 WO2023010839A1 (zh) 2021-07-31 2022-03-04 访问控制方法、客户端代理装置、网关设备及相关系统

Country Status (3)

Country Link
EP (1) EP4369656A1 (zh)
CN (1) CN115694862A (zh)
WO (1) WO2023010839A1 (zh)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1708449A1 (en) * 2005-04-01 2006-10-04 Zyxel Communications Corporation Mobile VPN proxy method based on session initiation protocol
CN101119196A (zh) * 2006-08-03 2008-02-06 西安电子科技大学 一种双向认证方法及系统
CN111885031A (zh) * 2020-07-13 2020-11-03 董鹏 一种基于会话过程的细粒度访问控制方法及系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1708449A1 (en) * 2005-04-01 2006-10-04 Zyxel Communications Corporation Mobile VPN proxy method based on session initiation protocol
CN101119196A (zh) * 2006-08-03 2008-02-06 西安电子科技大学 一种双向认证方法及系统
CN111885031A (zh) * 2020-07-13 2020-11-03 董鹏 一种基于会话过程的细粒度访问控制方法及系统

Also Published As

Publication number Publication date
EP4369656A1 (en) 2024-05-15
CN115694862A (zh) 2023-02-03

Similar Documents

Publication Publication Date Title
US10419348B2 (en) Efficient intercept of connection-based transport layer connections
US11792169B2 (en) Cloud storage using encryption gateway with certificate authority identification
US8788805B2 (en) Application-level service access to encrypted data streams
US9667601B2 (en) Proxy SSL handoff via mid-stream renegotiation
JP2023116573A (ja) クライアント－クラウドまたはリモートサーバーの安全なデータまたはファイル・オブジェクト暗号化ゲートウェイ
US8984268B2 (en) Encrypted record transmission
US8510549B2 (en) Transmission of packet data over a network with security protocol
JP4245838B2 (ja) セキュアクライアントサーバトランザクションを管理するための方法及びシステム
US9350711B2 (en) Data transmission method, system, and apparatus
WO2020048478A1 (zh) 一种传输控制方法和装置
AU2004306787A1 (en) Encapsulating protocol for session persistence and reliability
US11924248B2 (en) Secure communications using secure sessions
CA3066728A1 (en) Cloud storage using encryption gateway with certificate authority identification
KR101971995B1 (ko) 보안을 위한 보안 소켓 계층 복호화 방법
CN108900584B (zh) 内容分发网络的数据传输方法和系统
WO2023010839A1 (zh) 访问控制方法、客户端代理装置、网关设备及相关系统
CN114070606A (zh) 一种基于国产操作系统的网络安全终端装置及工作方法
WO2022012355A1 (zh) 安全通信方法、相关装置及系统
CN116094746A (zh) 一种聚合多个运营商中各物联网设备的安全网关系统
CN116405264A (zh) 一种单包授权的方法及系统
Varadhan Securing Traffic Tunnelled over TCP or UDP

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22851566

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2022851566

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022851566

Country of ref document: EP

Effective date: 20240207

NENP Non-entry into the national phase

Ref country code: DE