Flow detection methods, devices and electronic equipment

Abstract

This invention provides a traffic detection method, apparatus, and electronic device, comprising: receiving HTTPS mirror traffic; an SSL resolver resolving the original packets and original handshake information between the client and server from the HTTPS mirror traffic; the SSL resolver sending the original packets to a proxy module through a simulated client and a simulated server according to the traffic direction of the HTTPS mirror traffic, and sending the original handshake information to the proxy module through a simulated client; the proxy module establishing a first SSL connection between the proxy module and the simulated client, and establishing a second SSL connection between the proxy module and the simulated server based on the original SSL handshake information; wherein the master key of the first SSL connection and the second SSL connection is the same; and the proxy module performing a security detection operation after decrypting the original packets based on the master key. This method can achieve secure detection of HTTPS traffic and helps reduce the operating load of the SSL resolver.

Description

Technical Field

[0001] This invention relates to the field of flow monitoring technology, and in particular to a flow detection method, device, and electronic device. Background Technology

[0002] Currently, traffic detection technology for the Hypertext Transfer Protocol (HTTP) is generally obtained through a bypass web application early warning system based on the Nginx proxy module. However, in this system, the Nginx proxy module cannot successfully perform an SSL handshake with the simulated client and the simulated server.

[0003] Therefore, the above-mentioned technologies can only achieve traffic detection for Hypertext Transfer Protocol (HTTP) traffic detection, but cannot solve the problem of traffic detection for Hypertext Transfer Security Protocol (HTTP). Summary of the Invention

[0004] The purpose of this invention is to provide a traffic detection method, apparatus, and electronic device to alleviate the technical problem that the existing technology can only realize HTTP traffic detection and cannot solve the problem of HTTPS traffic detection, so as to realize HTTPS traffic detection.

[0005] In a first aspect, embodiments of the present invention provide a traffic detection method, comprising: when the received mirrored traffic is HTTPS mirrored traffic, an SSL parser parses the original SSL message and original SSL handshake information transmitted between the client and the server from the HTTPS mirrored traffic; the SSL parser sends the original SSL message to an Nginx proxy module through a simulated client and a simulated server according to the traffic direction of the HTTPS mirrored traffic, and sends the original SSL handshake information to the Nginx proxy module through the simulated client; the Nginx proxy module establishes a first SSL connection between the Nginx proxy module and the simulated client based on the original SSL handshake information, and establishes a second SSL connection between the Nginx proxy module and the simulated server; wherein the master key used by the first SSL connection and the second SSL connection is the same; the Nginx proxy module performs a security detection operation after decrypting the original SSL message based on the master key.

[0006] In a preferred embodiment of the present invention, the SSL parser parses the original SSL packets and original SSL handshake information transmitted between the client and the server from the aforementioned HTTPS mirror traffic, including: for the mirror traffic of the first HTTPS traffic sent by the client to the server in the aforementioned HTTPS mirror traffic, the SSL parser parses the original SSL packets and original SSL handshake information of the first HTTPS traffic from the aforementioned HTTPS mirror traffic; the SSL parser sends the original SSL packets to the Nginx proxy module through a simulated client and a simulated server according to the traffic direction of the aforementioned HTTPS mirror traffic, including: the SSL parser sends the original SSL packets of the first HTTPS traffic to the Nginx proxy module through a simulated client.

[0007] In a preferred embodiment of the present invention, the SSL parser parses the original SSL packets and original SSL handshake information transmitted between the client and the server from the HTTPS mirror traffic, including: for the mirror traffic of the second HTTPS traffic sent by the server to the client in the HTTPS mirror traffic, the SSL parser parses the original SSL packets and original SSL handshake information of the second HTTPS traffic from the HTTPS mirror traffic; the SSL parser sends the original SSL packets to the Nginx proxy module through the simulated client and simulated server according to the traffic direction of the HTTPS mirror traffic, including: the SSL parser sends the original SSL packets of the second HTTPS traffic to the Nginx proxy module through the simulated server.

[0008] In a preferred embodiment of the present invention, the Nginx proxy module establishes a first SSL connection between itself and the simulated client based on the original SSL handshake information, including: the Nginx proxy module receiving the original SSL handshake information sent by the simulated client, and performing a random number exchange with the simulated client based on the server-side random number in the original SSL handshake information; after the random number exchange with the simulated client is completed, the Nginx proxy module uses the pre-master key in the original SSL handshake information and the simulated client to jointly generate the master key, thereby completing the establishment of the first SSL connection between the Nginx proxy module and the simulated server.

[0009] In a preferred embodiment of the present invention, the Nginx proxy module establishes a second SSL connection between itself and the simulated server based on the original SSL handshake information, including: the Nginx proxy module performing a random number exchange with the simulated server based on the client random number in the original SSL handshake information; after the random number exchange with the simulated server is completed, the Nginx proxy module uses the pre-master key in the original SSL handshake information and the simulated server to jointly generate the master key, thereby completing the establishment of the second SSL connection between the Nginx proxy module and the simulated server.

[0010] In a preferred embodiment of the present invention, during the establishment of the first SSL connection, the original SSL handshake information sent by the simulated client is appended before the first SSL handshake message sent by the simulated client to the Nginx proxy module.

[0011] During the establishment of the second SSL connection, the client random number in the original SSL handshake information is carried in the first SSL handshake message sent by the Nginx proxy module to the simulated server.

[0012] In a preferred embodiment of the present invention, the Nginx proxy module decrypts the original SSL message based on the master key, including: the Nginx proxy module decrypts the encrypted data in the original SSL message using a preset hardware acceleration device based on the master key to obtain the plaintext of the original SSL message.

