CN114499913B

CN114499913B - Encrypted message detection method and protection equipment

Info

Publication number: CN114499913B
Application number: CN202011377786.0A
Authority: CN
Inventors: 何新乾
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2020-10-26
Filing date: 2020-11-30
Publication date: 2022-12-06
Anticipated expiration: 2040-11-30
Also published as: CN114499913A

Abstract

The application provides a detection method and protection equipment for encrypted messages, and belongs to the technical field of communication. According to the method and the device, an SSL handshake flow between the protective device and the client device and an SSL handshake flow between the protective device and the server are associated, the same DH parameters are respectively sent to the client device and the server by the protective device, the DH parameters on two sides are multiplexed when a session key is generated, and the session key is used for decrypting an encrypted message sent by the client device or the server and encrypting plaintext data after decryption detection. The embodiment of the application reduces the calculation amount brought by generation of the DH parameters, saves the resource occupation of the protection equipment such as the firewall and the like, and is beneficial to greatly improving the SSL handshake speed and the performance of the protection equipment.

Description

Encrypted message detection method and protection equipment

The present application claims priority of chinese patent application No. 202011155469.4 entitled "a method and related apparatus for processing encrypted traffic" filed on 26.10/26/2020, which is incorporated herein by reference in its entirety.

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method for detecting an encrypted packet and a protection device.

Background

In the TCP/IP Protocol Suite (TCP/IP Protocol Suite, or TCP/IP Protocols) having a multi-Layer structure, a Secure Socket Layer/Transport Layer Security (SSL/TLS) is located between a hypertext transfer Protocol (HTTP) Protocol and a Transmission Control Protocol (TCP) Protocol. The traffic of using HTTPS (HTTP over TLS) for interaction needs to establish a TCP connection like ordinary HTTP traffic, then performs SSL/TLS handshake on the TCP connection, establishes SSL/TLS session, and then encrypts HTTP interactive content using the SSL/TLS session, thereby ensuring privacy, reliability, and credibility of data transmission.

When a client and a server transmit encrypted messages based on SSL/TLS, how a firewall arranged between the client and the server performs security detection on the encrypted messages becomes a problem to be solved urgently. The currently predominant solution is a detection scheme based on SSL/TLS man-in-the-middle (man-in-the-middle) technology.

The basic principle of SSL/TLS middleware is that the firewall acts as a proxy server and performs SSL/TLS handshake with the client. Meanwhile, the firewall is used as a proxy client and carries out SSL/TLS handshake with the server.

In the related technology, when the SSL/TLS middleware is implemented, the firewall serves as an end point of an SSL/TLS session, and completes SSL handshake with the server and the client device independently. When the method is adopted, huge calculation amount is involved in the process that the firewall negotiates various encrypted keys and encrypted parameters with the server and the client device respectively, so that the firewall has excessive resource occupation and low performance.

Disclosure of Invention

The embodiment of the application provides a detection method of an encrypted message and protection equipment, which are beneficial to reducing equipment resource occupation and improving equipment performance. The technical scheme is as follows.

In a first aspect, a method for detecting an encrypted packet is provided, in which a guard device sends a Diffie-Hellman (DH) parameter to a client device and a server, respectively, the guard device is deployed between the client device and the server, and the DH parameter is a DH parameter generated by the guard device; the protective device generates a first session key according to the man-in-the-middle DH parameter and a client DH parameter, wherein the client DH parameter is a DH parameter generated by the client device; the protective device generates a second session key according to the man-in-the-middle DH parameter and a server DH parameter, wherein the server DH parameter is the DH parameter generated by the server; the protection equipment receives an original encrypted message; if the original encrypted message comes from the client device, the protection device decrypts the original encrypted message by using the first session key, detects decrypted plaintext data, encrypts the detected data by using the second session key to obtain a target encrypted message, and sends the target encrypted message to the server; or, if the original encrypted message is from the server, the protection device decrypts the original encrypted message by using the second session key, detects decrypted plaintext data, encrypts the detected data by using the first session key to obtain a target encrypted message, and sends the target encrypted message to the client device.

The method provided by the first aspect associates the SSL handshake flow between the protection device and the client device and the SSL handshake flow between the protection device and the server, and the protection device sends the same DH parameter to the client device and the server, and multiplexes the DH parameters on both sides when generating the session key, thereby reducing the amount of calculation caused by DH parameter generation, saving resource occupation on the protection devices such as a firewall, and contributing to greatly increasing the SSL handshake speed and improving the performance of the protection device.

Optionally, the sending, by the protective device, the man-in-the-middle DH parameter to the client device and the server respectively includes: the protection equipment receives an original client key exchange message from the client equipment; the protection device replaces the client DH parameters in the original client key exchange message with the man-in-the-middle DH parameters to obtain a target client key exchange message; the protective equipment sends the target client key exchange message to the server; the protection equipment receives an original server key exchange message from the server; the protection equipment replaces the server DH parameter in the original server key exchange message with the man-in-the-middle DH parameter so as to obtain a target server key exchange message; and the protective equipment sends the target server key exchange message to the client equipment.

Through the optional mode, the handshake process of the real client and the server is used for driving, and the protection equipment can realize handshake with two sides only by generating less parameters, executing message analysis and content replacement on the basis of handshake messages sent by the two sides, so that a large amount of resource overhead is reduced.

Optionally, before the guard device obtains the target server key exchange packet, the method further includes: and the protecting equipment replaces the server signature in the original server key exchange message with a man-in-the-middle signature, wherein the man-in-the-middle signature is obtained by using a private key of the protecting equipment to sign the DH parameter of the man-in-the-middle.

Through the optional mode, the protection device replaces the server signature with the man-in-the-middle signature, so that the man-in-the-middle DH parameter is transmitted to the client device along with the man-in-the-middle signature, the probability of transmission failure due to the fact that signature verification is not passed is reduced, and the success rate of transmitting the man-in-the-middle DH parameter is improved.

Optionally, the generating, by the guard device, a first session key according to the man-in-the-middle DH parameter and the client DH parameter includes: the protection device generates a first pre-master secret key by using the man-in-the-middle DH parameter and the client DH parameter; the protection device generates the first session key by using the first premaster secret key, a client random number and a server random number, wherein the client random number is a random number generated by the client device, and the server random number is a random number generated by the server; the protecting device generates a second session key by using the man-in-the-middle DH parameter and the server DH parameter, including: the protective equipment generates a second pre-master secret key by using the man-in-the-middle DH parameter and the server DH parameter; the protection device generates the second session key using the second premaster secret key, the client random number, and the server random number.

By this alternative, the guard device avoids the overhead of independently generating random numbers by multiplexing the random numbers generated by the client device and the server when generating the session key.

Optionally, the client random number is extracted by the guard device from an original client hello message, and the server random number is extracted by the guard device from an original server hello message.

Through the optional mode, the protection equipment can obtain the random number from the received original hello message, and the implementation complexity is reduced.

Optionally, before the guard device sends the man-in-the-middle DH parameter to the client device and the server, respectively, the method further includes: the guard device receiving an original client hello message from the client device, the original client hello message including an algorithm list; the protection device deletes the identifier of the first algorithm in the algorithm list from the original client hello message so as to obtain a target client hello message, wherein the first algorithm is an algorithm which is not supported by the protection device; and the protection equipment sends the target client hello message to the server.

Through the optional mode, safety and compatibility are considered, and flexibility is high.

Optionally, the decrypting, by the protective device, the original encrypted packet using the first session key includes: the protection device decrypts the original encrypted message by using the first session key through a second algorithm, wherein the second algorithm is an algorithm corresponding to the algorithm identifier remaining after the identifier of the first algorithm is deleted from the algorithm list; the encrypting the detected data by using the second session key to obtain the target encrypted message includes: encrypting the detected data by using the second session key through the second algorithm to obtain a target encryption message; the decrypting, by the protection device, the original encrypted packet using the second session key includes: the protection device decrypts the original encrypted message by using the second session key through the second algorithm; the encrypting the detected data by using the first session key to obtain a target encrypted message includes: and encrypting the detected data by using the first session key through the second algorithm to obtain a target encrypted message.

Through the optional mode, the client, the protective equipment and the server are ensured to use the algorithms supported by the three parties to encrypt and decrypt the data in the data transmission stage, and the failure of security detection caused by the fact that the protective equipment does not support the algorithm required by decryption is avoided.

Optionally, before the guard device sends the man-in-the-middle DH parameter to the client device and the server, respectively, the method further includes: the protection equipment receives an original server hello message from the server; the protection device replaces a server certificate in the original server hello message with a broker certificate so as to obtain a target server hello message, wherein the server certificate comprises a public key of the server, and the broker certificate comprises a public key of the protection device; and the protection equipment sends the target server hello message to the client equipment.

In this alternative, the guard device ensures that the man-in-the-middle signature passes the verification of the client device by replacing the certificate of the server, thereby avoiding the data (such as the man-in-the-middle DH parameter) transmitted to the client device along with the man-in-the-middle signature from failing to be transmitted due to the failure of the signature verification.

Optionally, the protection device includes a hardware accelerator, where the hardware accelerator is configured to generate the man-in-the-middle DH parameter, generate a session key, decrypt the original encrypted packet, or encrypt the detected data; if the hardware accelerator is configured to generate the session key, the protection device generates a first session key according to the man-in-the-middle DH parameter and the client DH parameter, including: the protection equipment inputs the DH parameter of the man-in-the-middle and the DH parameter of the client into the hardware accelerator and receives a first session key generated by the hardware accelerator; the protective device generates a second session key according to the man-in-the-middle DH parameter and the server DH parameter, including: the protection equipment inputs the man-in-the-middle DH parameters and the server DH parameters into the hardware accelerator and receives a second session key generated by the hardware accelerator; if the hardware accelerator is used to decrypt the original encrypted packet, the protecting device uses the first session key to decrypt the original encrypted packet, including: the protection equipment inputs the first session key and the original encrypted message into the hardware accelerator, and receives plaintext data obtained by decryption of the hardware accelerator; the decrypting, by the protection device, the original encrypted packet using the second session key includes: the protection equipment inputs the second session key and the original encrypted message into the hardware accelerator, and receives plaintext data decrypted by the hardware accelerator; if the hardware accelerator is configured to encrypt the detected data, the encrypting, by using the second session key, the detected data includes: the protection equipment inputs the second session key and the detected data into the hardware accelerator, and receives a target encrypted message encrypted by the hardware accelerator; the encrypting the detected data using the first session key includes: and the protection equipment inputs the first session key and the detected data into the hardware accelerator and receives a target encrypted message encrypted by the hardware accelerator.

Through the optional mode, the algorithm part consuming performance adopts special acceleration hardware for processing, so that the resource occupation is greatly improved, and the performance is greatly improved.

In a second aspect, there is provided a protective apparatus having the functionality of any one of the first aspect or the alternatives of the first aspect. The protective equipment comprises at least one unit for implementing the method provided by the first aspect or any one of the alternatives of the first aspect.

In some embodiments, the units in the guard device are implemented in software, and the units in the guard device are program modules. In other embodiments, the units in the guard are implemented in hardware or firmware. Specific details of the protective device provided by the second aspect may be referred to in the first aspect or any optional manner of the first aspect, and are not described herein again.

In a third aspect, a protection device is provided, where the protection device includes a processor and a communication interface, where the processor is configured to execute instructions so that the protection device performs the method provided by the first aspect or any one of the optional manners of the first aspect, and the communication interface is configured to receive or send a message. Specific details of the protective device provided by the third aspect may be found in the first aspect or any optional manner of the first aspect, and are not described herein again.

In a fourth aspect, a computer-readable storage medium is provided, where at least one instruction is stored, and when the instruction is executed on a computer, the instruction causes the computer to execute the method provided by the first aspect or any one of the optional manners of the first aspect.

In a fifth aspect, there is provided a computer program product comprising one or more computer program instructions which, when loaded and executed by a computer, cause the computer to perform the method of the first aspect or any of the alternatives of the first aspect.