[0013] In a preferred embodiment of the present invention, the SSL resolver, the simulated client, and the simulated server are deployed in a bypass process; the SSL resolver is connected to the simulated client and the simulated server, respectively.

[0014] Secondly, embodiments of the present invention also provide a traffic detection device, comprising: an SSL parser, configured to, when receiving HTTPS mirror traffic, parse the original SSL messages and original SSL handshake information transmitted between the client and the server from the HTTPS mirror traffic, and send the original SSL messages to an Nginx proxy module through a simulated client and a simulated server according to the traffic direction of the HTTPS mirror traffic, and send the original SSL handshake information to the Nginx proxy module through the simulated client; and a simulated client, configured to receive the original SSL messages and original SSL handshake information sent by the SSL parser according to the traffic direction of the HTTPS mirror traffic. The SSL handshake information is sent to the Nginx proxy module; the simulated server receives the original SSL message sent by the SSL resolver in the direction of the HTTPS mirrored traffic and sends it to the Nginx proxy module; the Nginx proxy module establishes a first SSL connection between itself and the simulated client based on the original SSL handshake information, and establishes a second SSL connection between itself and the simulated server; wherein the master key used in the first SSL connection and the second SSL connection is the same; the Nginx proxy module also performs security checks after decrypting the original SSL message based on the master key.

[0015] Thirdly, embodiments of the present invention also provide an electronic device, which includes a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the traffic detection method.

[0016] The embodiments of the present invention have the following beneficial technical effects:

[0017] This invention provides a traffic detection method, apparatus, and electronic device, comprising: when the received mirrored traffic is HTTPS mirrored traffic, an SSL parser parses the original SSL message and original SSL handshake information transmitted between the client and the server from the HTTPS mirrored traffic; the SSL parser sends the original SSL message to an Nginx proxy module through a simulated client and a simulated server according to the traffic direction of the HTTPS mirrored traffic, and sends the original SSL handshake information to the Nginx proxy module through the simulated client; the Nginx proxy module establishes a first SSL connection between the Nginx proxy module and the simulated client based on the original SSL handshake information, and establishes a second SSL connection between the Nginx proxy module and the simulated server; wherein the first SSL connection and the second SSL connection use the same master key; the Nginx proxy module decrypts the original SSL message based on the master key and then performs a security detection operation. This method establishes SSL connections with the Nginx proxy module by simulating both the client and the server, and decrypts the data using the same master key. This not only achieves secure detection of HTTPS traffic, but also significantly reduces the workload of the SSL parser by having the Nginx proxy module perform the decryption of SSL messages, compared to performing the parsing and decryption of HTTPS traffic through the SSL parser. This effectively solves the performance bottleneck of the SSL parser and thus optimizes the overall performance of the system. Attached Figure Description

[0018] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a flow detection method provided in an embodiment of the present invention;

[0020] Figure 2 This is a schematic diagram of the structure of a flow detection device provided in an embodiment of the present invention;

[0021] Figure 3 A flowchart illustrating another flow detection method provided in an embodiment of the present invention;

[0022] Figure 4 This is a schematic diagram illustrating the original SSL handshake information passed from a simulated client to an Nginx proxy module, provided as an embodiment of the present invention.

[0023] Figure 5 A schematic diagram illustrating the establishment of an SSL connection between a simulated client and an Nginx proxy module, provided as an embodiment of the present invention;

[0024] Figure 6 This is a schematic diagram illustrating how an Nginx proxy module establishes an SSL connection with a simulated server, as provided in an embodiment of the present invention.

[0025] Figure 7 A schematic diagram of the structure of a traffic detection device for an extended QAT hardware acceleration card provided in an embodiment of the present invention;

[0026] Figure 8 This is a schematic diagram of another flow detection device provided in an embodiment of the present invention;

[0027] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention.

[0028] Icons: 31-SSL resolver; 32-Simulated client; 33-Nginx proxy module; 34-Simulated server; 41-Memory; 42-Processor; 43-Bus; 44-Communication interface. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0030] First, some of the terms used in the embodiments of this application will be explained to facilitate understanding by those skilled in the art.

[0031] HTTPS (Hypertext Transfer Protocol Secure) is an HTTP channel designed for security. Building upon HTTP, it ensures security during transmission through encryption and authentication. HTTPS adds SSL to HTTP; the security foundation of HTTPS is SSL, and therefore the details of encryption are handled by SSL. HTTPS uses a different default port than HTTP and includes an encryption / authentication layer (between HTTP and TCP).

[0032] SSL (Secure Sockets Layer) and its successor Transport Layer Security (TLS) are security protocols that provide security and data integrity for network communications.

[0033] TLS: Transport Layer Security (TLS) is used to provide confidentiality and data integrity between two communicating applications. This protocol consists of two layers: the TLS Record protocol and the TLS Handshake protocol. The lower layer, the TLS Record protocol, sits on top of a reliable transport protocol (such as TCP) and is independent of the specific application; therefore, TLS is generally classified as a transport layer security protocol.

[0034] HTTP: Hypertext Transfer Protocol (HTTP) is a simple request-response protocol that typically runs on top of TCP. It specifies what messages a client might send to a server and what responses it might receive.

[0035] RSA: Public-key cryptography is a cryptosystem that uses different encryption and decryption keys, and "it is computationally infeasible to derive the decryption key from the known encryption key."

[0036] DH: (Diffie-Hellman) Key exchange protocol / algorithm.