In a sixth aspect, there is provided a chip comprising a memory for storing computer instructions and a processor for retrieving and executing the computer instructions from the memory to perform the method of the first aspect and any possible implementation manner of the first aspect.

In a seventh aspect, a network system is provided, where the network system includes a protection device, and the network system further includes a client device or a server, and the protection device is configured to perform the method according to the first aspect or any one of the optional manners of the first aspect.

Drawings

FIG. 1 is a schematic diagram of the location of SSL/TLS in a protocol family according to an embodiment of the present application;

fig. 2 is a flowchart of SSL/TLS handshake performed between two communication parties according to an embodiment of the present application;

FIG. 3 is a flowchart of an SSL/TLS broker-based detection scheme provided by an embodiment of the present application;

FIG. 4 is a diagram illustrating an exemplary application scenario provided by an embodiment of the present application;

FIG. 5 is a schematic structural diagram of a protection device provided by an embodiment of the present application;

fig. 6 is a flowchart of a method for detecting an encrypted message according to an embodiment of the present application;

fig. 7 is a flowchart of a communication three-party interaction key exchange message according to an embodiment of the present application;

fig. 8 is a flowchart of a detection method for an encrypted message according to an embodiment of the present application;

fig. 9 is a flowchart of a communication three-party interactive greeting message provided by an embodiment of the present application;

FIG. 10 is a flowchart of an SSL/TLS broker-based detection scheme provided by an embodiment of the present application;

fig. 11 is a schematic structural diagram of a protection device according to an embodiment of the present application.

Detailed Description

To make the objects, technical solutions and advantages of the present application more clear, the following detailed description of the embodiments of the present application will be made with reference to the accompanying drawings.

SSL/TLS encrypted traffic in the Internet accounts for more and more weight. According to Google's (Google) related statistics, about 90% of traffic is hypertext transfer protocol secure (HTTPS) traffic, where HTTPS is also known as HTTP over TLS. Most of the current network security detection technologies are based on deep identification and analysis of traffic. Most network security technologies fail if they cannot decrypt the plaintext. How to detect encrypted traffic becomes a hot spot problem for the guard device.

Referring to fig. 1, SSL/TLS is located between HTTP protocol and TCP protocol in the TCP/IP protocol suite having a multi-layer structure. For the traffic interacted by using HTTPS, both communication parties first need to establish a Transmission Control Protocol (TCP) connection like ordinary HTTP traffic. Then, both communication parties need to perform SSL/TLS handshake on the TCP connection, an SSL/TLS session is established, and then the SSL/TLS session is used for encrypting HTTP interactive contents, so that the privacy, reliability and credibility of data transmission are ensured.

The SSL/TLS session is mainly divided into two phases: a handshake phase and a data transfer phase.

In the handshake phase, the two end devices of the SSL/TLS session negotiate a session key used in a subsequent data transmission phase based on asymmetric encryption (also called public key encryption) and a key negotiation algorithm.

In the data transmission phase, the two end devices of the SSL/TLS session use the algorithm and the session key negotiated in the handshake phase to encrypt and transmit the application layer (e.g., HTTP) data. The data transmission phase is also referred to as the symmetric encryption processing phase.

An important concern here is the process of key negotiation. The key negotiation has many algorithms, and most of the algorithms are based on complex mathematical theory and require a large number of mathematical operations. Among them, diffie-Hellman (DH) algorithm is most widely used. The DH algorithm includes an Elliptic Curve DH (ECDH) algorithm. The DH algorithm can enable two communication parties to establish a secret key through an insecure channel under the condition that no information of the other party exists in advance; the two parties of communication that use the DH algorithm to negotiate respectively generate DH parameters. For simplicity of understanding, the respective DH parameters of both communicating parties can be divided into two parts: a public part (pub key) and a private part (private key). The communicating parties exchange the published portion of the DH parameters. The DH algorithm ensures that both parties of the communication can calculate a consistent secret (i.e., key information for finally generating a session key) using their own DH parameters (public part and private part) plus the public part of the DH parameters of the opposite end; any third party, relying only on the public part of the DH parameters disclosed by both parties, cannot calculate the secret.

Referring to fig. 2, taking the ECDH algorithm as an example, in the case of no man-in-the-middle participation, the SSL/TLS handshake process of two communication parties is as shown in fig. 2, and includes the following steps S11 to S14.

Step S11, the client device sends a client hello message to the server, wherein the client hello message comprises a client random number, a version supported by the client and an algorithm list.

And step S12, the server sends the server random number and the server certificate to the client equipment. The server certificate includes the public key of the server.

And S13, the server sends the server DH parameters and the server signature to the client equipment. The server signature is obtained by the server using a private key to sign the client random number, the server random number and the server DH parameter.

Step S14, the client device sends the client DH parameters to the server.

Then, the client device and the server use the client DH parameters and the server DH parameters to generate the same pre-master key. The client device and the server use the premaster secret key, the client random number and the server random number respectively to generate a finally used session secret key.

When a protection device such as a firewall device is located in a network between a client device and a server, the protection device needs to decrypt encrypted traffic in order to detect an encrypted packet transmitted between the client device and the server. The current mainstream solution is a detection scheme based on SSL/TLS broker. The SSL/TLS man-in-the-middle agent technology, as the name implies, the protection device needs to be used as a proxy server and a client device to perform SSL/TLS handshake. Meanwhile, the protection device serves as a proxy client and carries out SSL/TLS handshake with the server.

In some studies, the guard was attempted to act as an endpoint for the SSL/TLS session, with the guard independently completing the handshake with the actual server and the actual client, respectively. The information required for the guard to handshake is automatically generated depending on SSL library software, such as OpenSSL (a software library package of open source code). Specifically, referring to fig. 3, fig. 3 shows a flow chart of such a SSL/TLS broker-based detection scheme, and the method shown in fig. 3 includes the following steps S21 to S28. In the flow shown in fig. 3, when the guard device performs handshake, a man-in-the-middle DH parameter 1, a man-in-the-middle DH parameter 2, a man-in-the-middle random number 1, and a man-in-the-middle random number 2 are required, and the man-in-the-middle DH parameter 1, the man-in-the-middle DH parameter 2, the man-in-the-middle random number 1, and the man-in-the-middle random number 2 are generated by executing complex computation through SSL library software.

And S21, the client device sends a client hello message to the server. The client hello message includes a client random number, a supported version, and an algorithm list.

And S22, the protective equipment receives the client hello message. The protection device extracts a client random number from the client hello message, and initiates handshake to the server by using OpenSSL according to a preconfigured algorithm list.

And step S23, the server sends the server random number and the server certificate to the client equipment, and the protection equipment receives the server random number and the server certificate. The server certificate includes the public key of the server.

And step S24, the server sends the server DH parameters and the server signature to the client equipment. The server signature is obtained by the server using a private key to sign the client random number, the server random number and the server DH parameter.

And S25, the protection device sends the man-in-the-middle DH parameter 1 to the server.

Then, the server and the guard device use the DH parameters of both parties (the man-in-the-middle DH parameter 1 and the server DH parameter) to generate the same premaster secret key 1. Then, the server and the guard device use the premaster secret key 1, the middleman random number 1 and the server random number to generate the same session secret key 1.

Step S26, after the protection device obtains the server certificate, the protection device reissues a new certificate (a broker certificate), and continues handshaking with the client device using OpenSSL.

And S27, the protective device sends the man-in-the-middle DH parameter 2 and the man-in-the-middle signature to the client device.

And S28, the client device sends the client DH parameters to the server, and the protective device receives the client DH parameters.

Then, the client device and the guard device use the DH parameters (client DH parameter and man-in-the-middle DH parameter 2) of both parties to generate the same premaster secret key 2. Then, both the client device and the guard device use the premaster secret key, the client random number, and the broker random number 2 to generate the same session secret key 2.

During the study it was found that the SSL/TLS broker scheme shown in figure 3 is not as complete. On one hand, from the perspective of efficiency, in the scheme shown in fig. 3, openSSL or other open source software is required to be relied on when the protection device performs SSL/TLS handshake, and such open source software generally has the problems of low performance, high resource occupation, and the like. Specifically, many parameters are involved in the whole SSL handshake interaction process, and in the scheme shown in fig. 3, the guard device is generated and maintained through OpenSSL. From the perspective of the guard device, it is preferable to be able to implement multiplexing of the above parameters, e.g., directly multiplexing client device or server generated parameters, rather than generating them by themselves. However, in the scheme shown in fig. 3, the interaction flows of the protection device and the two ends are split without correlation, and parameters required for handshaking are generated by SSL library software, so that the parameters cannot be reused. In addition, the communicating parties need to perform complex computation respectively to obtain the asymmetric key, which results in huge computation overhead. On the other hand, from the perspective of security and compatibility, the scheme shown in fig. 3 may cause the security of the data transmission phase to be reduced because the handshake phase negotiates an unsafe algorithm. If it is forced to configure a high security algorithm, compatibility problems may be introduced: originally, the client device and the server can use a lower security algorithm meeting the requirements for negotiation, and the negotiation is failed after the protective device is introduced as a man-in-the-middle.

In view of the problems of security and compatibility and poor efficiency in the scheme shown in fig. 3, the embodiment of the present application provides a stateless SSL broker scheme, which associates the protection device with the interaction flows at two ends, implements multiplexing of parameters of both communication parties, and reduces the amount of computation caused by independent generation of parameters by the protection device, thereby saving resource occupation of the protection device and contributing to greatly improving the processing efficiency of the protection device as the SSL broker.

An application scenario provided by the embodiment of the present application is described below with reference to fig. 4.

Referring to fig. 4, fig. 4 is a schematic diagram illustrating a typical application scenario provided in the embodiment of the present application. The application scenario includes a client device 31, a server 32, and a guard device 33. The client device 31, the server 32, and the guard device 33 are described below, respectively.

(1) Client device 31

The client device 31 is a device in the internet that initiates access. The client device 31 is, for example, a terminal device that has browser software installed. Client devices 31 include, but are not limited to, personal computers, mobile phones, servers, laptops, IP phones, cameras, tablets, wearable devices, and the like. For example, the client device 31 is an office device of an employee inside an enterprise. In an actual network system, there are optionally a large number of client devices, and for the sake of simplicity, fig. 4 illustrates the case of one client device 31 as an example.

(2) Server 32

The server 32 is a device that provides services in the internet. For example, the server 32 is a web server, and the server 32 is used to provide resources required for accessing web pages for browser software in the client device 31. As another example, server 32 is a financial server, and server 32 is used to provide resources required for personal financial services (e.g., bank account management, purchasing financial products, etc.) for financial client software in client device 31.

The data transmission between the client device 31 and the server 32 may be bidirectional, and it is possible that the client device 31 transmits data to the server 32, or the server 32 transmits data to the client device 31.

(3) Protective equipment 33

The guard device 33 is disposed between the client device 31 and the server 32. The deployment of the protective equipment 33 includes, but is not limited to, straight line deployment, bypass deployment, and the like. The guard device 33 is connected to the client device 31 and the server 32 via a network, respectively.

The protective device 33 is configured to implement SSL/TLS broker for access traffic in the network, and perform security detection after locally decrypting encrypted traffic. Security tests include, without limitation, intrusion Prevention System (IPS) tests, anti-virus (AV) tests, and the like. The protective devices 33 include, without limitation, firewalls, intrusion Detection System (IDS) class devices, IPS class devices, security gateways, unified Threat Management (UTM) devices, servers, hosts, personal computers, or the like.

Optionally, the guard 33 includes an SSL/TLS proxy module 331 and a TCP/IP stack module 332. The SSL/TLS proxy module 331 is configured to implement processing tasks in the SSL/TLS proxy, for example, perform SSL/TLS handshake with the server instead of the client, perform SSL/TLS handshake with the client instead of the server, and so on. The TCP/IP stack module 332 is used for transmitting packets based on the TCP/IP protocol.

Optionally, the guard device also includes a cryptographic accelerator 333. The encryption/decryption accelerator 333 is used to accelerate the steps related to generating encryption parameters, generating session keys, and encrypting or decrypting by means of algorithm hardware, so as to improve the performance of the protection device.

Fig. 5 is a schematic structural diagram of a protection device provided in an embodiment of the present application. Alternatively, the shielding apparatus having the structure shown in fig. 5 is the shielding apparatus 33 in fig. 4.

Referring to fig. 5, fig. 5 is a schematic diagram illustrating a structure of a guard device 400 according to an exemplary embodiment of the present application, wherein the guard device 400 is implemented by a general bus architecture.

Guard device 400 includes at least one processor 401, a communication bus 402, a memory 403, and at least one network interface 404.

The processor 401 is, for example, a Central Processing Unit (CPU), a Network Processor (NP), a Graphics Processing Unit (GPU), a neural-Network Processing Unit (NPU), a Data Processing Unit (DPU), a microprocessor, or one or more integrated circuits for implementing the present disclosure. For example, the processor 401 may include an application-specific integrated circuit (ASIC), a Programmable Logic Device (PLD), or a combination thereof. PLDs are, for example, complex Programmable Logic Devices (CPLDs), field-programmable gate arrays (FPGAs), general Array Logic (GAL), or any combination thereof.

A communication bus 402 is used to transfer information between the above components. The communication bus 402 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in FIG. 5, but this is not intended to represent only one bus or type of bus.

The memory 403 stores program code 410 for implementing the embodiments of the method of the present application. The Memory 403 is, for example, but not limited to, a read-only Memory (ROM) or other type of static storage device that can store static information and instructions, a Random Access Memory (RAM) or other type of dynamic storage device that can store information and instructions, an electrically erasable programmable read-only Memory (EEPROM), a compact disc read-only Memory (CD-ROM) or other optical disc storage, optical disc storage (including compact disc, laser disc, optical disc, digital versatile disc, blu-ray disc, etc.), a magnetic disc storage medium or other magnetic storage device, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. The memory 403 is, for example, separate and connected to the processor 401 through a communication bus 402. The memory 403 may also be integrated with the processor 401.

The network interface 404 uses any transceiver or the like for communicating with other devices or a communication network. The network interface 404 includes a wired communication interface and may also include a wireless communication interface. The wired communication interface may be an ethernet interface, for example. The ethernet interface may be an optical interface, an electrical interface, or a combination thereof. The wireless communication interface may be a Wireless Local Area Network (WLAN) interface, a cellular network communication interface, or a combination thereof.

In particular implementations, processor 401 may include one or more CPUs, such as CPU0 and CPU1 shown in fig. 5, as one embodiment.

Optionally, the guard device 400 also includes a hardware accelerator 405. The hardware accelerator 405 is configured to generate a man-in-the-middle DH parameter, generate a session key, decrypt an original encrypted message, or encrypt detected data. The hardware accelerator 405 accelerates the execution of these steps by means of algorithmic hardware. The hardware accelerator 405 supports at least one algorithm. Algorithms supported by the hardware accelerator 405 include, but are not limited to, algorithms used by the SSL/TLS communication flow to generate DH parameters, session keys, random numbers, etc. during the session negotiation phase, and algorithms used by the SSL/TLS communication flow during encryption and decryption during the data transfer phase. For example, the hardware accelerator 405 supports a DH algorithm (e.g., ECDH algorithm), etc. In some embodiments, hardware accelerator 405 includes a cryptographic processor. The hardware accelerator 405 includes, but is not limited to, a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), a system on chip (SoC), a Central Processing Unit (CPU), a Network Processor (NP), a digital signal processing circuit (DSP), a Micro Controller Unit (MCU), a Programmable Logic Device (PLD), or other integrated chips.

Each of the processor 401 and the hardware accelerator 405 is, for example, a single-core processor (single-CPU) or, for example, a multi-core processor (multi-CPU). A processor herein may refer to one or more devices, circuits, and/or processing cores for processing data (e.g., computer program instructions).

In particular implementations, guard device 400 may also include an output device and an input device, as one embodiment. An output device is in communication with the processor 401 and may display information in a variety of ways. For example, the output device may be a Liquid Crystal Display (LCD), a Light Emitting Diode (LED) display device, a Cathode Ray Tube (CRT) display device, a projector (projector), or the like. The input device is in communication with the processor 401 and may receive user input in a variety of ways. For example, the input device may be a mouse, a keyboard, a touch screen device, or a sensing device, among others.

In the flow illustrated in fig. 6, the processor 401, after reading the program code 410 stored in the memory 403, is configured to perform the following operations: the processor 401 instructs the network interface 404 to send a man-in-the-middle DH parameter to the client device and the server, respectively, where the man-in-the-middle DH parameter is a DH parameter generated by the processor 401 or the hardware accelerator 405; the processor 401 generates a first session key according to the man-in-the-middle DH parameter and the client DH parameter; the processor 401 generates a second session key according to the man-in-the-middle DH parameter and the server DH parameter; a network interface 404, configured to receive an original encrypted packet; if the original encrypted message comes from the client device, the processor 401 decrypts the original encrypted message by using the first session key, detects the decrypted plaintext data, encrypts the detected data by using the second session key to obtain a target encrypted message, and the processor 401 instructs the network interface 404 to send the target encrypted message to the server; or, if the original encrypted message is from the server, the processor 401 decrypts the original encrypted message using the second session key, detects the decrypted plaintext data, and encrypts the detected data using the first session key to obtain a target encrypted message, and the processor 401 instructs the network interface 404 to send the target encrypted message to the client device.

In some embodiments, a network interface 404 for receiving an original client key exchange message from a client device; the processor 401 is configured to read the program code 410 stored in the memory 403, and then perform the following operations: replacing a client DH parameter in the original client key exchange message with a man-in-the-middle DH parameter so as to obtain a target client key exchange message; processor 401 instructs network interface 404 to send a target client key exchange message to the server;

in some embodiments, a network interface 404 for receiving an origin server key exchange message from a server; the processor 401 is configured to read the program code 410 stored in the memory 403, and then perform the following operations: replacing a server DH parameter in the original server key exchange message with a man-in-the-middle DH parameter so as to obtain a target server key exchange message; instructing the network interface 404 to send a target server key exchange message to the client device.

In some embodiments, the processor 401 is further configured to replace the server signature in the original server key exchange message with a man-in-the-middle signature.

In some embodiments, processor 401, upon reading program code 410 stored in memory 403, performs the following: generating a first pre-master secret key by using a man-in-the-middle (DH) parameter and a client DH parameter; generating a first session key using the first premaster key, the client random number and the server random number; generating a second premaster secret key by using the intermediate DH parameter and the server DH parameter; and generating a second session key by using the second pre-master key, the client random number and the server random number.

In some embodiments, the processor 401 is configured to extract a client nonce from an original client hello message received by the network interface 404 and a server nonce from an original server hello message received by the network interface 404.

In some embodiments, a network interface 404 for receiving an original client hello message from a client device; after the processor 401 reads the program code 410 stored in the memory 403, the following operations are performed: deleting the identification of the first algorithm in the algorithm list from the original client hello message so as to obtain a target client hello message; instructing the network interface 404 to send a target client hello message to the server.

In some embodiments, the processor 401 is configured to decrypt, by a second algorithm, the original encrypted message using the first session key; encrypting the detected data by using a second session key through a second algorithm to obtain a target encrypted message; after the processor 401 reads the program code 410 stored in the memory 403, the following operations are performed: decrypting the original encrypted message by using a second session key through a second algorithm; and encrypting the detected data by using the first session key through a second algorithm to obtain a target encrypted message.

In some embodiments, the network interface 404 is further configured to receive an original server hello message from the server; after the processor 401 reads the program code 410 stored in the memory 403, the following operations are performed: replacing a server certificate in the original server hello message with a broker certificate so as to obtain a target server hello message; instructing the network interface 404 to send a target server hello message to the client device.

In some embodiments, if the hardware accelerator 405 is configured to generate a session key, the processor 401 inputs the man-in-the-middle DH parameter and the client DH parameter into the hardware accelerator 405, and receives a first session key generated by the hardware accelerator 405; the processor 401 inputs the man-in-the-middle DH parameter and the server DH parameter into the hardware accelerator 405, and receives the second session key generated by the hardware accelerator 405.

In some embodiments, if the hardware accelerator 405 is configured to decrypt the original encrypted message, the processor 401 inputs the first session key and the original encrypted message into the hardware accelerator 405, and receives plaintext data decrypted by the hardware accelerator 405; the processor 401 inputs the second session key and the original encrypted message into the hardware accelerator 405, and receives plaintext data decrypted by the hardware accelerator 405.

In some embodiments, if the hardware accelerator 405 is configured to encrypt the detected data, the processor 401 inputs the second session key and the detected data into the hardware accelerator 405, and receives a target encrypted message encrypted by the hardware accelerator 405; the processor 401 inputs the first session key and the detected data into the hardware accelerator 405, and receives a target encrypted message encrypted by the hardware accelerator 405.

For more details of the above functions, the processor 401, the network interface 404, the memory 403, the hardware accelerator 405, and the like refer to the description of the method embodiments later.

The following describes a method for detecting an encrypted message according to an embodiment of the present application with reference to fig. 6. Fig. 6 is a flowchart of a method 500 for detecting an encrypted message according to an embodiment of the present application. The method 500 includes steps S501 to S514.

Optionally, a network deployment scenario involving the client device, the server, and the guard device in the method 500 is shown in fig. 4. The client device involved in the method 500 is the client device 31 in fig. 4, the server in the method 500 is the server 32 in fig. 4, and the protecting device in the method 500 is the protecting device 33 in fig. 4.

Optionally, the shielding apparatus of method 500 has the structure shown in fig. 5.

The interaction agent of method 500 involves three classes of devices-a guard device, a client device, and a server.

The interaction of the three types of equipment relates to parameters corresponding to the various types of equipment. In order to distinguish and describe the parameters corresponding to different devices, the words "middle man", "client", and "server" are used in this embodiment to refer to the parameters corresponding to the different devices. For example, a guard-device generated DH parameter is referred to using a "man-in-the-middle DH parameter", a client-device generated DH parameter is referred to using a "client DH parameter", and a server generated DH parameter is referred to using a "server DH parameter".

When the three types of equipment are interacted, the protective equipment plays the role of a middle person between the client equipment and the server. The protection device can forward the interactive message between the client device and the server and modify the interactive message between the client device and the server. In order to distinguish and describe the message before the modification of the protection device from the message after the modification, the present embodiment uses the words such as "original" and "target" to refer to the message before the modification of the protection device and the message after the modification of the protection device. For example, the "original encrypted message" refers to an encrypted message received by the protection device, and the "target encrypted message" refers to an encrypted message obtained by the protection device after decryption, detection, encryption, and the like.

Step S501, the protection device sends the man-in-the-middle DH parameters to the client device and the server respectively.

The middle person DH parameter is a DH parameter generated by the protective equipment. In some embodiments, the man-in-the-middle DH parameters are generated by the guard device by performing a large number operation. The DH parameters are the negotiation parameters in the DH algorithm. The DH algorithm is a key agreement algorithm used in SSL/TLS. The DH algorithm includes, but is not limited to, the ECDH algorithm.

After the guard device generates the man-in-the-middle DH parameter, the guard device sends the man-in-the-middle DH parameter to the client device, so that the following guard device and the client device generate a session key through the DH parameters of both sides. And the protection device sends the DH parameter of the man-in-the-middle to the server, so that the subsequent protection device and the server generate a session key through the DH parameters of both sides. The man-in-the-middle parameter sent by the protective device to the client device is the same as the man-in-the-middle parameter sent by the protective device to the server. In some embodiments, the man-in-the-middle DH parameters sent by the guard device to the client device and the server are specifically public portions of DH parameters generated by the guard device. The public part of the DH parameters is the public key in the DH algorithm (e.g., ECDH algorithm).