[0037] Nginx is a high-performance HTTP and Nginx proxy module that also provides IMAP / POP3 / SMTP services.

[0038] A message is a data unit exchanged and transmitted in a network; it is a block of data that a station sends at one time. A message contains complete data information to be sent, and its length varies greatly, being unlimited and variable.

[0039] DPDK: Data Plane Development Kit (DPDK) is developed by 6WIND, Intel, and other companies. It mainly runs on Linux systems and is a collection of function libraries and drivers for fast packet processing. It can greatly improve data processing performance and throughput, and improve the efficiency of data plane applications.

[0040] Plaintext refers to unencrypted text (or strings) that are generally understandable to the average person; it is a cryptographic term. In communication systems, it can be a bitstream, such as text, bitmaps, digitized voice, or digitized video images.

[0041] Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol.

[0042] However, currently, when simulating clients and servers, the original packets are typically sent to the detection server for parsing. The random numbers in the packets returned by the detection server to the simulated clients and servers are inevitably different from those in the original packets. Therefore, the detection server cannot successfully and securely interface with the simulated clients and servers, and cannot support traffic detection for the Hypertext Transfer Security Protocol (HTTP).

[0043] Based on this, embodiments of the present invention provide a traffic detection method, apparatus, and electronic device. This method parses HTTPS traffic using an SSL resolver and converts it into raw SSL message data. Then, using an Nginx proxy module, it establishes SSL connections with a simulated client and a simulated server using the same handshake information as the original SSL connection, respectively, employing the same master key. The master key is then used to decrypt the SSL message data to obtain HTTP plaintext, thus achieving secure detection of the Hypertext Transfer Protocol (HTTP). For ease of understanding, a traffic detection method is first introduced.

[0044] Example 1

[0045] In this embodiment, Figure 1 This is a flowchart illustrating a traffic detection method provided in an embodiment of the present invention. The method can be applied to a traffic detection device, which may include an SSL resolver, a simulated client, and a simulated server deployed in a bypass process. Figure 1 As seen, the method includes:

[0046] Step S101: When the received mirror traffic is HTTPS mirror traffic, the SSL parser parses the original SSL messages and original SSL handshake information transmitted between the client and the server from the above HTTPS mirror traffic.

[0047] In some examples, the aforementioned HTTPS mirror traffic is sent from the Data Plane (DPDK) to the aforementioned SSL resolver, and the traffic type of the mirror traffic includes HTTPS mirror traffic and HTTP mirror traffic.

[0048] In some examples, prior to step S101 above, the method further includes determining whether the traffic type is HTTPS mirror traffic.

[0049] The data plane can be the data plane of the traffic detection device, or it can collect mirrored traffic from other links. For example, it can obtain the real traffic of the client requesting to access the server and / or the real traffic of the server responding to the client through the forwarding device, and copy the obtained real traffic to obtain mirrored traffic, which is received by the data plane of the traffic detection device.

[0050] The aforementioned raw SSL handshake information may include: client random number, server random number, key set, compression algorithm, and pre-master key.

[0051] Step S102: The SSL parser sends the original SSL message to the Nginx proxy module through the simulated client and simulated server according to the traffic direction of the HTTPS mirror traffic, and sends the original SSL handshake information to the Nginx proxy module through the simulated client.

[0052] The traffic direction of the aforementioned HTTPS mirror traffic can be divided into two categories: request direction and response direction. The request direction indicates that the original traffic of the HTTPS mirror traffic is HTTPS traffic sent from the client to the server, while the response direction indicates that the original traffic of the HTTPS mirror traffic is HTTPS traffic sent from the server to the client.

[0053] Step S103: Based on the original SSL handshake information, the Nginx proxy module establishes a first SSL connection between itself and the simulated client, and establishes a second SSL connection between itself and the simulated server; wherein the master key used in the first SSL connection and the second SSL connection is the same.

[0054] This application establishes two SSL connections between the Nginx proxy module and the client and server using the same master key. This method ensures the transparency and consistency of communication, while simplifying key management and improving proxy efficiency.

[0055] Step S104: The Nginx proxy module decrypts the original SSL message based on the master key and then performs a security check.

[0056] For ease of understanding, Figure 2 This is a schematic diagram of a flow detection device provided in an embodiment of the present invention.

[0057] Depend on Figure 2 As can be seen, the data plane is responsible for receiving mirrored traffic; the bypass process is used to process the above-mentioned mirrored traffic, which includes: HTTP parser, SSL parser, emulated client, and emulated server.

[0058] An SSL parser can be used to classify SSL or TLS protocol record messages, placing request-oriented messages into the simulated client's send queue and response-oriented messages into the simulated server's send queue. Furthermore, the original SSL handshake information is appended to the beginning of the first TCP datagram sent by the simulated client.

[0059] The HTTP parser is used to classify HTTP protocol messages, placing HTTP request messages into the sending queue of the simulated client and HTTP response messages into the sending queue of the simulated server.