In some embodiments, the protection device modifies the original handshake message, such as the original server key exchange message and the original client key exchange message, to implement step S501. Specifically, referring to fig. 7, step S501 is implemented by, for example, the flow shown in fig. 7. The flow shown in fig. 7 is an explanation of step S501 in the flow shown in fig. 6. The flow shown in fig. 7 includes the following steps S5010 to S5019.

Step S5010, the server generates and sends an original server key exchange packet to the client device.

The origin server key exchange message includes the server DH parameters. The server DH parameters are, for example, the public part of the server generated DH parameters. In some embodiments, the origin server key exchange message includes a server signature. The server signature is a digital signature generated by the server. Specifically, the server signature is obtained by the server signing the server DH parameters using the server's private key.

Step S5011, the protection device receives an original server key exchange packet from the server.

Step S5012, the protection device replaces the server DH parameter in the original server key exchange message with the man-in-the-middle DH parameter, so as to obtain a target server key exchange message, where the target server key exchange message includes the man-in-the-middle DH parameter.

In addition, the guard device replaces the server signature in the original server key exchange message with a man-in-the-middle signature. The target server key exchange message includes a man-in-the-middle signature.

The man-in-the-middle signature is a digital signature generated by the guard. Specifically, the protection device uses a private key of the protection device to digest and encrypt the client random number, the server random number and the man-in-the-middle DH parameter to obtain a man-in-the-middle signature.

Step S5013, the protection device sends the target server key exchange packet to the client device.

Step S5014, the client device receives the target server key exchange packet from the protection device, and the client device obtains the man-in-the-middle DH parameter from the target server key exchange packet.

In some embodiments, the client device obtains the man-in-the-middle signature from the target server key exchange message. The client device verifies the man-in-the-middle signature. And if the man-in-the-middle signature passes the verification, the client equipment stores the man-in-the-middle DH parameter and sends an original client key exchange message.

Step S5015, the client device generates and sends an original client key exchange packet to the server, where the original client key exchange packet includes a client DH parameter.

The client DH parameters in the original client key exchange message are, for example, the public part of the DH parameters generated by the client.

Step S5016, the protection device receives the original client key exchange packet from the client device.

Step S5017, the protection device replaces the client DH parameter in the original client key exchange message with the man-in-the-middle DH parameter, so as to obtain a target client key exchange message, where the target client key exchange message includes the man-in-the-middle DH parameter.

Step S5018, the protection device sends the target client key exchange message to the server.

Step S5019, the server receives the target client key exchange packet from the protection device, and the server obtains the broker DH parameter from the target client key exchange packet.

Through the communication flow described in the above steps S5010 to S5019, a stateless processing manner similar to that on the device side is provided, which can further reduce the resource overhead of the protection device on the basis of realizing parameter multiplexing, and is helpful to ensure the compatibility and security of the added middle person to the maximum extent when no middle person exists. The technical principle for achieving this effect will be explained below.

Referring to fig. 3, in a conventional scheme for implementing SSL broker, the guard devices need to maintain connection states of the client device and the server. When the protection device and the client perform handshake, the protection device needs to completely generate each handshake message sent to the client device; when the protection device and the server perform handshake, the protection device needs to completely generate each handshake message sent to the server, and the processing flow is complex and may need to be trapped in the kernel.

In the embodiment, in the steps S5010 to S5019, the handshake process between the real client and the server is used for driving, and the protection device can handshake with both sides only by generating fewer parameters, performing message parsing and content replacement on the basis of the handshake messages sent from both sides, which can reduce a large amount of resource overhead. Specifically, when the guard device and the client handshake, the guard device executes the steps of DH parameter replacement, signature modification and the like on the basis of the server key exchange message sent by the real server, that is, the server key exchange message can be sent to the client; when the protective equipment and the server perform handshake, the protective equipment executes the steps of DH parameter replacement and the like on the basis of the client key exchange message sent by the real client, so that the client key exchange message can be sent to the server, thereby avoiding SSL handshake performed independently and at two ends of the protective equipment, and avoiding the complex processing flow of OpenSSL.

Referring back to the flow shown in fig. 6, in step S502, the secure device generates the first session key according to the man-in-the-middle DH parameter and the client DH parameter.

The client DH parameters are DH parameters generated by the client device. The first session key refers to a session key between the guard device and the client device.

In some embodiments, the first session key is generated by a premaster secret in combination with the client random number and the server random number. Specifically, the protection device generates a first pre-master key by using a man-in-the-middle (DH) parameter and a client DH parameter; the protection device generates a first session key using the first premaster secret key, the client random number and the server random number. The client random number is a random number generated by the client device, and the server random number is a random number generated by the server.

Step S503, the protection device generates a second session key according to the man-in-the-middle DH parameter and the server DH parameter.

The server DH parameters are server generated DH parameters. The second session key refers to a session key between the secure device and the server.

In some embodiments, the second session key is generated by a premaster secret in combination with the client random number and the server random number. Specifically, the protection device generates a second premaster secret key by using a man-in-the-middle (DH) parameter and a server (DH) parameter; the protection device generates a second session key using the second premaster key, the client random number, and the server random number.

The protection device realizes the multiplexing of the DH parameters of the man-in-the-middle by executing the steps S501 to S503, thereby greatly reducing the operation cost and greatly improving the SSL/TLS handshake speed. The technical principle of this effect is explained below with reference to fig. 3. In a conventional manner, when the security device implements SSL/TLS broker, two broker DH parameters need to be generated for both sides of the client device and the server. Specifically, referring to fig. 3, when the security device and the client device perform SSL/TLS handshake, the security device generates and sends a man-in-the-middle DH parameter 1 to the client device; when the protective device and the server perform SSL/TLS handshake, the protective device generates and sends a man-in-the-middle DH parameter 2 to the server. The man-in-the-middle parameter 1 sent by the protection device to the client device and the man-in-the-middle parameter 2 sent by the protection device to the server are two independent DH parameters which need to be generated through DH operation respectively. Therefore, the guard device needs to perform a large number of complex calculations, resulting in a large consumption of performance. In this embodiment, the protection device sends the same man-in-the-middle DH parameter to the client device and the server, and uses the same man-in-the-middle DH parameter when negotiating session keys with the client device and the server, respectively, so that the DH parameter is multiplexed, and the amount of computation required for generating the DH parameter is reduced. Particularly, under the condition that the DH parameters are generated through large number operation, the expense of large number operation (namely the expense of generating the middle person DH parameters) is obviously reduced, and only the expense is considered, the new building speed is expected to be increased by nearly 20 percent, and the processing performance of the whole machine is greatly improved.

The communication process of SSL/TLS is divided into a session negotiation stage and a data transmission stage. Steps S501 to S503 in fig. 6 above are examples of steps involved in the session negotiation phase. The steps involved in the data transfer phase are illustrated below by steps S504 to S514 in fig. 6. The data transmission phase includes a scenario in which the client sends data to the server or a scenario in which the server sends data to the client, the transmission process of the scenario in which the client sends data to the server refers to steps S504 to S509, and the transmission process of the scenario in which the server sends data to the client refers to steps S510 to S514.

Step S504, when the client device is about to send data to the server, the client device encrypts the service data by using the first session key to obtain an original encrypted message.

Step S505, the client device sends the original encrypted message.

Step S506, the protection device receives the original encrypted message from the client device.

Step S507, the protection device decrypts the original encrypted message from the client device using the first session key, detects the decrypted plaintext data, and encrypts the detected data using the second session key to obtain the target encrypted message.

And step S508, the protective equipment sends the target encrypted message to the server.

Step S509, the server decrypts the target encrypted packet by using the second session key, so as to obtain plaintext data detected by the protection device.

Step S510, when the server wants to send data to the client device, the server encrypts the service data using the second session key to obtain an original encrypted message. The server sends the original encrypted message.

Step S511, the protection device receives the original encrypted message from the server.

Step S512, the protection device decrypts the original encrypted message from the server using the second session key, detects the decrypted plaintext data, and encrypts the detected data using the first session key to obtain the target encrypted message.

Step S513, the protection device sends the target encrypted message to the client device.

Step S514, the client device decrypts the target encrypted message by using the first session key, so as to obtain plaintext data detected by the protection device.

It should be noted that, steps S504 to S509 shown in fig. 6 are preceded by steps S510 to S514, and the following steps are merely exemplary, and the timing sequence of steps S504 to S509 and steps S510 to S514 is not limited in this embodiment. In some embodiments, steps S504 to S509 and steps S510 to S514 are performed sequentially. For example, step S504 to step S509 are performed first, and then step S510 to step S514 are performed; for another example, step S510 to step S514 are executed first, and then step S504 to step S509 are executed. In other embodiments, steps S504 to S509 are executed in parallel with steps S510 to S514, that is, steps S504 to S509 and steps S510 to S514 are executed simultaneously.

According to the method provided by the embodiment, the SSL handshake flow between the protection device and the client device and the SSL handshake flow between the protection device and the server are associated, the same DH parameters are respectively sent to the client device and the server by the protection device, and the DH parameters on two sides are multiplexed when the session key is generated, so that the calculated amount caused by generation of the DH parameters is reduced, the resource occupation of the protection devices such as a firewall is saved, the SSL handshake speed is greatly improved, and the performance of the protection device is improved.

In some embodiments, the guard device further deletes an unsupported algorithm from the algorithm list sent by the client, and forwards the deleted algorithm list to the server, so that the server selects a final negotiated algorithm from the deleted algorithm list from the client and the guard device, thereby associating an algorithm used for encryption and decryption between the guard device and the client with an algorithm used for encryption and decryption between the guard device and the server.

For example, referring to fig. 8, a flow example of the deletion algorithm includes steps S521 to S526 described below.

Step S521, the client device generates and sends an original client hello (client hello) message.

The original client hello message is a handshake message in the SSL/TLS protocol. The original client hello message includes an algorithm list and a client random number. The algorithm list and the client random number in the original client hello message are both generated by the client device.

The list of algorithms in the original client hello message is used to describe at least one algorithm supported by the client device. The list of algorithms includes an identification of at least one algorithm. The algorithm list is used for the server to select the algorithm used in the encryption and decryption in the data transmission stage. For example, the client hello message sent by the client device contains the list of algorithms shown in table 1 below. The list of algorithms shown in table 1 contains an identification of 5 algorithms, each of which 5 algorithms is supported by the client device.

TABLE 1

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
	TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_256_CBC_SHA

Step S522, the guard device receives an original client hello message from the client device.

Step S523, the protection device deletes the identifier of the first algorithm in the algorithm list from the original client hello message, so as to obtain the target client hello message.

Step S524, the protection device sends a target client hello message to the server.

The first algorithm is an algorithm that is not supported by the guard device. The first algorithm is an algorithm for encrypting and decrypting data.

The target client hello message is a message obtained after the protection device deletes the algorithm. The target client hello message includes an algorithm list. The list of algorithms in the target client hello message includes the identities of at least one algorithm other than the first algorithm, i.e., the identities of some algorithms remaining after the guard device is deleted. The list of algorithms in the target client hello message is used to describe at least one algorithm supported by both the client device and the guard device. Specifically, because the algorithms in the algorithm list sent by the client device are algorithms supported by the client device, and the guard device deletes the algorithms that are not supported by the guard device, the remaining algorithms after deletion can be supported by both the client device and the guard device.

For example, the client device provides 5 algorithms shown in table 1 for selection by the server. The client hello message received by the guard device includes the algorithm list shown in table 1 above. When the guard device checks whether the algorithm list in the client hello message includes an algorithm that is not supported by the guard device, it finds that the guard device does not support the fourth algorithm "TLS _ RSA _ WITH _ RC4_128_sha" in table 1. The guard deletes the fourth algorithm "TLS _ RSA _ WITH _ RC4_128_sha" from the algorithm list in the client hello message, resulting in the algorithm list shown in table 2 below. The algorithm list of the client hello message sent by the guard device to the server includes the algorithm list shown in table 2 below. The relationship between the algorithm list shown in table 2 and the algorithm list shown in table 1 is that the algorithm list shown in table 2 contains the identification of 4 other algorithms than "TLS _ RSA _ WITH _ RC4_128_sha" in the algorithm list shown in table 1. The 4 algorithms shown in table 2 are all supported by both the guard device and the client device. Where the algorithm identified by "TLS _ RSA _ WITH _ RC4_128_SHA" is an illustration of the first algorithm.

TABLE 2

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
	TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
	TLS_RSA_WITH_AES_256_CBC_SHA

Step S525, the server receives the target client hello message.

And step S526, the server selects a second algorithm from the remaining algorithms after the protection device is deleted according to the algorithm list in the hello message of the target client.

The second algorithm is an algorithm negotiated by three parties (client device, server and guard device) in the handshake phase. The second algorithm is an algorithm used by three parties in the data transmission stage to encrypt and decrypt data. The second algorithm is one of the algorithms in the algorithm list in the target client hello message. In other words, the second algorithm identifies the corresponding algorithm for the remaining algorithms after the identification of the first algorithm is deleted from the algorithm list.

The second algorithm is an algorithm supported by the guard device, the client device, and the server. Specifically, the server selects an algorithm (second algorithm) supported by the server from the algorithm list in the received client hello message according to the algorithm supported by the server.

For example, the client device sends an algorithm list describing 5 algorithms shown in table 1, and after deleting an identifier of one algorithm from the algorithm list, the protecting device sends an algorithm list describing 4 algorithms shown in a server forwarding table 2. After the server receives the algorithm list shown in table 2, the server finds that the server supports the 3 rd algorithm TLS _ ECDHE _ ECDSA _ WITH _ AES _128_gcm _sha256among the 4 algorithms shown in table 2. The server selects the 3 rd algorithm TLS _ ECDHE _ ECDSA _ WITH _ AES _128_gcm _sha256. In this example, the algorithm identified by TLS _ ECDHE _ ECDSA _ WITH _ AES _128_gcm _sha256 is illustrative of the second algorithm.

In some embodiments, the server maintains a list of algorithms that the server supports. And the server compares the algorithm list in the hello message of the target client with a locally stored algorithm list. If an algorithm is found that exists in both the algorithm list in the target client hello message and the locally stored algorithm list, the server selects the algorithm (second algorithm).

When the handshake phase employs the above-described steps S521 to S526, the subsequent data transmission phase is realized by, for example, the following steps S504 'to S514'. Steps S504 'to S514' described below correspond to steps S504 to S514 in the flow shown in fig. 6, respectively.

Step S504', when the client device is about to send data to the server, the client device encrypts the service data by using the first session key through the second algorithm to obtain an original encrypted message.

In some embodiments, the guard device determines the algorithm selected by the server as the second algorithm according to the original server hello message from the server; and the client equipment determines the algorithm selected by the server as a second algorithm according to the target server hello message from the protective equipment.

For example, when the server sends a server hello message, the server carries the identity of the server-selected algorithm in the server hello message and sends an original server hello message that includes the identity of the second algorithm. And after receiving the original server hello message, the protection equipment determines the algorithm selected by the server as the second algorithm according to the identifier of the second algorithm in the original server hello message. And the protection equipment performs certificate replacement and other processing on the server hello message sent by the server to generate a target server hello message, and the target server hello message still carries the identifier of the second algorithm. The guard device sends a target server hello message to the client device. And after the client equipment receives the hello message of the target server, determining the algorithm selected by the server as the second algorithm according to the identifier of the second algorithm in the hello message of the target server.

Step S505', the client device sends the original encrypted message.

Step S506', the guard device receives the original encrypted message from the client device.

Step S507', the protection device decrypts the original encrypted message by using the first session key through the second algorithm, and detects plaintext data obtained through decryption. And the protection equipment encrypts the detected data by using a second session key through a second algorithm to obtain a target encrypted message.

Step S508', the protection device sends the target encrypted message to the server.

Step S509', the server decrypts the target encrypted packet by using the second session key through the second algorithm, so as to obtain plaintext data detected by the protection device.

Step S510', when the server wants to send data to the client device, the server encrypts the service data by using the second session key through the second algorithm, so as to obtain an original encrypted message. The server sends the original encrypted message.

Step 511', the protection device receives the original encrypted message from the server.

Step S512', the protection device decrypts the original encrypted message from the server by using the second session key through the second algorithm, detects the decrypted plaintext data, and encrypts the detected data by using the first session key through the second algorithm to obtain the target encrypted message.

Step S513', the protection device sends the target encrypted message to the client device.

Step S514', the client device decrypts the target encrypted packet by using the first session key through the second algorithm, so as to obtain the plaintext data detected by the protection device.

Through the process, on one hand, communication failure caused by the fact that the protective equipment does not support an algorithm negotiated between the client and the server in the data transmission stage is avoided, and reliability and success rate of data transmission are improved. On the other hand, the method gives consideration to safety and compatibility, and ensures that the algorithm used by the protective equipment meets the requirements of the client and the server on the flow transmission safety. The principle of achieving this effect will be described below.

On one hand, in the SSL/TLS protocol, a client negotiates an encryption and decryption algorithm used in subsequent data transmission with a server by sending a client hello message to the server. Specifically, the client carries a series of algorithms supported by the client in a client hello message in an algorithm list form and sends the algorithm list to the server. After receiving the client hello message, the server finds out the algorithms supported by both parties through the algorithm list in the client hello message, and informs the client of the algorithms as negotiated algorithms. The client and the server then encrypt and decrypt the data using the negotiated algorithm during the data transmission phase.

If the algorithm negotiated by the client and the server is an algorithm which is not supported by the protection device, when the protection device receives the encrypted data transmitted between the client and the server, the encrypted data cannot be decrypted to obtain plaintext data, and the plaintext data cannot be subjected to security detection, so that the security detection fails.

By the SSL/TLS handshake process provided in this embodiment, each algorithm remaining in the algorithm list after the algorithm is deleted is an algorithm supported by the protection device because the protection device deletes an unsupported algorithm from the algorithm list of the client hello packet. Therefore, after the protective device forwards the client hello message after the algorithm is deleted to the server, the algorithm list in the client hello message received by the server does not contain the algorithm which is not supported by the protective device. In other words, the algorithms in the algorithm list in the client hello message received by the server are all algorithms supported by the protection device. Therefore, when the server selects an algorithm from the algorithm list in the client hello message, the algorithm selected by the server (i.e., the algorithm negotiated in the SSL/TLS handshake phase) is an algorithm supported by the protection device.

Then, because the algorithm negotiated in the handshake phase is an algorithm supported by the protection device, it is ensured that the client, the protection device, and the server all use the algorithms supported by the three parties to encrypt and decrypt data in the data transmission phase, and the failure of security detection caused by the fact that the protection device does not support the algorithm required by decryption is avoided.

On one hand, from the perspective of security and compatibility, in the conventional SSL broker scheme as shown in fig. 3, it is impossible to achieve both security and compatibility. This is because the algorithm list sent by the guard device to the server is generated independently by the guard device itself, regardless of the algorithm list provided by the client. Specifically, the operation and maintenance personnel can pre-configure the algorithm list on the protection device. The protective device is pre-configured with which algorithm, and when the protective device and the server perform handshake, which algorithm is placed in the algorithm list and sent to the server. In other words, the list of algorithms issued by the guard device to the server is fixed (depending on the pre-configuration) regardless of which algorithms the list of algorithms issued by the client contains.

And the algorithm is configured with 2 options, namely, the algorithm with high safety is configured, or the algorithm with good compatibility but certain safety risk is configured. If the protection device configures a high-security algorithm, when the client or the server cannot support the high-security algorithm, a problem of compatibility is introduced, which results in a failure of negotiation. If the protection device configures an algorithm with good compatibility, the security is reduced when the client or the server has a high requirement on the security of the algorithm.

The embodiment skillfully solves the dilemma through the flow of the interactive algorithm list, and balances the safety and the compatibility. Specifically, the algorithm list is generated by the client, and the guard device modifies the algorithm list. If the client needs to use the high-security algorithm, the client sends a list containing the high-security algorithm to the protective equipment, the protective equipment sends the algorithm list from the client to the server after deleting the unsupported algorithm, and after the server selects the algorithm from the residual high-security algorithms after deleting, the high-security algorithm selected by the server is used for three-way encryption and decryption, so that the requirement on security is met. If the client needs to use the algorithm with good compatibility, the client sends a list containing the high-compatibility algorithm to the protective equipment, the protective equipment sends the algorithm list from the client to the server after deleting the algorithm which is not supported, and after the server selects the algorithm from the high-compatibility algorithms which are left after deleting, the high-compatibility algorithm selected by the server is used for encryption and decryption by three parties, so that the requirement on compatibility is met. In summary, the algorithm used when the protection device interacts with the two sides no longer only depends on fixed configuration, but is determined according to the security requirement of the client and the selection of the server, so that the adaptive selection of security and compatibility is realized, the security and the compatibility are both considered, and the flexibility is high.

In some embodiments, the guard device also ensures that the man-in-the-middle signature passes verification of the client device by replacing the certificate of the server, thereby avoiding transmission failure of data (e.g., man-in-the-middle DH parameters) transmitted to the client device with the man-in-the-middle signature due to failed signature verification.

For example, referring to fig. 9, the flow of replacing the certificate includes the following steps S531 to S534.

Step S531, the server generates and sends a hello message of the original server.

The original server hello message includes the server certificate. The server certificate includes the public key of the server.

Step S532, the protection device receives the original server hello message from the server.

Step S533, the protection device replaces the server certificate in the original server hello message with the intermediary certificate, so as to obtain a target server hello message.

The target server hello message includes a broker certificate. The intermediary certificate includes the public key of the guard device.

Step S534, the protection device sends a target server hello message to the client device.

The client device receives a target server hello message. The client device obtains the public key of the guard device from the broker certificate in the target server hello message, and stores the public key of the guard device as the public key of the opposite end in the SSL/TLS session. And then, when the client device interacts with the protection device, the protection device generates a man-in-the-middle signature by using a private key of the protection device, and the client device verifies the man-in-the-middle signature by using a public key of the protection device.

For example, in the flow shown in fig. 7, the target server key exchange message sent by the protecting device in step S5013 includes the broker signature and the broker DH parameter. When the client device receives the target server key exchange message, the client device verifies the man-in-the-middle signature by using the public key of the protection device. Because the public key of the protection device and the private key used for generating the man-in-the-middle signature are a pair of keys which can be mutually encrypted and decrypted, the man-in-the-middle signature can be verified by the client device, and the client device can store the DH parameter of the man-in-the-middle and send an original client key exchange message.

In some embodiments, the guard device extracts and forwards the random number in the original hello message, thereby multiplexing the random numbers generated by the client device and the server, and avoiding the overhead caused by the independent generation of the random number by the guard device.

Specifically, referring to fig. 3, in the method shown in fig. 3, in order to generate a session key between the guard device and the client and a session key between the guard device and the server, the guard device is required to generate two sets of man-in-the-middle random numbers by itself. Specifically, when the protection device interacts with the server, the protection device needs to generate a man-in-the-middle random number 1, the protection device sends the man-in-the-middle random number 1 to the server, and the subsequent protection devices and the server both use the man-in-the-middle random number 1 and the server random number to generate a session key 2. When the protection device interacts with the client device, the protection device needs to generate a man-in-the-middle random number 2, the protection device sends the man-in-the-middle random number 2 to the client device, and the subsequent protection device and the client device both use the man-in-the-middle random number 2 and the client random number to generate a session key 1. Obviously, generating the man-in-the-middle random number 1 and the man-in-the-middle random number 2 generates a certain resource overhead, which consumes the computing power of the protection device.

In some embodiments of the present application, after receiving an original client hello message sent by a client device, a guard device further extracts a client random number from the original client hello message. The target client hello message sent to the server by the protection device comprises a client random number, so that the client random number generated by the client device is transmitted to the server. And the subsequent protective equipment and the server both use the client random number and the server random number to generate a second session key, so that the client random number generated by the client equipment is multiplexed, and the resource overhead caused by generating the man-in-the-middle random number 1 is avoided. After the protection device receives the original server hello message sent by the server, the protection device also extracts the server random number from the original server hello message. The target server hello message sent to the client device by the protection device comprises the server random number, so that the server random number generated by the server is transmitted to the client device. The subsequent protection equipment and the client equipment both use the client random number and the server random number to generate a first session key, so that the server random number generated by the server is multiplexed, and resource overhead caused by generation of the man-in-the-middle random number 2 is avoided.