[0060] The simulated client is used to send packets in the sending queue to the Nginx proxy module (i.e., Figure 2 (Nginx service in the middle).

[0061] The simulated server is used to send messages in the sending queue to the Nginx proxy module.

[0062] The Nginx proxy module is used to receive messages from simulated clients and simulated servers. If it is an HTTP message, it is inspected directly. If it is an HTTPS message, it is decrypted into HTTP plaintext before inspection.

[0063] This invention provides a traffic detection method, comprising: when the received mirrored traffic is HTTPS mirrored traffic, an SSL parser parses the original SSL message and original SSL handshake information transmitted between the client and the server from the HTTPS mirrored traffic; the SSL parser sends the original SSL message and the original SSL handshake information to an Nginx proxy module through a simulated client and a simulated server according to the traffic direction of the HTTPS mirrored traffic, and sends the original SSL handshake information to the Nginx proxy module through the simulated client; the Nginx proxy module establishes a first SSL connection between the Nginx proxy module and the simulated client based on the original SSL handshake information, and establishes a second SSL connection between the Nginx proxy module and the simulated server; wherein the first SSL connection and the second SSL connection use the same master key; the Nginx proxy module decrypts the original SSL message based on the master key and then performs a security detection operation. This method establishes a bidirectional SSL connection with the Nginx proxy module by introducing simulated clients and servers and using the same master key for decryption. This not only achieves secure detection of HTTPS traffic, but also reduces the workload of the SSL parser and optimizes system performance by centralizing the SSL handshake and message decryption in the Nginx proxy module.

[0064] Example 2

[0065] Based on the above embodiments, Figure 3 This is a flowchart illustrating another flow detection method provided in an embodiment of the present invention.

[0066] Depend on Figure 3 As seen, the method includes:

[0067] Step S201: When the received mirrored traffic is HTTPS mirrored traffic, for the mirrored traffic of the first HTTPS traffic sent by the client to the server in the above HTTPS mirrored traffic, the above SSL parser parses the original SSL message and the original SSL handshake information of the first HTTPS traffic from the above HTTPS mirrored traffic.

[0068] In some embodiments of this application, step S201 further includes: for the mirrored traffic of the second HTTPS traffic sent by the server to the client in the above-mentioned HTTPS mirrored traffic, the above-mentioned SSL parser parses the original SSL message and the original SSL handshake information of the second HTTPS traffic from the above-mentioned HTTPS mirrored traffic.

[0069] Step S202: The SSL parser sends the original SSL packet of the first HTTPS traffic to the Nginx proxy module through a simulated client, and sends the original SSL packet of the second HTTPS traffic to the Nginx proxy module through a simulated server.

[0070] Step S203: The SSL parser sends the original SSL handshake information to the Nginx proxy module through a simulated client.

[0071] The present invention has the following beneficial technical effects: the method achieves accurate SSL message parsing and decryption for the first HTTPS mirror traffic from the client to the server and the second HTTPS mirror traffic from the server to the second client through the collaborative work of the SSL parser and the Nginx proxy module. By establishing a two-way SSL connection, the security and consistency of the decryption process are ensured, thereby improving the accuracy and efficiency of security detection, while optimizing the SSL processing flow and reducing the system load.

[0072] Step S204: Based on the original SSL handshake information, the Nginx proxy module establishes a first SSL connection between itself and the simulated client, and establishes a second SSL connection between itself and the simulated server; wherein the master key used in the first SSL connection and the second SSL connection is the same.

[0073] The aforementioned SSL resolver, the aforementioned simulated client, and the aforementioned simulated server are deployed in a bypass process; the aforementioned SSL resolver is connected to the aforementioned simulated client and the aforementioned simulated server, respectively.

[0074] In some examples, the Nginx proxy module establishes a first SSL connection between itself and the simulated client based on the original SSL handshake information. This includes: the Nginx proxy module receiving the original SSL handshake information sent by the simulated client and performing a random number exchange with the simulated client based on the server-side random number in the original SSL handshake information; after completing the random number exchange with the simulated client, the Nginx proxy module uses the pre-master key in the original SSL handshake information and the simulated client to jointly generate the master key, thereby completing the establishment of the first SSL connection between the Nginx proxy module and the simulated server.

[0075] Furthermore, based on the original SSL handshake information, the Nginx proxy module establishes a second SSL connection between itself and the simulated server, including: the Nginx proxy module performs a random number exchange with the simulated server based on the client random number in the original SSL handshake information; after the random number exchange with the simulated server is completed, the Nginx proxy module uses the pre-master key in the original SSL handshake information and the simulated server to jointly generate the master key, thereby completing the establishment of the second SSL connection between the Nginx proxy module and the simulated server.

[0076] Specifically, during the establishment of the first SSL connection, the original SSL handshake information sent by the simulated client is appended before the first SSL handshake message sent by the simulated client to the Nginx proxy module; during the establishment of the second SSL connection, the client random number in the original SSL handshake information is carried in the first SSL handshake message sent by the Nginx proxy module to the simulated server.

[0077] Here, the method uses the Nginx proxy module to exchange random numbers with the simulated client and server respectively and jointly generate a master key, ensuring the security and consistency of the first SSL connection and the second SSL connection, improving the accuracy and security of HTTPS mirror traffic decryption, while optimizing the SSL handshake process, reducing system load, and enhancing the overall system performance and reliability.

[0078] Step S205: The Nginx proxy module above decrypts the original SSL message based on the master key and then performs a security check operation.

[0079] In some examples, the Nginx proxy module decrypts the original SSL message using the master key via a pre-defined hardware acceleration device to obtain the plaintext of the original SSL message.

[0080] This invention provides a traffic detection method, comprising: when the received mirrored traffic is HTTPS mirrored traffic, for the mirrored traffic of the first HTTPS traffic sent by the client to the server in the HTTPS mirrored traffic, the SSL parser parses the original SSL message and original SSL handshake information of the first HTTPS traffic from the HTTPS mirrored traffic; for the mirrored traffic of the second HTTPS traffic sent by the server to the client in the HTTPS mirrored traffic, the SSL parser parses the original SSL message of the second HTTPS traffic from the HTTPS mirrored traffic, and the SSL parser transmits the original SSL message of the first HTTPS traffic through... A simulated client sends the original SSL packets of the second HTTPS traffic to the Nginx proxy module via a simulated server, and also sends the original SSL handshake information to the Nginx proxy module via the simulated client. Based on the original SSL handshake information, the Nginx proxy module establishes a first SSL connection between itself and the simulated client, and a second SSL connection between itself and the simulated server. The master key used in both the first and second SSL connections is the same. The Nginx proxy module decrypts the original SSL packets using the master key and then performs security checks. This method, through the collaborative work of the SSL parser and the Nginx proxy module, achieves accurate SSL packet parsing and decryption for client-to-server HTTPS mirrored traffic. The establishment of bidirectional SSL connections ensures the security and consistency of the decryption process, thereby improving the accuracy and efficiency of security checks, optimizing the SSL processing flow, and reducing system load.

[0081] Example 3

[0082] To facilitate understanding, this embodiment, based on embodiment 2, will further detail the steps of the flow detection method in specific operation.

[0083] First, in the bypass process, it is determined that the mirrored traffic received by the data plane is HTTPS traffic. If so, the HTTPS traffic packets are sent to the SSL resolver for processing. The SSL resolver places request-direction packets in the HTTPS mirrored traffic into the simulated client's sending queue and response-direction packets into the simulated server's sending queue. This divides the HTTPS mirrored traffic into two categories: mirrored traffic of the first HTTPS traffic sent from the client to the server and mirrored traffic of the second HTTPS traffic sent from the server to the client. The SSL resolver then parses the original SSL packets carried in the traffic data packets to obtain the original SSL handshake information. This original SSL handshake information includes: client random number, server random number, key set, compression algorithm, and pre-master key.

[0084] Then, the SSL parser appends the original SSL handshake information from the simulated client to the first SSL handshake message sent by the simulated client to the Nginx proxy module, thus obtaining the SSL handshake message to be sent by the simulated client to the Nginx proxy module.

[0085] The simulated client sends the aforementioned SSL handshake message to the Nginx proxy module, initiating an SSL handshake with the Nginx proxy module. After parsing the additional original SSL handshake information from the simulated client's SSL handshake message, the Nginx proxy module, in its reply to the simulated client's SSL handshake message, uses the server-side random number and pre-master key to establish the first SSL connection between the Nginx proxy module and the simulated client. During this process, the Nginx proxy module calculates the same master key as the one used in the original SSL connection, thereby decrypting subsequent SSL encrypted data to obtain the plaintext of the HTTP request and performing security checks on the plaintext HTTP request.

[0086] Furthermore, after the HTTP request detection is completed, the Nginx proxy module establishes an SSL connection with the simulated server. During this process, the Nginx proxy module uses the original SSL handshake information to establish a second SSL connection between the Nginx proxy module and the simulated server. In this process, the Nginx proxy module also calculates the same master key as the original SSL connection, and then decrypts the subsequent SSL encrypted data to obtain the plaintext of the HTTP response, and performs security checks on the plaintext of the HTTP request.

[0087] For ease of understanding, Figure 4 This is a schematic diagram illustrating the original SSL handshake information passed from a simulated client to an Nginx proxy module, provided as an embodiment of the present invention.

[0088] Depend on Figure 4 As shown, the simulated client needs to pass the original SSL handshake information to the Nginx proxy module, so that the Nginx proxy module uses the same handshake information to perform an SSL handshake with the simulated client and the simulated server, calculates the same master key, and then decrypts and performs security checks on the HTTPS traffic transmitted between the client and the server.

[0089] The original SSL handshake information includes: client random number, session ID, server random number, cipher suite, and pre-master key. The session ID is used to uniquely identify the session.

[0090] The raw SSL handshake information may also include compression algorithms, which are used to reduce the size of message data for more efficient message transmission.

[0091] The above information from the original SSL handshake can be assembled in TLV format and sent as the TCP payload along with the first SSL handshake message that the simulated client wants to send to the Nginx proxy module.

[0092] TLV (Type-Length-Value) is a simple and flexible format for encoding data. It represents each data item as three components: Type, which identifies the type of data item and is typically a fixed-length field, such as one or two bytes; Length, which specifies the length of the subsequent value field and is also a fixed-length field indicating the size of the actual data portion; and Value, which contains the actual data content, with its length specified by the preceding length field.

[0093] Furthermore, during the SSL handshake between the Nginx proxy module and the simulated client, the simulated client acts as the client and the Nginx proxy module acts as the server.

[0094] During the SSL handshake process between the Nginx proxy module and the simulated server, the Nginx proxy module acts as the client and the simulated server acts as the server.

[0095] The following messages are involved in both the SSL handshake process between the Nginx proxy module and the simulated client, and the SSL handshake process between the Nginx proxy module and the simulated server:

[0096] The ClientHello message is the first message in a TLS (Transport Layer Security) or SSL (Secure Sockets Layer) handshake protocol, initiated by the client.

[0097] The ServerHello message is the second message in the TLS or SSL handshake protocol, sent by the server after receiving the ClientHello message from the client.

[0098] The ClientKeyExchange message is an important message in the TLS or SSL handshake protocol. It is sent by the client after receiving messages such as ServerHello, Certificate, and Server Key Exchange from the server.

[0099] Furthermore, Figure 5 This is a schematic diagram illustrating the establishment of an SSL connection between a simulated client and an Nginx proxy module, provided as an embodiment of the present invention. Figure 5 As shown, the simulated client sends the original SSL handshake information and the original ClientHello message to the Nginx proxy module (i.e., Nginx). The Nginx proxy module parses the original SSL handshake information and uses the server-side random number, session ID, cipher suite, and compression algorithm to construct a ServerHello message. The Nginx proxy module constructs a Certificate message based on the pre-imported site certificate. The Nginx proxy module constructs a ServerHelloDone message and replies to the simulated client with a ServerHello+Certificate+ServerHelloDone message. The simulated client sends the original ClientKeyExchange message, ChangeCipherSpec message, and Finished message to the Nginx proxy module. Since the key information of the SSL handshake is exactly the same as that of the original SSL connection, the Nginx proxy module calculates the same master key, can decrypt the received Finished message normally, and constructs a ChangeSipherSpec message and a Finished message to send to the simulated client, completing the SSL handshake.

[0100] The ClientHello message is the first message in the TLS or SSL handshake protocol, initiated by the simulated client; the ServerHello message is the second message in the TLS or SSL handshake protocol, sent by the Nginx proxy module after receiving the ClientHello message from the simulated client; the ServerHelloDone message is a short message in the TLS or SSL handshake protocol, sent by the Nginx proxy module after sending the ServerHello, Certificate, and Server Key; the Finished message is an important message in the TLS or SSL handshake protocol, used to confirm the successful completion of the handshake process and verify the integrity and authenticity of all previously exchanged data.

[0101] For ease of understanding, Figure 6 This is a schematic diagram illustrating how an Nginx proxy module establishes an SSL connection with a simulated server, as provided in an embodiment of the present invention. Figure 6 As shown, the Nginx proxy module constructs a ClientHello message using the client's random number, cipher suite, and compression algorithm from the original SSL handshake information and sends it to the simulated server. The simulated server returns the original ServerHello, Certificate, and ServerHelloDone messages. The Nginx proxy module then constructs a ClientKeyExchange message using the pre-master key from the original SSL handshake information. Since the key information of the SSL handshake is exactly the same as that of the original SSL connection, the Nginx proxy module calculates the same master key and constructs ChangeSipherSpec and Finished messages, which are then sent to the simulated server. The simulated server returns the original ChangeCipherSpec and Finished messages to the Nginx proxy module. The Nginx proxy module can correctly decrypt the original Finished message, completing the SSL handshake.

[0102] In some embodiments of this application, when the above-mentioned mirrored traffic is determined to be HTTP mirrored traffic, the above-mentioned HTTP mirrored traffic is parsed by an HTTP parser connected to the data plane to obtain HTTP traffic data; and the above-mentioned Nginx proxy module performs security detection on the above-mentioned HTTP mirrored traffic based on the HTTP traffic data.

[0103] Here, the aforementioned HTTP traffic data can be divided into: request data and response data; the aforementioned method includes: the HTTP parser sending the aforementioned request data to the sending queue of the aforementioned simulated client, and sending the aforementioned response data to the sending queue of the aforementioned simulated server; the simulated client sending the aforementioned request data to the aforementioned Nginx proxy module; when the aforementioned Nginx proxy module receives the aforementioned request data, it establishes a TCP connection with the simulated server and forwards the aforementioned request data to the simulated server; after receiving the aforementioned request data, the simulated server sends the response data in the sending queue to nginx for security detection, so as to complete the security detection of HTTP traffic by the Nginx proxy module.

[0104] In one implementation, the key suite of the master key is constructed based on the RSA key exchange algorithm.

[0105] In some embodiments, the step of the Nginx proxy module decrypting the original SSL message based on the master key includes: the Nginx proxy module decrypting the encrypted data in the original SSL message using a preset hardware acceleration device based on the master key to obtain the plaintext of the original SSL message.

[0106] Here, the Nginx proxy module can send the master key and the encrypted data in the original SSL message to the preset QAT acceleration card. The QAT acceleration card decrypts the encrypted data in the original SSL message to obtain the plaintext of the original SSL message.

[0107] For ease of understanding, Figure 7 This is a schematic diagram of the structure of a traffic detection device for an extended QAT hardware acceleration card provided in an embodiment of the present invention.

[0108] Depend on Figure 7 As shown, since software-implemented SSL encryption and decryption are very performance-intensive, the traffic detection device can be expanded with a QAT hardware acceleration card. After expansion, the Nginx proxy module will send the master key and the encrypted data in the original SSL message to the QAT hardware acceleration card for decryption, reducing the performance consumption of SSL encryption and decryption and enabling the device to handle more traffic.

[0109] Furthermore, the expanded traffic detection device adds three components: a QAT hardware acceleration card, a QAT engine, and a QAT driver. Specifically, during Nginx proxy module initialization, the QAT engine is initialized. The SSL decryption process then becomes: the Nginx proxy module sends the SSL ciphertext to the QAT engine, then to the QAT driver, and finally to the QAT hardware acceleration card. The Nginx proxy module then asynchronously processes other data. During the decryption process, the QAT hardware acceleration card continuously attempts to obtain the results. If decryption is successful, the QAT engine notifies the Nginx proxy module to retrieve the HTTP plaintext. After retrieving the HTTP plaintext, the Nginx proxy module performs security checks on it.

[0110] According to embodiments of the present invention, a traffic detection device for implementing a traffic detection method can be attached to a forwarding device, allowing the forwarding device to create a mirror image of the traffic and upload it to the traffic detection device, enabling security detection and early warning for HTTP or HTTPS traffic.

[0111] Example 2

[0112] Based on the above embodiments, Figure 8 This is a schematic diagram of another flow detection device provided in an embodiment of the present invention.

[0113] Depend on Figure 8 As shown, the device includes:

[0114] The SSL parser 31 is used to parse the original SSL message and original SSL handshake information transmitted between the client and the server from the received HTTPS mirror traffic when the received mirror traffic is HTTPS mirror traffic. The original SSL message is sent to the Nginx proxy module 33 through the simulated client 32 and the simulated server 34 according to the traffic direction of the HTTPS mirror traffic, and the original SSL handshake information is sent to the Nginx proxy module 33 through the simulated client 32.

[0115] The simulated client 32 is used to receive the original SSL message and the original SSL handshake information sent by the SSL parser 31 in the direction of the HTTPS mirror traffic, and send them to the Nginx proxy module 33.

[0116] The simulated server 34 is used to receive the original SSL messages sent by the SSL parser 31 in the direction of the HTTPS mirror traffic, and send them to the Nginx proxy module 33.

[0117] The aforementioned Nginx proxy module 33 is used to establish a first SSL connection between the aforementioned Nginx proxy module 33 and the aforementioned simulated client 32 based on the aforementioned original SSL handshake information, and to establish a second SSL connection between the aforementioned Nginx proxy module 33 and the aforementioned simulated server 34; wherein the aforementioned first SSL connection and the aforementioned second SSL connection use the same master key; and perform security detection operations after decrypting the aforementioned original SSL message based on the aforementioned master key.

[0118] In some implementations, the SSL parser 31 is further configured to parse the original SSL message and original SSL handshake information of the first HTTPS traffic from the mirrored traffic of the first HTTPS traffic sent by the client to the server in the aforementioned HTTPS mirrored traffic; and send the original SSL message of the first HTTPS traffic to the Nginx proxy module 33 through the simulated client 32.

[0119] In some implementations, the SSL parser 31 is further configured to parse the original SSL message of the second HTTPS traffic from the mirrored HTTPS traffic sent by the server to the client; and send the original SSL message of the second HTTPS traffic to the Nginx proxy module 33 through the simulated server 34.

[0120] In some implementations, during the establishment of the first SSL connection, the original SSL handshake information sent by the simulated client 32 is appended before the first SSL handshake message sent by the simulated client 32 to the Nginx proxy module; during the establishment of the second SSL connection, the client random number in the original SSL handshake information is carried in the first SSL handshake message sent by the Nginx proxy module to the simulated server.

[0121] In some implementations, the Nginx proxy module 33 is further configured to: receive the original SSL handshake information sent by the simulated client 32, and perform random number exchange with the simulated client 32 based on the server random number in the original SSL handshake information; after the random number exchange with the simulated client 32 is completed, generate the master key together with the simulated client 32 using the pre-master key in the original SSL handshake information, so as to complete the establishment of the first SSL connection between the Nginx proxy module 33 and the simulated server 34.

[0122] In some implementations, the Nginx proxy module 33 is further configured to perform a random number exchange with the simulated server 34 based on the client random number in the original SSL handshake information; after the random number exchange with the simulated server 34 is completed, the master key is generated jointly with the simulated server 34 using the pre-master key in the original SSL handshake information, so as to complete the establishment of a second SSL connection between the Nginx proxy module 33 and the simulated server 34.

[0123] In some implementations, the Nginx proxy module 33 is further configured to: decrypt the original SSL message using a preset hardware acceleration device based on the master key to obtain the plaintext of the original SSL message.

[0124] In some implementations, the SSL resolver 31, the emulated client 32, and the emulated server 34 are deployed in a bypass process; the SSL resolver 31 is connected to the emulated client 32 and the emulated server 34, respectively.

[0125] The flow detection device provided in this embodiment of the invention has the same technical features as the flow detection method provided in the above embodiments, and therefore can solve the same technical problems and achieve the same technical effects. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0126] Example 4

[0127] This embodiment provides an electronic device, including a processor and a memory. The memory stores computer-executable instructions that can be executed by the processor, and the processor executes the computer-executable instructions to implement the steps of the flow detection device method.

[0128] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of a flow detection device method.

[0129] See Figure 9 The diagram shows the structure of an electronic device, which includes a memory 41 and a processor 42. The memory 41 stores a computer program that can run on the processor 42. When the processor executes the computer program, it implements the steps provided by the above-described flow detection device method.

[0130] like Figure 9As shown, the device also includes a bus 43 and a communication interface 44, with the processor 42, the communication interface 44 and the memory 41 connected via the bus 43; the processor 42 is used to execute executable modules, such as computer programs, stored in the memory 41.

[0131] The memory 41 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between this system network element and at least one other network element is achieved through at least one communication interface 44 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0132] Bus 43 can be an ISA bus, PCI bus, or EISA bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 9 The symbol is represented by a single double-headed arrow, but this does not mean that there is only one bus or one type of bus.

[0133] The memory 41 stores the program, and the processor 42 executes the program after receiving the execution instruction. The method executed by the flow detection device disclosed in any of the foregoing embodiments of the present invention can be applied to the processor 42, or implemented by the processor 42. The processor 42 may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by the integrated logic circuit in the hardware of the processor 42 or by instructions in the form of software. The processor 42 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of the present invention. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this invention can be directly manifested as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory 41, and processor 42 reads information from memory 41 and, in conjunction with its hardware, completes the steps of the above method.