Summarizing the DH parameter replacement, signature replacement, certificate replacement, and random number extraction described above, it can be seen that the SSL broker scheme provided in this embodiment does not use an OpenSSL library to perform a complete black box handshake process, but uses an original handshake message as a trigger to extract and modify information (such as DH parameters, random numbers, signatures, and certificates) related to key negotiation in the original handshake message, so as to complete two-side negotiation of a session key. Because a complex processing flow of OpenSSL is not needed, the technical dilemma that the OpenSSL is likely to be trapped in a kernel is avoided, the implementation complexity of the scheme is reduced, and the resource occupation of the protective equipment is reduced. Meanwhile, a bank for realizing SSL interaction completely is not needed, and the problems of safety and compatibility of a self-research SSL bank are avoided. After the key is obtained, in the subsequent symmetric processing stage, the session processing flow of OpenSSL is optionally no longer used, but the security device itself implements parsing of the SSL record (SSL record) layer. In particular, it is advantageous to hardware the subsequent symmetric encryption processing portion (the processing of this portion is implemented using logic, ASIC, etc.), as described in detail below.

In some embodiments, the steps involving DH operation, encryption, and decryption are accelerated by hardware. In particular, the guard device includes one or more hardware accelerators. The hardware accelerator is, for example, encryption accelerator 333 in fig. 4.

The hardware accelerator is dedicated hardware that executes either the DH algorithm or the encryption/decryption algorithm. The hardware accelerator is used for accelerating the steps needing to adopt the DH algorithm or the encryption and decryption algorithm, so that the performance of the protective device for negotiating the key, encrypting data or decrypting data based on the DH algorithm is improved.

Hardware accelerators include, but are not limited to, field Programmable Gate Arrays (FPGAs), application Specific Integrated Circuits (ASICs), system on chips (socs), central Processing Units (CPUs), network Processors (NPs), digital signal processing circuits (DSPs), micro Controllers (MCUs), programmable Logic Devices (PLDs), or other integrated chips.

In conjunction with the method shown in fig. 6, for example, a hardware accelerator is used to generate a session key, decrypt an original encrypted message, or encrypt detected data.

For example, if the hardware accelerator is used to generate the session key, the step S502 is implemented as follows: the protection device inputs the DH parameter of the man-in-the-middle and the DH parameter of the client into the hardware accelerator and receives a first session key generated by the hardware accelerator. The above step S503 is implemented as follows: and the protection equipment inputs the intermediate DH parameters and the server DH parameters into the hardware accelerator and receives a second session key generated by the hardware accelerator.

For example, if the hardware accelerator is used to decrypt the original encrypted message, the step S507 is implemented as follows: the protection equipment inputs the first session secret key and the original encrypted message into the hardware accelerator and receives plaintext data obtained by decryption of the hardware accelerator. The above step S512 is implemented as follows: and the protection equipment inputs the second session key and the original encrypted message into the hardware accelerator and receives plaintext data decrypted by the hardware accelerator.

For example, if the hardware accelerator is used to encrypt the detected data, the step S507 is implemented as follows: and the protection equipment inputs the second session key and the detected data into the hardware accelerator and receives a target encrypted message encrypted by the hardware accelerator. Step S512 is implemented as follows: and the protection equipment inputs the first session key and the detected data into the hardware accelerator and receives a target encrypted message encrypted by the hardware accelerator.

The protection device realizes the steps in the flow of the method shown in the attached figure 6 by adopting a hardware acceleration means, so that tasks such as DH operation, encryption processing and the like which consume a large amount of computing power in the SSL agent are unloaded from a CPU to a hardware accelerator, namely the most-consumption algorithm part adopts special acceleration hardware processing, the occupation of the SSL agent on the computing power of the CPU is reduced, the resource occupation is greatly improved, the performance is greatly improved, and the protection device is accelerated to realize the processing flow of the SSL agent.

The following describes the complete flow of the SSL broker scheme in conjunction with an example.

In the following example, the first session key is a session key 1, the second session key is a session key 2, the first premaster key is a premaster key 1, the second premaster key is a premaster key 2, and the broker DH parameter sent by the guard device to the client device and the server is Pubkey _ fw. And the DH parameter of the client replaced by the protective device is Pubkey _ C. The parameter of the server DH replaced by the protective device is Pubkey _ S. Wherein, fw in Pubkey _ fw means firewall (fire Wall). The meaning of S in Pubkey _ S is server (server). The meaning of C in Pubkey _ C is Client (Client).

As shown in fig. 10, the following example includes the following steps S61a to S66b in the handshake phase.

And S61a, the client equipment sends an original client hello message. The original client hello message includes the client random number and the algorithm list supported by the client device.

And S61b, after the protection equipment receives the original client hello message, the protection equipment analyzes the original client hello message, and the protection equipment extracts the client random number in the original client hello message. The protective device checks whether the algorithm list of the original client hello message contains an algorithm which is not supported by the protective device. If the algorithm list of the original client hello message contains the algorithm which is not supported by the protective device, the protective device deletes the algorithm which is not supported by the protective device from the original client hello message, so that the target client hello message is obtained. And then, the protective equipment forwards the target client hello message to the server.

And step S62a, after the server receives the target client hello message, the server selects a version and an algorithm supported by the server from information provided by the client equipment in the target client hello message. The server generates an original server hello message according to the selected algorithm, the random number generated by the server (server random number) and the server certificate. The server sends an original server hello message to the client device. The original server hello message includes an identification of the algorithm selected by the server, the server random number, and the server certificate. The server certificate includes the public key of the server.

Step S62b, the protection device receives the original server hello message of the server. The protective equipment extracts the server random number and the identification of the algorithm in the original server hello message. The protecting equipment regenerates the certificate (the man-in-the-middle certificate) reissued by the protecting equipment, and replaces the server certificate in the original server hello message with the man-in-the-middle certificate. The intermediary certificate includes the public key of the guard device. The protection device sends the target server hello message to the client device. The target server hello message includes an identifier of the algorithm selected by the server.

Step S63a, if the server chooses to use the DH negotiation algorithm to negotiate the session key according to the option of the target client hello packet in step S62a, the server generates its own DH parameter (server DH parameter) in step S63 a. And the server signs the client random number, the server random number and the server DH parameter by using a private key of the server to obtain a server signature. The server carries the public part (Pubkey _ S) of the DH parameter and the server signature in an original server key exchange message, and sends the original server key exchange message to the client equipment.

For example, the server selects the elliptic curve algorithm secp256r1 to negotiate a session key. The original server key exchange message sent by the server includes the contents shown in table 3 below. The contents of the Pubkey field in table 3 (043 c334e8058c5fb31fa8fa517a44d59e9dbeb3705a0612 \8230;) are the server DH parameters. The contents of the Signature field in table 3 (483 fa3177932cf6512ba616444e84d7d98349e60fc29e 959) are server signatures.

TABLE 3

In table 3, "043c334e8058c5fb31fa8fa517a44d59e9dbeb3705a0612 \8230;" middle "\8230;" ellipsis, "\8230;" indicates that the Pubkey field further includes and omits contents not shown, that is, the DH parameters further include and do not show the portions. The meaning of the ellipses in the contents of the Pubkey field in the other tables shown later herein is the same.

"483fa3177932cf6512ba616444e84d7d98349e60fc29e959 \8230;" middle "\8230;" ellipses, "\8230;" indicates that the Signature field also includes and omits content not shown, that is, the Signature also includes and does not include a portion in the Signature field in table 3. The meaning of the ellipses in the content of the Signature field in the other tables shown here below is the same.

The contents of the fields other than the Pubkey field and the Signature field in table 3 have the following meanings.

The contents of the handshake protocol field are server key exchanges. The content of the handshake type field (i.e. the type of handshake message in the SSL/TLS protocol) is the server key exchange, and the handshake type is represented by a value 12. The content of the length field is 329. The ECDH server parameter field includes a curve type field, a curve name field, a Pubkey length field, and a Pubkey field. The contents of the curve type field are named curves, the curve type being represented by the value 0x 03. The contents of the curve name field are secp256r1, which is represented by the value 0x 0017. The contents of the curve type field and the curve name field indicate that the generation algorithm of Pubkey is secp256r1. The content of the Pubkey length field is 65. The content of the signature algorithm (the algorithm used when generating the server signature) field is rsa _ pkcs1sha512, which is represented by the value 0x 0601. The content of the signature length (length of server signature) field is 256.

Step S63b, after the protection device receives the original server key exchange message sent by the server, the protection device extracts Pubkey _ S (server DH parameter) in the original server key exchange message. Then, the guard device replaces Pubkey _ S (server DH parameter) in the original server key exchange message with Pubkey _ fw (man-in-the-middle DH parameter) generated by the guard device using the same algorithm. And the protection device signs the client random number, the server random number and the man-in-the-middle DH parameter by using a private key of the protection device, so as to regenerate the man-in-the-middle signature. The guard device replaces the server signature in the original server key exchange message with a man-in-the-middle signature. And then, the protection equipment sends the target server key exchange message to the client equipment.

For example, the original server key exchange message received by the guard device includes the content shown in table 3, the guard device replaces the content of Pubkey field in table 3 with the man-in-the-middle DH parameter, the guard device replaces the content of Signature field in table 3 with the man-in-the-middle Signature, so as to obtain the target server key exchange message including the content shown in table 4 below, and sends the target server key exchange message including the content shown in table 4 below to the client device. The contents of the Pubkey field in table 4 (04083 f0c2b627d51d88fff2d2d9fa373328d \8230;) are the man-in-the-middle DH parameters. The contents of the Signature field in Table 4 (046 f476af7cd0e95f912246656d2bc7b1cccb7f490133e90 \8230;) are the man-in-the-middle signatures.

TABLE 4

The meaning of the contents of the fields in table 4 except Pubkey field and Signature field is the same as that in table 3, please refer to the description in table 3.

Comparing table 3 with table 4, it can be seen that the contents of the 2 fields, i.e., pubkey field and Signature field, in table 4 are different from table 3, the contents of the 2 fields in table 4 are generated by the guard device, and the contents of the fields other than the 2 fields in table 4 can directly reuse table 3 without depending on the complex processing logic, such as session state, of the guard device itself. In one example, after receiving an original server key exchange message containing the content shown in table 3 sent by a server, the guard device modifies the content of Pubkey field and the content of Signature field in table 3 to obtain a target server key exchange message containing the content shown in table 4, and sends the target server key exchange message containing the content shown in table 4 to a client, thereby realizing handshake between the guard device and the client. Obviously, the implementation method simplifies the processing logic of the protection device and saves the expense of the protection device.

Step S64a, after the client device receives the target server key exchange message sent by the protection device, the client device generates and sends an original client key exchange message. The original client key exchange message includes a client DH parameter. The DH parameter of the client is specifically the public part Pubkey _ C of the DH parameter.

For example, the original client key exchange message sent by the client device includes the contents shown in table 5 below. The content of the Pubkey field in table 5 (0456 be94b776d9a32dc00d4f673bb3f9c232b2526575066 \8230;) is the client DH parameter.

TABLE 5

The contents of the fields other than the Pubkey field in table 5 have the following meanings.

The contents of the handshake protocol field are client key exchanges. The contents of the handshake type field, which is indicated by a value 16, are client key exchanges. The content of the length field is 66. The ECDH client parameter field includes a Pubkey length field and a Pubkey field. The content of the Pubkey length field is 65.

And S64b, the protection device receives the original client key exchange message of the client device. After the guard device extracts the client DH parameter Pubkey _ C in the original client key exchange message, the guard device replaces the client DH parameter Pubkey _ C in the original client key exchange message with the DH parameter Pubkey _ fw (man-in-the-middle DH parameter) of the guard device. And then, the protection device sends the target client key exchange message to the server.