[0134] Furthermore, this embodiment of the invention also provides a machine-readable storage medium storing machine-executable instructions. When these machine-executable instructions are invoked and executed by the processor 42, they cause the processor 42 to implement the above-described flow detection device method.

[0135] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0136] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units described above can be a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0137] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0138] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0139] If the integrated units described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0140] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0141] Furthermore, the terms “first,” “second,” and “third” are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0142] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A flow rate detection method, characterized in that, include: When the received mirror traffic is HTTPS mirror traffic, the SSL parser parses the original SSL messages and original SSL handshake information transmitted between the client and the server from the HTTPS mirror traffic. The SSL resolver sends the original SSL message to the Nginx proxy module through the simulated client and simulated server according to the traffic direction of the HTTPS mirror traffic, and sends the original SSL handshake information to the Nginx proxy module through the simulated client; Based on the original SSL handshake information, the Nginx proxy module establishes a first SSL connection between itself and the simulated client, and establishes a second SSL connection between itself and the simulated server; wherein the first SSL connection and the second SSL connection use the same master key; The Nginx proxy module performs a security check operation after decrypting the original SSL message based on the master key.

2. The flow detection method according to claim 1, characterized in that, The SSL parser extracts the original SSL messages and original SSL handshake information transmitted between the client and server from the HTTPS mirror traffic, including: For the mirrored traffic of the first HTTPS traffic sent by the client to the server in the HTTPS mirrored traffic, the SSL parser parses the original SSL message and original SSL handshake information of the first HTTPS traffic from the HTTPS mirrored traffic; The SSL resolver sends the original SSL packet to the Nginx proxy module through the simulated client and simulated server according to the traffic direction of the HTTPS mirrored traffic, including: The SSL resolver sends the original SSL message of the first HTTPS traffic to the Nginx proxy module through a simulated client.

3. The flow detection method according to claim 1, characterized in that, The SSL parser extracts the original SSL messages and original SSL handshake information transmitted between the client and the server from the HTTPS mirror traffic, including: For the mirrored traffic of the second HTTPS traffic sent by the server to the client in the HTTPS mirrored traffic, the SSL parser parses the original SSL message and original SSL handshake information of the second HTTPS traffic from the HTTPS mirrored traffic; The SSL resolver sends the original SSL packet to the Nginx proxy module through the simulated client and simulated server according to the traffic direction of the HTTPS mirrored traffic, including: The SSL resolver sends the original SSL message of the second HTTPS traffic to the Nginx proxy module through a simulated server.

4. The flow detection method according to claim 1, characterized in that, The Nginx proxy module establishes a first SSL connection between itself and the simulated client based on the original SSL handshake information, including: The Nginx proxy module receives the original SSL handshake information sent by the simulated client, and performs a random number exchange with the simulated client based on the server-side random number in the original SSL handshake information. After the Nginx proxy module completes the random number exchange with the simulated client, it uses the pre-master key in the original SSL handshake information to generate the master key together with the simulated client, thereby establishing the first SSL connection between the Nginx proxy module and the simulated server.

5. The flow detection method according to claim 4, characterized in that, The Nginx proxy module establishes a second SSL connection between itself and the simulated server based on the original SSL handshake information, including: The Nginx proxy module performs a random number exchange with the simulated server based on the client random number in the original SSL handshake information; After the Nginx proxy module completes the random number exchange with the simulated server, it uses the pre-master key in the original SSL handshake information to jointly generate the master key with the simulated server, thereby establishing a second SSL connection between the Nginx proxy module and the simulated server.