For example, the original client key exchange message received by the guard device includes the content shown in table 5, the guard device replaces the content of the Pubkey field in table 5 with the man-in-the-middle DH parameter, so as to obtain a target client key exchange message including the content shown in table 6 below, and sends the target client key exchange message including the content shown in table 6 below to the server. The contents of the Pubkey field in Table 6 (04083 f0c2b627d51d88fff2d2d9fa373328d 8230;) are the man-in-the-middle DH parameters.

TABLE 6

The content meanings of the fields other than the Pubkey field in table 6 are the same as those in table 5, please refer to the description of table 5.

Comparing table 4 with table 6, it can be seen that the contents of Pubkey fields in table 4 and table 6 are the same, that is, the man-in-the-middle DH parameter sent by the guard device to the server is the same as the man-in-the-middle DH parameter sent by the guard device to the client device, which can realize multiplexing of DH parameters and save the overhead of generating 2 parts of DH parameters respectively.

In addition, comparing table 5 and table 6, it can be seen that the content of Pubkey field in table 6 is different from table 5, the content of Pubkey field in table 6 is generated by the guard, and the content of other fields except Pubkey field in table 6 can directly use table 5 without depending on the complex processing logic such as session state generated by the guard itself. In one example, after receiving an original client key exchange message containing the content shown in table 5 sent by a client, the guard device modifies the content of Pubkey field in table 5 to obtain a target client key exchange message containing the content shown in table 6, and the handshake between the guard device and the server is realized by sending the target client key exchange message containing the content shown in table 6 to the server. Obviously, the implementation mode simplifies the processing logic of the protection device and saves the expense of the protection device.

Step S65a, the client device performs calculation using the private part of the DH parameter of the client device and Pubkey _ fw, so as to obtain the premaster secret key 1. The guard uses Pubkey _ C and the private part of the guard DH parameters to perform calculations, thus obtaining the same premaster secret key 1.

Step S65b, like step S65a, the server performs calculation using the server DH parameter private part and Pubkey _ fw, thereby obtaining the premaster key 2. The guard uses Pubkey _ S and the private part of the guard DH parameters to perform calculations, thus obtaining the same premaster secret key 2.

Step S66a, the client device and the protection device each perform calculation using the premaster secret key 1, the client random number and the server random number, so as to obtain the same session secret key 1.

Step S66b, the server and the protecting device perform calculation by using the premaster secret key 2, the client random number and the server random number, so as to obtain the same session secret key 2.

At this time, the session negotiation part is completed, and the transmission process of the subsequent client device sending data to the server is as follows, including steps (1-1) to (1-4).

And (1-1) when the client equipment sends the data message to the server, the client equipment encrypts the plaintext data by using the session secret key 1 to obtain an encrypted message and sends the encrypted message.

And (1-2) after the protective equipment receives the encrypted message sent by the client equipment, the protective equipment decrypts by using the session key 1, and then the protective equipment performs content check on the decrypted plaintext data.

And (1-3) if the clear data is checked to be free of threats, the protection equipment encrypts the checked data by using the session key 2 and then sends the encrypted data to the server.

And (1-4) after the server receives the encrypted message from the protective equipment, the server decrypts the encrypted message by using the session key 2.

The transmission process of the server sending data to the client device is similar to the steps (1-1) to (1-4) and comprises the following steps (2-1) to (2-4).

And (2-1) when the server sends the data message to the client equipment, the server encrypts the plaintext data by using the session key 2 to obtain an encrypted message, and sends the encrypted message.

And (2-2) after the protective equipment receives the encrypted message sent by the server, the protective equipment decrypts the message by using the session key 2, and then the protective equipment performs content check on the decrypted plaintext data.

And (2-3) if the clear text data is checked and found to be free of threats, the protection device encrypts the checked data by using the session key 1 and then sends the encrypted data to the client device.

And (2-4) after the client device receives the encrypted message from the protective device, the client device decrypts the encrypted message by using the session key 1.

In the steps (1-1) to (1-4) and the steps (2-1) to (2-4), the algorithms adopted when the communication three parties (client equipment, protective equipment and server) carry out encryption and decryption are the same. For example, the algorithm used when the server encrypts and decrypts is the algorithm corresponding to the algorithm identifier in the original server hello packet. And the algorithm adopted by the protection equipment for encryption and decryption is the algorithm corresponding to the algorithm identifier in the original server hello message. And the algorithm adopted by the client equipment for encryption and decryption is the algorithm corresponding to the algorithm identifier in the target server hello message.

Fig. 11 is a schematic structural diagram of another protection device provided in the embodiment of the present application. Alternatively, the shield apparatus 700 having the structure shown in fig. 11 is the shield apparatus 33 in fig. 4. Alternatively, the shielding apparatus having the structure shown in fig. 11 is the shielding apparatus 400 in fig. 5. The guard device 700 comprises a transmitting unit 701, a processing unit 702 and a receiving unit 703.

A transmitting unit 701 configured to perform S501; a processing unit 702 for executing S502; a receiving unit 703 for executing S506 and S511; if the original encrypted message is from the client device, the processing unit 702 is further configured to execute S507, and the sending unit 701 is further configured to execute S508; if the original encrypted message is from the server, the processing unit 702 is further configured to execute S512, and the sending unit 701 is further configured to execute S513.

In some embodiments, the receiving unit 703 is further configured to perform S5011; a processing unit 702 further configured to execute S5012; the transmitting unit 701 is further configured to perform S5013.

In some embodiments, the receiving unit 703 is further configured to perform S5016; a processing unit 702 further configured to execute S5017; the transmitting unit 701 is further configured to execute S5018.

In some embodiments, the processing unit 702 is further configured to replace the server signature in the original server key exchange message with a man-in-the-middle signature.

In some embodiments, the processing unit 702 is configured to generate a first pre-master key using the man-in-the-middle DH parameter and the client DH parameter; generating a first session key by using the first pre-master key, the client random number and the server random number; generating a second pre-master secret key by using the intermediate DH parameter and the server DH parameter; and generating a second session key by using the second pre-master key, the client random number and the server random number.

In some embodiments, the receiving unit 703 is further configured to execute S522; a processing unit 702 further configured to execute S523; the transmitting unit 701 is further configured to execute S524.

In some embodiments, the processing unit 702 is configured to perform S507 'and S512'. A sending unit 701 configured to perform S508 'and S513'.

In some embodiments, the receiving unit 703 is further configured to perform S532; a processing unit 702 further configured to execute S533; the sending unit 701 is further configured to execute S534.

The embodiment of the apparatus depicted in fig. 11 is only schematic, for example, the division of a unit is only a logical functional division, and there may be other optional divisions when the actual implementation is performed, for example, multiple units or components may be optionally combined or optionally integrated into another system, or some features may be optionally omitted, or not executed. The functional units in the embodiments of the present application are optionally integrated into one processing unit, or alternatively, each unit exists separately and physically, or alternatively, two or more units are integrated into one unit. The above-mentioned units in fig. 11 are optionally implemented in the form of hardware, or alternatively implemented in the form of software functional units. For example, when implemented in software, the receiving unit 703, the processing unit 702, and the sending unit 701 may be optionally implemented by software functional modules generated after the CPU in fig. 5 reads the program code 410 stored in the memory 403. In fig. 11, the above units may be optionally implemented by different hardware in the protection device, for example, the receiving unit 703 and the sending unit 701 are implemented by the network interface 404 in fig. 5, the processing unit is implemented by the processor 401 in fig. 5, or implemented by a Programmable device such as a Field-Programmable Gate Array (FPGA), or a coprocessor. Obviously, the above functional modules may also be implemented by combining software and hardware, for example, the receiving unit 703 and the sending unit 701 are implemented by hardware programmable devices, and the processing unit 702 is a software functional module generated after the CPU reads the program code 410 stored in the memory 403.

Those of ordinary skill in the art will appreciate that the various method steps and elements described in connection with the embodiments disclosed herein can be implemented as electronic hardware, computer software, or combinations of both, and that the steps and elements of the various embodiments have been described above generally in terms of their functionality in order to clearly illustrate the interchangeability of hardware and software. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the technical solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It can be clearly understood by those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

The terms "first," "second," and the like, in this application are used for distinguishing between similar items and items that have substantially the same function or similar functionality, and it is to be understood that "first" and "second" do not have a logical or temporal dependency or limitation on the number or order of execution. For example, the first session key may be referred to as the second session key, and similarly, the second session key may be referred to as the first session key, without departing from the scope of the various examples. The first session key and the second session key may both be session keys, and in some cases may be separate and distinct session keys.

The term "at least one" in this application means one or more.

In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer program instructions. The procedures or functions according to the embodiments of the present application are wholly or partially generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device.

The computer program instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another computer readable storage medium, for example, the computer program instructions may be transmitted from one website site, computer, server, or data center to another website site, computer, server, or data center by wire or wirelessly. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that includes one or more available media. The storage medium may include a variety of media that may store program code, such as a U-disk, a removable disk, a read-only memory (ROM), a Random Access Memory (RAM), a magnetic or optical disk, and so forth.

The above embodiments are only used to illustrate the technical solutions of the present application, and not to limit the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; and the modifications or the substitutions do not make the essence of the corresponding technical solutions depart from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A method for detecting encrypted messages, the method comprising:

the method comprises the steps that a protective device sends middle person DH parameters to a client device and a server respectively, the protective device is deployed between the client device and the server, and the middle person DH parameters are DH parameters generated by the protective device;

the protective equipment generates a first session key according to the DH parameter of the man-in-the-middle and the DH parameter of the client, wherein the DH parameter of the client is the DH parameter generated by the client equipment;

the protective device generates a second session key according to the man-in-the-middle DH parameter and a server DH parameter, wherein the server DH parameter is the DH parameter generated by the server;

the protection equipment receives an original encrypted message;

if the original encrypted message comes from the client device, the protection device decrypts the original encrypted message by using the first session key, detects decrypted plaintext data, encrypts the detected data by using the second session key to obtain a target encrypted message, and sends the target encrypted message to the server; or

And if the original encrypted message comes from the server, the protection device decrypts the original encrypted message by using the second session key, detects the decrypted plaintext data, encrypts the detected data by using the first session key to obtain a target encrypted message, and sends the target encrypted message to the client device.

2. The method of claim 1, wherein the guard device sends the man-in-the-middle DH parameters to the client device and the server, respectively, comprising:

the protection equipment receives an original client key exchange message from the client equipment; the protection device replaces the client DH parameters in the original client key exchange message with the man-in-the-middle DH parameters, so that a target client key exchange message is obtained; the protective equipment sends the target client key exchange message to the server;

the protection equipment receives an original server key exchange message from the server; the protection equipment replaces the server DH parameter in the original server key exchange message with the man-in-the-middle DH parameter so as to obtain a target server key exchange message; and the protective equipment sends the target server key exchange message to the client equipment.

3. The method of claim 2, wherein before the guard device obtains the target server key exchange packet, the method further comprises:

and the protecting equipment replaces the server signature in the original server key exchange message with a man-in-the-middle signature, wherein the man-in-the-middle signature is obtained by using a private key of the protecting equipment to sign the DH parameter of the man-in-the-middle.

4. The method of claim 1, wherein generating, by the guard device, a first session key according to the man-in-the-middle DH parameter and a client DH parameter comprises:

the protection device generates a first pre-master secret key by using the man-in-the-middle DH parameter and the client DH parameter;

the protection device generates the first session key by using the first pre-master key, a client random number and a server random number, wherein the client random number is a random number generated by the client device, and the server random number is a random number generated by the server;

the protecting device generates a second session key by using the man-in-the-middle DH parameter and the server DH parameter, including:

the protective equipment generates a second pre-master secret key by using the man-in-the-middle DH parameter and the server DH parameter;

the protection device generates the second session key using the second premaster secret key, the client random number and the server random number.

5. The method of claim 4,