6. The flow detection method according to any one of claims 1 to 5, characterized in that, During the establishment of the first SSL connection, the original SSL handshake information sent by the simulated client is appended before the first SSL handshake message sent by the simulated client to the Nginx proxy module; During the establishment of the second SSL connection, the client random number in the original SSL handshake information is carried in the first SSL handshake message sent by the Nginx proxy module to the simulated server.

7. The flow detection method according to claim 1, characterized in that, The Nginx proxy module decrypts the original SSL message based on the master key, including: The Nginx proxy module decrypts the encrypted data in the original SSL message using the master key and a preset hardware acceleration device to obtain the plaintext of the original SSL message.

8. The flow detection method according to claim 1, characterized in that, The SSL resolver, the simulated client, and the simulated server are deployed in a bypass process; the SSL resolver is connected to both the simulated client and the simulated server.

9. A flow detection device, characterized in that, include: An SSL resolver is used to, when receiving HTTPS mirror traffic, parse the original SSL messages and original SSL handshake information transmitted between the client and the server from the HTTPS mirror traffic, and send the original SSL messages to the Nginx proxy module through the simulated client and simulated server according to the traffic direction of the HTTPS mirror traffic, and send the original SSL handshake information to the Nginx proxy module through the simulated client. A simulated client is used to receive the original SSL message and the original SSL handshake information sent by the SSL resolver in the direction of the HTTPS mirror traffic, and send them to the Nginx proxy module. The simulated server is used to receive the original SSL message sent by the SSL resolver in the direction of the HTTPS mirror traffic, and send it to the Nginx proxy module; The Nginx proxy module is used to establish a first SSL connection between the Nginx proxy module and the simulated client based on the original SSL handshake information, and to establish a second SSL connection between the Nginx proxy module and the simulated server; wherein the first SSL connection and the second SSL connection use the same master key; The Nginx proxy module is also used to perform security detection operations after decrypting the original SSL message based on the master key.

10. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing computer-executable instructions that can be executed by the processor, the processor executing the computer-executable instructions to implement the traffic detection method according to any one of claims 1 to 8.

Images