the client random number is extracted by the protection device from an original client hello message, and the server random number is extracted by the protection device from an original server hello message.

6. The method of claim 1, wherein before the guard device sends the intermediary diffie-hellman DH parameters to the client device and the server, respectively, the method further comprises:

the guard device receiving an original client hello message from the client device, the original client hello message including an algorithm list;

the protection device deletes the identifier of the first algorithm in the algorithm list from the original client hello message so as to obtain a target client hello message, wherein the first algorithm is an algorithm which is not supported by the protection device;

and the protection equipment sends the target client hello message to the server.

7. The method of claim 6, wherein the defending device decrypting the original encrypted message using the first session key comprises:

the protection device decrypts the original encrypted message by using the first session key through a second algorithm, wherein the second algorithm is an algorithm corresponding to the algorithm identifier remaining after the identifier of the first algorithm is deleted from the algorithm list;

the encrypting the detected data by using the second session key to obtain the target encrypted message includes:

encrypting the detected data by using the second session key through the second algorithm to obtain a target encryption message;

the decrypting, by the protection device, the original encrypted packet using the second session key includes:

the protection device decrypts the original encrypted message by using the second session key through the second algorithm;

the encrypting the detected data by using the first session key to obtain the target encrypted message includes:

and encrypting the detected data by using the first session key through the second algorithm to obtain a target encrypted message.

8. The method of claim 1, wherein before the guard device sends the intermediary diffie-hellman DH parameters to the client device and the server, respectively, the method further comprises:

the protection equipment receives an original server hello message from the server;

the protection device replaces a server certificate in the original server hello message with a broker certificate so as to obtain a target server hello message, wherein the server certificate comprises a public key of the server, and the broker certificate comprises a public key of the protection device;

and the protection equipment sends the target server hello message to the client equipment.

9. The method of claim 1, wherein the guard device comprises a hardware accelerator configured to generate the middleman DH parameters, generate a session key, decrypt the original encrypted message, or encrypt the detected data;

if the hardware accelerator is configured to generate the session key, the protection device generates a first session key according to the man-in-the-middle DH parameter and the client DH parameter, including: the protection equipment inputs the DH parameter of the man-in-the-middle and the DH parameter of the client into the hardware accelerator and receives a first session key generated by the hardware accelerator; the protective device generates a second session key according to the man-in-the-middle DH parameter and the server DH parameter, including: the protection equipment inputs the man-in-the-middle DH parameters and the server DH parameters into the hardware accelerator and receives a second session key generated by the hardware accelerator;

if the hardware accelerator is configured to decrypt the original encrypted packet, the decrypting, by the protection device, the original encrypted packet using the first session key includes: the protection equipment inputs the first session key and the original encrypted message into the hardware accelerator and receives plaintext data decrypted by the hardware accelerator; the decrypting, by the protection device, the original encrypted packet using the second session key includes: the protection equipment inputs the second session key and the original encrypted message into the hardware accelerator, and receives plaintext data decrypted by the hardware accelerator;

if the hardware accelerator is configured to encrypt the detected data, the encrypting the detected data using the second session key includes: the protection equipment inputs the second session key and the detected data into the hardware accelerator, and receives a target encryption message encrypted by the hardware accelerator; the encrypting the detected data using the first session key includes: and the protection equipment inputs the first session key and the detected data into the hardware accelerator and receives a target encrypted message encrypted by the hardware accelerator.

10. A guard device, comprising a memory, a network interface, and at least one processor;

the memory is used for storing program codes;

the at least one processor, after reading the program code stored in the memory, is configured to:

the processor instructs the network interface to send an intermediate human Diffie-Hellman DH parameter to a client device and a server respectively, the protective device is deployed between the client device and the server, and the intermediate human DH parameter is a DH parameter generated by the protective device;

the processor generates a first session key according to the man-in-the-middle DH parameter and a client DH parameter, wherein the client DH parameter is a DH parameter generated by the client device;

the processor generates a second session key according to the man-in-the-middle DH parameter and a server DH parameter, wherein the server DH parameter is the DH parameter generated by the server;

the network interface is used for receiving an original encrypted message;

if the original encrypted message comes from the client device, the processor decrypts the original encrypted message by using the first session key, detects decrypted plaintext data, encrypts the detected data by using the second session key to obtain a target encrypted message, and instructs the network interface to send the target encrypted message to the server; or

If the original encrypted message comes from the server, the processor decrypts the original encrypted message by using the second session key, detects decrypted plaintext data, encrypts the detected data by using the first session key to obtain a target encrypted message, and instructs the network interface to send the target encrypted message to the client device.

11. The safeguard device according to claim 10, wherein the network interface is configured to receive an original client key exchange packet from the client device;

replacing the client DH parameter in the original client key exchange message by the intermediate DH parameter by the processor, so as to obtain a target client key exchange message;

the processor instructs the network interface to send the target client key exchange message to the server;

the network interface is used for receiving an original server key exchange message from the server;

the processor replaces the server DH parameter in the original server key exchange message with the man-in-the-middle DH parameter, so that a target server key exchange message is obtained; and instructing the network interface to send the target server key exchange message to the client equipment.

12. The safeguarding device of claim 11, wherein the processor is further configured to replace a server signature in the original server key exchange message with a man-in-the-middle signature, the man-in-the-middle signature being signed by the man-in-the-middle DH parameter using a private key of the safeguarding device.

13. The safeguarding device of claim 10, wherein the processor is configured to generate a first pre-master key using the man-in-the-middle DH parameters and the client DH parameters; generating the first session key by using the first premaster key, a client random number and a server random number, wherein the client random number is a random number generated by the client device, and the server random number is a random number generated by the server; generating a second pre-master key by using the man-in-the-middle DH parameter and the server DH parameter; generating the second session key using the second premaster key, the client random number, and the server random number.

14. Guard device according to claim 13,

the processor is configured to extract the client random number from an original client hello message received by the network interface, and extract the server random number from an original server hello message received by the network interface.

15. The protective apparatus of claim 10, wherein the network interface is configured to receive an original client hello message from the client device, the original client hello message comprising an algorithm list;

the processor deletes the identifier of the first algorithm in the algorithm list from the original client hello message so as to obtain a target client hello message, wherein the first algorithm is an algorithm which is not supported by the processor; and instructing the network interface to send the target client hello message to the server.

16. Guard means according to claim 15,

the processor is configured to decrypt, by using a second algorithm, the original encrypted packet using the first session key, where the second algorithm is an algorithm corresponding to an algorithm identifier remaining after the identifier of the first algorithm is deleted from the algorithm list; encrypting the detected data by using the second session key through the second algorithm to obtain a target encrypted message;

the processor is configured to decrypt, by using the second algorithm, the original encrypted packet using the second session key; and encrypting the detected data by using the first session key through the second algorithm to obtain a target encrypted message.

17. Guard device according to claim 10,

the network interface is also used for receiving an original server hello message from the server;

replacing a server certificate in the original server hello message with a broker certificate by the processor so as to obtain a target server hello message, wherein the server certificate comprises a public key of the server, and the broker certificate comprises a public key of the protective device; and instructing the network interface to send the target server hello message to the client device.

18. The protecting device according to claim 10, wherein the protecting device comprises a hardware accelerator configured to generate the man-in-the-middle DH parameter, generate a session key, decrypt the original encrypted packet, or encrypt the detected data;

if the hardware accelerator is used for generating the session key, the processor inputs the man-in-the-middle DH parameter and the client DH parameter into the hardware accelerator, and receives a first session key generated by the hardware accelerator; the processor inputs the man-in-the-middle DH parameter and the server DH parameter into the hardware accelerator, and receives a second session key generated by the hardware accelerator;

if the hardware accelerator is used for decrypting the original encrypted message, the processor inputs the first session key and the original encrypted message into the hardware accelerator and receives plaintext data decrypted by the hardware accelerator; the processor inputs the second session key and the original encrypted message into the hardware accelerator, and receives plaintext data obtained by decryption of the hardware accelerator;

if the hardware accelerator is used for encrypting the detected data, the processor inputs the second session key and the detected data into the hardware accelerator, and receives a target encryption message obtained by encrypting the hardware accelerator; and the processor inputs the first session key and the detected data into the hardware accelerator and receives a target encrypted message encrypted by the hardware accelerator.

19. A protective apparatus, characterized in that the protective apparatus comprises:

a sending unit, configured to send a middleman diffie-hellman DH parameter to a client device and a server, respectively, where the protective device is deployed between the client device and the server, and the middleman DH parameter is a DH parameter generated by the protective device;

a processing unit, configured to generate a first session key according to the man-in-the-middle DH parameter and a client DH parameter, where the client DH parameter is a DH parameter generated by the client device; generating a second session key according to the man-in-the-middle DH parameter and a server DH parameter, wherein the server DH parameter is the DH parameter generated by the server;

a receiving unit, configured to receive an original encrypted packet;

if the original encrypted message is from the client device, the processing unit is further configured to decrypt the original encrypted message using the first session key, detect decrypted plaintext data, and encrypt the detected data using the second session key to obtain a target encrypted message, and the sending unit is further configured to send the target encrypted message to the server; or

If the original encrypted message is from the server, the processing unit is further configured to decrypt the original encrypted message using the second session key, detect decrypted plaintext data, and encrypt the detected data using the first session key to obtain a target encrypted message, and the sending unit is further configured to send the target encrypted message to the client device.

20. The safeguard device according to claim 19, wherein the receiving unit is further configured to receive an original client key exchange packet from the client device; the processing unit is further configured to replace the client DH parameter in the original client key exchange message with the man-in-the-middle DH parameter, so as to obtain a target client key exchange message; the sending unit is further configured to send the target client key exchange packet to the server;

the receiving unit is further configured to receive an original server key exchange packet from the server; the processing unit is further configured to replace the server DH parameter in the original server key exchange message with the man-in-the-middle DH parameter, so as to obtain a target server key exchange message; the sending unit is further configured to send the target server key exchange packet to the client device.

21. The safeguard device of claim 20, wherein the processing unit is further configured to replace a server signature in the original server key exchange message with a man-in-the-middle signature, wherein the man-in-the-middle signature is obtained by signing the man-in-the-middle DH parameter using a private key of the safeguard device.

22. The safeguard device according to claim 19, wherein the processing unit is configured to generate a first pre-master key using the man-in-the-middle DH parameter and the client DH parameter; generating the first session key by using the first pre-master key, a client random number and a server random number, wherein the client random number is a random number generated by the client device, and the server random number is a random number generated by the server; generating a second pre-master key by using the man-in-the-middle DH parameter and the server DH parameter; generating the second session key using the second pre-master key, the client random number, and the server random number.

23. The safeguarding device of claim 19, wherein the receiving unit is further configured to receive an original client hello message from the client device, the original client hello message comprising an algorithm list;

the processing unit is further configured to delete the identifier of the first algorithm in the algorithm list from the original client hello message, so as to obtain a target client hello message, where the first algorithm is an algorithm that is not supported by the protection device;

the sending unit is further configured to send the target client hello message to the server.

24. The safeguard device according to claim 23, wherein the processing unit is configured to decrypt, by using a second algorithm, the original encrypted packet using the first session key, where the second algorithm is an algorithm corresponding to an algorithm identifier remaining after the identifier of the first algorithm is deleted from the algorithm list; encrypting the detected data by using the second session key through the second algorithm to obtain a target encryption message; decrypting the original encrypted message by using the second session key through the second algorithm; and encrypting the detected data by using the first session key through the second algorithm to obtain a target encrypted message.

25. The safeguarding device of claim 19, wherein the receiving unit is further configured to receive an original server hello message from the server;

the processing unit is further configured to replace a server certificate in the original server hello message with a broker certificate, so as to obtain a target server hello message, where the server certificate includes a public key of the server, and the broker certificate includes a public key of the protection device;

the sending unit is further configured to send the target server hello message to the client device.

26. A computer-readable storage medium having stored therein at least one instruction which, when executed on a computer, causes the computer to perform the method of detecting an encrypted message according to any one of claims 1 to 9.