CN116032657A - Flow monitoring method, system and electronic equipment - Google Patents
Flow monitoring method, system and electronic equipment Download PDFInfo
- Publication number
- CN116032657A CN116032657A CN202310114441.3A CN202310114441A CN116032657A CN 116032657 A CN116032657 A CN 116032657A CN 202310114441 A CN202310114441 A CN 202310114441A CN 116032657 A CN116032657 A CN 116032657A
- Authority
- CN
- China
- Prior art keywords
- server
- client
- service
- ssl
- key
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 75
- 238000012544 monitoring process Methods 0.000 title claims abstract description 45
- 238000004891 communication Methods 0.000 claims abstract description 152
- 230000008569 process Effects 0.000 claims description 19
- 238000012545 processing Methods 0.000 claims description 10
- 238000004590 computer program Methods 0.000 claims description 6
- 230000007246 mechanism Effects 0.000 claims description 4
- 238000005516 engineering process Methods 0.000 abstract description 31
- 238000010586 diagram Methods 0.000 description 16
- 238000012806 monitoring device Methods 0.000 description 10
- 238000012546 transfer Methods 0.000 description 9
- 230000006870 function Effects 0.000 description 3
- 230000005540 biological transmission Effects 0.000 description 2
- 230000008676 import Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000006855 networking Effects 0.000 description 1
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The present disclosure relates to the field of communications, and in particular, to a method, a system, and an electronic device for traffic monitoring. When the SSL client deployed on the server negotiates a communication secret key for encrypting HTTP session traffic between the service client deployed on the user terminal and the service server deployed on the server, the communication secret key and session information between the service client and the service server are intercepted, and the communication secret key and the session information are sent to the SSL server of the security device, so that the security device adds the communication secret key and the session information into a session table, and the HTTP session traffic between the service client and the service server is decrypted according to the session table, and the HTTP session traffic is processed, so that the security device can acquire the communication secret key negotiated by the forward encryption technology and the non-forward encryption technology, the monitoring range of the security device is enlarged, and the security of the whole network is improved.
Description
Technical Field
The present disclosure relates to the field of communications, and in particular, to a method, a system, and an electronic device for traffic monitoring.
Background
HTTP (HyperText Transfer Protocol ) is an application layer protocol for distributed, collaborative, and hypermedia information systems. In brief, a method of publishing and receiving HTML pages is used to transfer traffic between a Web browser and a Web server.
With increasing network size, HTTP traffic is increasingly occupying a larger proportion of the network. However, the HTTP protocol is not an encryption protocol, so there are many security risks in using the HTTP protocol for traffic transmission.
To address the security issue, HTTPS (Hypertext Transfer Protocol Secure, hypertext transfer security protocol) protocol has evolved. HTTPS (Hypertext Transfer Protocol Secure) the packets are encrypted using SSL (Secure Socket Layer, secure sockets layer)/TLS (Transport Layer Security, transport layer security protocol), the main purpose of which is to provide authentication of the web server, protecting the privacy and integrity of the exchanged data.
However, in practical applications, in order to ensure the security of the entire network, a security device needs to be configured on the network, and the security device needs to acquire HTTP traffic to parse to ensure the security of the network. However, when the HTTPS protocol is adopted between the user terminal and the server to perform traffic communication, the security device cannot decrypt the HTTPS traffic after obtaining the HTTPS traffic, so that the HTTPS traffic in the network cannot be monitored, and potential safety hazards are caused.
Disclosure of Invention
The application provides a flow monitoring method, a flow monitoring system and electronic equipment, which are used for expanding the flow monitoring range of safety equipment and improving the safety of the whole network.
According to a first aspect of the present application, the present application provides a traffic monitoring method, where the method is applied to a server, and an SSL client is deployed on the server; an SSL server is deployed on a security device between a user terminal and the server; the security device is connected with the forwarding device between the user terminal and the server in a bypass deployment mode, and the method comprises the following steps:
when the SSL client deployed on the server negotiates a communication key for encrypting HTTP session flow between the service client deployed on the user terminal and the service server deployed on the server, session information between the communication key and the service client and the service server is intercepted;
and the SSL client sends the communication secret key and the session information to an SSL server of the safety equipment, so that the safety equipment adds the communication secret key and the session information into a session table, decrypts the HTTP session traffic between the service client and the service server according to the session table, and processes the HTTP session traffic.
Optionally, the intercepting the communication key includes:
the SSL client acquires the negotiated communication secret key by using an EPBF mechanism.
Optionally, the communication key is a communication key negotiated by the service client and the service server through a forward encryption technology.
Optionally, the forward encryption technology includes one or more of the following: DHE encryption algorithm, ECDHE encryption algorithm.
Optionally, the SSL client sends the communication key and session information to an SSL server of the security device, including:
the SSL client constructs a customized SSL secret key message; carrying the communication secret key and the session information in a TLV format of the SSL secret key message;
and the SSL client sends the customized SSL key message to an SSL server on the security equipment.
According to a second aspect of the present application, there is provided a traffic monitoring method, where the method is applied to a security device, an SSL server is deployed on the security device, the security device is connected to a forwarding device between a user terminal and the server by way of bypass deployment, and an SSL client is deployed on the server; the method comprises the following steps:
receiving communication key information and session information sent by an SSL client deployed on the server through the SSL server; the communication key is obtained after the SSL client determines that the service server on the server and the service client on the user terminal negotiate a communication key for encrypting HTTP session flow; the session information is information of an HTTP session established by the service client and the service server;
adding the communication key and the session information to a recorded session table;
and decrypting the HTTP session traffic between the service client and the service server according to the session table, and processing the HTTP session traffic.
Optionally, the decrypting the HTTP session traffic between the service client and the service server according to the session table, and processing the HTTP session traffic includes:
when HTTP session traffic between the service client and the service server is received, acquiring target session information carried by the HTTP session traffic;
searching a communication key corresponding to the target session information in the session table;
decrypting the HTTP session traffic according to the searched communication key, and processing the decrypted HTTP session traffic.
According to a third aspect of the present application, there is provided a flow monitoring system, the system comprising: the system comprises a user terminal, a server, forwarding equipment and safety equipment; the forwarding equipment is deployed between the user terminal and the server, and the safety equipment is connected with the forwarding equipment in a bypass deployment mode; SSL clients are deployed on the server; SSL server side is deployed on the security equipment;
the service client deployed on the user terminal negotiates a communication key for encrypting HTTP session traffic with the service server deployed on the server;
an SSL client is deployed on the server, when the communication secret key is determined to be negotiated between the service client and the service server, the communication secret key is intercepted, and the intercepted communication secret key and session information between the service client and the service server are sent to the SSL server of the security device;
and the security equipment adds the received communication secret key and the received session information into a session table through the SSL server, decrypts the HTTP session traffic between the service client and the service server according to the session table, and processes the HTTP session traffic.
Optionally, the communication key is negotiated based on a forward encryption technology, and negotiating a communication key for encrypting HTTP session traffic between a service client deployed on the user terminal and a service server deployed on the server includes:
the business client generates a first random value, generates a client private key according to the first random value, and sends the client private key to the business server;
the service server generates a second random value, generates a server private key according to the second random value, and sends the server private key to the service client;
the business server generates the communication secret key based on the server private key and the client private key;
the service client generates the communication secret key based on the client private key and the server private key.
According to a fourth aspect of the present application, there is provided an electronic device comprising:
a memory for storing a computer program;
and the processor is used for realizing the flow monitoring method when executing the computer program stored in the memory.
In the application, besides the originally deployed service server on the server, the application also deploys an SSL client on the server and deploys an SSL server on the security device. After the SSL client monitors that the service server and the service client negotiate a communication key for encrypting HTTP session flow, the SSL client intercepts the communication key and session information between the service client and the service server. And the SSL client sends the communication secret key and the session information to the SSL server of the safety equipment, so that the safety equipment adds the communication secret key and the session information into a session table, decrypts the HTTP session traffic between the service client and the service server according to the session table, and processes the HTTP session traffic.
Therefore, no matter whether the service client and the service server are keys negotiated through the forward encryption technology or the non-forward encryption technology, the SSL client deployed on the server can intercept the communication key and send the communication key to the safety equipment as long as the keys are negotiated by the forward encryption technology or the non-forward encryption technology, so that the safety equipment can monitor the session traffic encrypted by the forward encryption technology or the non-forward encryption technology, the monitoring range of the safety equipment is enlarged, and the safety of the whole network is improved.
Drawings
FIG. 1 is a schematic diagram of a network architecture of a flow monitoring system according to an exemplary embodiment of the present application;
FIG. 2 is a schematic diagram of a flow monitoring system of the type shown in an exemplary embodiment of the present application;
FIG. 3 is a flow chart illustrating a method of flow monitoring according to an exemplary embodiment of the present application;
fig. 4 is a schematic diagram of TLV format of an SSL key message according to an exemplary embodiment of the present application;
FIG. 5 is a hardware block diagram of a server according to an exemplary embodiment of the present application;
FIG. 6 is a block diagram of a flow monitoring device according to an exemplary embodiment of the present application;
FIG. 7 is a hardware block diagram of a security device according to an exemplary embodiment of the present application;
fig. 8 is a block diagram of another flow monitoring device according to an exemplary embodiment of the present application.
Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples are not representative of all implementations consistent with the present application.
The terminology used in the present application is for the purpose of describing particular embodiments only and is not intended to be limiting of the present application. As used in this application, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited by these terms. These terms are only used to distinguish one type of information from another. For example, a first message may also be referred to as a second message, and similarly, a second message may also be referred to as a first message, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.
Referring to fig. 1, fig. 1 is a schematic diagram of a network structure of a flow monitoring system according to an exemplary embodiment of the present application.
The flow monitoring system includes: user terminal, server, transmitting device and safety device.
The user terminal equipment is provided with a service client, and the server is provided with a service server. The business client and the business server can forward the traffic.
The service client and the service server may be a client and a server for performing a certain service, respectively. For example, if the service is a video service, the service client may be a video client, and the service server is a video server. The user can watch the film by using the service client, the service client sends a film request to the service server after monitoring the film name required by the user, and the service server returns the film. Of course, in practical application, the service may be a game, shopping, payment, reading, storing, accessing, etc., and the service is only described by way of example and is not limited specifically.
And the forwarding equipment is arranged between the user terminal and the server and is used for forwarding the traffic between the user terminal and the server. The forwarding device may be a switch or a router, and is only described here by way of example, and is not particularly limited.
The safety equipment is deployed on the forwarding equipment in a bypass deployment mode, namely the safety equipment is connected with the forwarding equipment in a bypass deployment mode. The port on the forwarding device connected with the security device opens the port traffic mirror image, and the received traffic can be mirrored to the security device.
In practical applications, the service client of the user terminal may negotiate a communication key with the service server on the server. The service client may then encrypt the HTTP session traffic using the communication key and send the encrypted HTTP session traffic to the service server via the forwarding device.
When the forwarding device receives the encrypted HTTP session traffic from the service client, the forwarding device sends the encrypted HTTP session traffic to the security device, so that the security device decrypts the encrypted HTTP session traffic to analyze the decrypted HTTP session traffic and determine whether the decrypted HTTP session traffic is malicious traffic, thereby ensuring the security of networking. It can be seen that how to decrypt encrypted HTTP session traffic is a challenge.
In the existing traffic monitoring method, a service client deployed on a user terminal and a service server deployed on a server typically negotiate a communication key through an RSA (an encryption algorithm) key exchange method. The RSA technique is a non-forward secret algorithm that is characterized by the fact that the final communication key can be determined from intermediate information generated during the negotiation process. According to the characteristic, the security device determines a final communication key through intermediate information generated in the negotiation process, and decrypts the HTTP session traffic through the determined communication key.
For example, the negotiation process of RSA is:
the security device pre-imports the server private key.
The service client sends a key negotiation request to the service server. And the service server returns the public key of the server to the service client. The service client generates a client private key, and then encrypts the client private key by using the server public key to generate a key ciphertext. And then, the service client sends the key ciphertext to the service server.
And the service server decrypts the secret key ciphertext by adopting the server private key to obtain the client private key, and determines the client private key as the communication secret key.
When the secret key ciphertext passes through the forwarding device, the forwarding device mirrors the secret key ciphertext (namely, intermediate information in the negotiation process) to the security device through port flow mirror, the security device decrypts the secret key ciphertext by using the service-side private key which is pre-led in by the security device to obtain the client-side private key, and therefore the security device can also obtain the communication secret keys of the service client and the service server.
However, in practical applications, the service client and the service server use a forward encryption algorithm in addition to a non-forward encryption algorithm. The forward encryption algorithm is characterized in that even if intermediate information in the negotiation process is acquired, the communication key cannot be determined based on the intermediate information, that is, the communication key cannot be directly determined through the negotiated intermediate information. The security device cannot determine the final communication key even if it can obtain the intermediate information.
Therefore, the existing traffic monitoring mode can only acquire the communication key negotiated by the non-forward encryption technology, but cannot acquire the communication key negotiated by the forward encryption technology, so that the security device cannot monitor the traffic encrypted by the forward encryption technology in the network, thereby greatly reducing the network security.
In view of this, the present application provides a traffic monitoring method that can realize monitoring of session traffic through a forward encryption technique and a non-forward encryption technique.
In the application, besides the originally deployed service server on the server, the application also deploys an SSL client on the server and deploys an SSL server on the security device. After the SSL client monitors that the service server and the service client negotiate a communication key for encrypting HTTP session flow, the SSL client intercepts the communication key and session information between the service client and the service server. And the SSL client sends the communication secret key and the session information to the SSL server of the safety equipment, so that the safety equipment adds the communication secret key and the session information into a session table, decrypts the HTTP session traffic between the service client and the service server according to the session table, and processes the HTTP session traffic.
Therefore, no matter whether the service client and the service server are keys negotiated through the forward encryption technology or the non-forward encryption technology, the SSL client deployed on the server can intercept the communication key and send the communication key to the safety equipment as long as the keys are negotiated by the forward encryption technology or the non-forward encryption technology, so that the safety equipment can monitor the session traffic encrypted by the forward encryption technology or the non-forward encryption technology, the monitoring range of the safety equipment is enlarged, and the safety of the whole network is improved.
Referring to fig. 2, fig. 2 is a schematic diagram of a flow monitoring system according to an exemplary embodiment of the present application.
The traffic monitoring system of the present application is basically the same as the traffic monitoring system of fig. 1, except that the present application additionally deploys a secure socket layer client (also called SSL client) on a server and a secure socket layer server (also called SSL server) on a secure device.
Specifically, in the traffic monitoring system, a service client is deployed on a user terminal, and an SSL client is deployed on a server in addition to a service server. SSL service ends are deployed on the security equipment.
The user terminal is connected with the server through the forwarding equipment.
The security device is connected to the forwarding device by means of bypass deployment.
Referring to fig. 3, fig. 3 is a flow chart illustrating a flow monitoring method according to an exemplary embodiment of the present application, which may include the steps as follows. The method may be used in a flow monitoring system as shown in fig. 2.
Step 301: and when the client side of the secure socket layer deployed on the server monitors that a communication key for encrypting the session flow of the hypertext transfer protocol is negotiated between the service client side deployed on the user terminal and the service server side deployed on the server, intercepting the communication key and session information between the service client side and the service server side.
The secure socket layer client is also called SSL client, and the hypertext transfer protocol session traffic is also called HTTPS session traffic.
Step 301 is described in detail below by steps 3011 to 3012.
Step 3011: and negotiating a communication key for encrypting the HTTP session traffic between the service client deployed on the user terminal and the service server deployed on the server.
In the embodiment of the present application, the service client and the service server may negotiate the communication key through a non-forward encryption technology, or may negotiate the communication key through a forward encryption technology, which is only described by way of example, and is not limited in detail.
Among other things, non-forward encryption techniques may include: the RSA encryption algorithm (an encryption algorithm) may also include other non-forward encryption techniques, which are only exemplified herein and are not specifically limited.
The forward encryption technique includes: DHE (diffie-hellman key exchange) encryption algorithm, ECDHE (an algorithm that uses elliptic curve to perform key agreement) encryption algorithm, etc., of course, the forward encryption technique also includes other techniques in practical application, and the forward encryption technique is only exemplified here and is not specifically limited.
For the non-forward encryption technology, the communication key finally negotiated by the two ends can be determined based on intermediate information in the negotiation process. For forward encryption techniques, the communication key that is ultimately negotiated by the two ends may not be determined based on intermediate information in the negotiation process.
In an alternative implementation, the service client and the service server may employ non-forward encryption techniques for communication key agreement.
For example, assume that the non-forward encryption technique is the RSA algorithm.
When the method is implemented, the service client side sends a key negotiation request to the service server side. The service server returns the server public key S2 to the service client. The service client generates a client private key C1. The service client may encrypt the client private key C1 using the server public key S2 to generate the key ciphertext M. Then, the service client sends the key ciphertext M to the service server.
The service server decrypts the secret key ciphertext by adopting the server private key S1 to obtain the client private key C1, and determines the client private key as the communication secret key.
In another alternative implementation, the traffic client and the traffic server may employ forward encryption techniques to conduct the communication key agreement.
For example, assuming that the service client and the service server use the EDH algorithm for key negotiation, the key negotiation method is exemplarily described below through steps A1 to A4.
Step A1: the business client generates a first random value, generates a client private key according to the first random value, and sends the generated client private key to the business server.
In an alternative implementation, the service client generates a first random value Xa. The service client may then generate a client private key from the at least one preset value and the first random value.
For example, the preset values q and p are industry accepted random values. The service client may generate a client private key Pa according to a code formula pa=q Xa mod p. The service client may then send the client private key Pa to the service server. Where mod is a modulo operation.
Step A2: and the service server generates a second random value, generates a server private key according to the second random value, and sends the server private key to the service client.
In an alternative implementation, the service server generates a second random value Xb. Then, the service server generates a server private key Pb according to at least one preset value and the second random value.
For example, the preset values q and p are industry accepted random values. The service server may generate a server private key Pb according to a code formula pb=q Xb mod p. The service client may then send the service client the server private key Pb. Where mod is a modulo operation.
Step A3: and the service server generates the communication secret key based on the server private key and the service client private key.
In an alternative implementation manner, the service server may generate the communication secret key S through the server private key Pb, the service client private key Pa, and a preset value.
For example, the service end may generate the communication key S according to the code formula s=pb Xa mod p.
Step A4: the service client generates the communication secret key based on the client private key and the server private key.
In an alternative implementation, the service client may generate the communication key through the server private key Pb, the service client private key Pa, and a preset value.
For example, the service client may generate the communication key S according to the code formula s=pb Xa mod p.
Therefore, the communication keys negotiated by the service client and the service server are the same, and are S.
Step 3012: and when the SSL client deployed on the server negotiates a communication key for encrypting HTTP session traffic between the service client and the service server, intercepting the communication key and session information between the service client and the service server.
In the present application, in order to obtain a communication key negotiated between a service client and a service server. The application deploys SSL clients on a server. The SSL client intercepts a communication key generated by the business server.
When the method is implemented, the SSL client can intercept a communication key generated by the service server and session information of a session between the service client and the service server through an EPBF (Extended Berkeley Packet Filter extended Berkeley packet filter) technology.
In implementation, the EPBF is event-driven, and the present application uses a server-side generated communication key as an event. When the event that the server generates the communication secret key occurs, the SSL client can acquire the communication secret key and the session information generated by the server through an EPBF mechanism.
The session information refers to information that can identify a session, and may include information such as source IP, destination IP, source port, destination port, and protocol of the session. The session information is only exemplarily described herein, and is not particularly limited.
Step 302: and the secure socket layer client sends the communication secret key and the session information to a secure socket layer server on the secure equipment.
In implementation, to prevent other devices from intercepting the communication key, a threat is posed to the network. The SSL client may customize the SSL key message and carry the communication key and session information in TLV format of the SSL key message.
For example, as shown in fig. 4, fig. 4 is a schematic diagram of TLV format of an SSL key message according to an exemplary embodiment of the present application.
As shown in fig. 4, the TLV format includes a Type (Type) field, a Length (Length) field, and a Value (Value) field.
When the value of the Type field is a first preset value, the user-defined message is an SSL key message. For example, the first preset value may be 1, which is only exemplarily described herein and is not particularly limited. When the Type field takes other values, other types of messages are indicated when the message is custom.
The Value of the Length field is a variable, which indicates the Length of the Value field.
The Value field may carry the negotiated communication key and session information.
In this embodiment of the present application, after intercepting the communication key and the session information, the SSL client may construct a custom message, set the Value of Type in the custom message to 1, and carry the communication key and the session information in the Value field, so as to construct an SSL key message. The SSL client sends an SSL key message to an SSL server deployed on the security device.
Step 303: and the safety equipment receives the communication key information and the session information sent by the safety socket layer client side deployed on the server through the safety socket layer server side.
When implemented, the security device may receive, via the SSL server, custom messages sent by SSL clients deployed on the server.
The security device may detect a Type value of the custom message, and when the Type value is a first preset value, indicate that the custom message is an SSL key message. Further, the security device may obtain the negotiated communication key and session information from the Value field of the SSL key message.
Step 304: the secure device adds the communication key and the session information to a recorded session table.
A session table is recorded on the secure device, the session table including session information and a communication key for an established session.
After resolving the communication key and the session information from the SSL key information, the secure device may add the communication key and the session information in the resolution to the session table.
Step 305: and the security equipment decrypts the hypertext transfer protocol session flow between the service client and the service server according to the session table and processes the hypertext transfer protocol session flow.
When the security device receives the HTTP session traffic between the service client and the service server, the security device may obtain the target session information (such as the source IP, the destination IP, the source port, the destination port, and the protocol) carried by the session traffic.
The secure device may then look up the communication key corresponding to the carried target session information in the session table.
If the communication key exists, the security device can decrypt the HTTP session traffic by using the communication key, and process the decrypted HTTP session traffic. For example, the secure device may parse the decrypted HTTP traffic to determine whether the HTTP session traffic is malicious traffic.
As can be seen from the above description, in the present application, no matter whether the service client side and the service server side are keys negotiated by the forward encryption technology or the non-forward encryption technology, as long as the service client side and the service server side negotiate the keys, the SSL client side deployed on the server can intercept the communication key and send the communication key to the security device, so that the security device can monitor the session traffic encrypted by using the forward encryption technology or the non-forward encryption technology, thereby expanding the monitoring range of the security device and improving the security of the whole network.
In addition, in the application, the SSL client sends the communication key and the session information to the security device through the custom SSL key message, and since the custom SSL key message is not easily parsed by other devices, the security of the communication key transmission can be further ensured.
The flow monitoring method provided by the application is described in detail below by taking a DHE algorithm as an example of a communication key negotiation manner between a service client and a service server.
Step B1: the service client generates a first random value Xa. Then, the service client can generate a client private key Pa according to the second preset value p, the third preset value q and the first random value Xa, and send the generated client private key Pa to the service server.
Step B2: the service server generates a second random value Xb. Then, the service server may generate a server private key Pb according to the second preset value p, the third preset value q and the second random value Xb, and send the generated server private key Pb to the service client.
Step B3: the service server may generate a communication secret key S by using the server private key Pb, the service client private key Pa, and the third preset value q.
Step B4: the service client may generate the communication secret key S by using the service client private key Pb, the service client private key Pa, and the third preset value q.
Step B5: the SSL client on the server intercepts a communication secret key S generated by the service server and session information of a session between the service client and the service server through an EPBF technology.
Step B6: the SSL client constructs a customized SSL key message and carries a communication key S and session information in the SSL key message.
Step B7: and the SSL client sends the SSL key information to an SSL server deployed on the security equipment.
Step B8: the security device obtains the communication key S and the session information carried by the SSL key information.
Step B9: the secure device adds the communication key S and session information to the session table.
Step B10: when the security device receives HTTP session traffic between the service client and the service server, session information carried by the HTTP session traffic is obtained;
step B11: the security device searches the communication secret key corresponding to the session information in the session table;
step B12: and the safety equipment decrypts the HTTP session traffic according to the searched communication key and processes the decrypted HTTP session traffic.
Referring to fig. 5, fig. 5 is a hardware configuration diagram of a server according to an exemplary embodiment of the present application.
Corresponding to the foregoing embodiments of the flow monitoring method, the present application also provides embodiments of a flow monitoring device.
The embodiment of the flow monitoring device can be applied to a server. The apparatus embodiments may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in a nonvolatile memory into a memory by a processor of a server where the device is located. In terms of hardware, as shown in fig. 5, a hardware structure diagram of a server where the flow monitoring device is located in the present application is shown in fig. 5, and in addition to the processor, the memory, the network output interface, and the nonvolatile memory shown in fig. 5, the server where the device is located in the embodiment generally may further include other hardware according to the actual function of the server, which is not described herein again.
Referring to fig. 6, fig. 6 is a block diagram of a traffic monitoring device according to an exemplary embodiment of the present application, the device being applied to an SSL client of a server; an SSL server is deployed on a security device between a user terminal and the server; the security device is connected with the forwarding device between the user terminal and the server in a bypass deployment mode, and the device comprises:
an obtaining unit 601, configured to intercept session information between a communication key used for encrypting HTTP session traffic when negotiating the communication key between a service client deployed on the user terminal and a service server deployed on the server;
and the sending unit 602 is configured to send the communication key and the session information to an SSL server of the security device, so that the security device adds the communication key and the session information to a session table, and decrypts HTTP session traffic between the service client and the service server according to the session table, thereby processing the HTTP session traffic.
Optionally, the obtaining unit 601 is configured to obtain the negotiated communication key by using an EPBF mechanism when intercepting the communication key.
Optionally, the communication key is a communication key negotiated by the service client and the service server through a forward encryption technology.
Optionally, the forward encryption technology includes one or more of the following: DHE encryption algorithm, ECDHE encryption algorithm.
Optionally, the sending unit 602 is configured to send a custom SSL key message when sending the communication key and session information to an SSL server of the security device; and carrying the communication key and the session information in a TLV format of the SSL key message.
Referring to fig. 7, fig. 7 is a hardware configuration diagram of a security device according to an exemplary embodiment of the present application.
Corresponding to the foregoing embodiments of the flow monitoring method, the present application also provides embodiments of a flow monitoring device.
The flow monitoring device can be applied to safety equipment. The apparatus embodiments may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in the nonvolatile memory into the memory by the processor of the security device where the device is located for operation. In terms of hardware, as shown in fig. 7, a hardware structure diagram of the security rope in which the flow monitoring device is located is shown in fig. 7, and in addition to the processor, the memory, the network output interface, and the nonvolatile memory shown in fig. 7, the security device in the embodiment generally includes other hardware according to the actual function of the security device, which is not described herein again.
Referring to fig. 8, fig. 8 is a block diagram of another flow monitoring device according to an exemplary embodiment of the present application. The device is applied to security equipment, an SSL server is deployed on the security equipment, the security equipment is connected with forwarding equipment between a user terminal and the server in a bypass deployment mode, and an SSL client is deployed on the server; the device comprises:
a receiving unit 801, configured to receive, through the SSL server, communication key information and session information sent by an SSL client deployed on the server; the communication key is obtained after the SSL client determines that the service server on the server and the service client on the user terminal negotiate a communication key for encrypting HTTP session flow; the session information is information of an HTTP session established by the service client and the service server;
an updating unit 802, configured to add the communication key and the session information to a recorded session table;
and the processing unit 803 is configured to decrypt HTTP session traffic between the service client and the service server according to the session table, and process the HTTP session traffic.
Optionally, the processing unit 803 is configured to obtain, when the HTTP session traffic between the service client and the service server is received and the HTTP session traffic between the service client and the service server is decrypted according to the session table, target session information carried by the HTTP session traffic; searching a communication key corresponding to the target session information in the session table; decrypting the HTTP session traffic according to the searched communication key, and processing the decrypted HTTP session traffic.
In addition, the present application further provides a flow monitoring system, which can execute the flow monitoring method, and is not described herein.
The implementation process of the functions and roles of each unit in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.
For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present application. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
The foregoing description of the preferred embodiments of the present invention is not intended to limit the invention to the precise form disclosed, and any modifications, equivalents, improvements and alternatives falling within the spirit and principles of the present invention are intended to be included within the scope of the present invention.
Claims (10)
1. The traffic monitoring method is characterized by being applied to a server, and SSL clients are deployed on the server; an SSL server is deployed on a security device between a user terminal and the server; the security device is connected with the forwarding device between the user terminal and the server in a bypass deployment mode, and the method comprises the following steps:
when the SSL client deployed on the server negotiates a communication key for encrypting HTTP session flow between the service client deployed on the user terminal and the service server deployed on the server, session information between the communication key and the service client and the service server is intercepted;
and the SSL client sends the communication secret key and the session information to an SSL server of the safety equipment, so that the safety equipment adds the communication secret key and the session information into a session table, decrypts the HTTP session traffic between the service client and the service server according to the session table, and processes the HTTP session traffic.
2. The traffic monitoring method according to claim 1, wherein the intercepting the communication key comprises:
the SSL client acquires the negotiated communication secret key by using an EPBF mechanism.
3. The traffic monitoring method according to claim 1, wherein the communication key is a communication key negotiated by the service client and the service server through a forward encryption technique.
4. A traffic monitoring method according to claim 3, wherein the forward encryption technique comprises one or more of the following: DHE encryption algorithm, ECDHE encryption algorithm.
5. The traffic monitoring method according to claim 1, wherein the SSL client sends the communication key and session information to an SSL server of the security device, comprising:
the SSL client constructs a customized SSL secret key message; carrying the communication secret key and the session information in a TLV format of the SSL secret key message;
and the SSL client sends the customized SSL key message to an SSL server on the security equipment.
6. The traffic monitoring method is characterized in that the method is applied to security equipment, an SSL server is deployed on the security equipment, the security equipment is connected with forwarding equipment between a user terminal and a server in a bypass deployment mode, and an SSL client is deployed on the server; the method comprises the following steps:
receiving communication key information and session information sent by an SSL client deployed on the server through the SSL server; the communication key is obtained after the SSL client determines that the service server on the server and the service client on the user terminal negotiate a communication key for encrypting HTTP session flow; the session information is information of an HTTP session established by the service client and the service server;
adding the communication key and the session information to a recorded session table;
and decrypting the HTTP session traffic between the service client and the service server according to the session table, and processing the HTTP session traffic.
7. The traffic monitoring method according to claim 6, wherein decrypting the HTTP session traffic between the service client and the service server according to the session table, processing the HTTP session traffic, comprises:
when HTTP session traffic between the service client and the service server is received, acquiring target session information carried by the HTTP session traffic;
searching a communication key corresponding to the target session information in the session table;
decrypting the HTTP session traffic according to the searched communication key, and processing the decrypted HTTP session traffic.
8. A flow monitoring system, the system comprising: the system comprises a user terminal, a server, forwarding equipment and safety equipment; the forwarding equipment is deployed between the user terminal and the server, and the safety equipment is connected with the forwarding equipment in a bypass deployment mode; SSL clients are deployed on the server; SSL server side is deployed on the security equipment;
the service client deployed on the user terminal negotiates a communication key for encrypting HTTP session traffic with the service server deployed on the server;
an SSL client is deployed on the server, when the communication secret key is determined to be negotiated between the service client and the service server, the communication secret key is intercepted, and the intercepted communication secret key and session information between the service client and the service server are sent to the SSL server of the security device;
and the security equipment adds the received communication secret key and the received session information into a session table through the SSL server, decrypts the HTTP session traffic between the service client and the service server according to the session table, and processes the HTTP session traffic.
9. The traffic monitoring system according to claim 8, wherein the communication key is negotiated based on a forward encryption technique, and wherein the service client deployed on the user terminal negotiates a communication key for encrypting HTTP session traffic with the service server deployed on the server, comprising:
the business client generates a first random value, generates a client private key according to the first random value, and sends the client private key to the business server;
the service server generates a second random value, generates a server private key according to the second random value, and sends the server private key to the service client;
the business server generates the communication secret key based on the server private key and the client private key;
the service client generates the communication secret key based on the client private key and the server private key.
10. An electronic device, comprising:
a memory for storing a computer program;
a processor for carrying out the method steps of any one of claims 1-7 when executing a computer program stored on said memory.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310114441.3A CN116032657A (en) | 2023-02-15 | 2023-02-15 | Flow monitoring method, system and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310114441.3A CN116032657A (en) | 2023-02-15 | 2023-02-15 | Flow monitoring method, system and electronic equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN116032657A true CN116032657A (en) | 2023-04-28 |
Family
ID=86070677
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310114441.3A Pending CN116032657A (en) | 2023-02-15 | 2023-02-15 | Flow monitoring method, system and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN116032657A (en) |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110870277A (en) * | 2017-06-26 | 2020-03-06 | 微软技术许可有限责任公司 | Introducing middleboxes into secure communication between a client and a server |
| US20200177566A1 (en) * | 2018-11-29 | 2020-06-04 | Checkpoint Software Technologies Ltd. | Method and system for cooperative inspection of encrypted sessions |
| CN111819824A (en) * | 2017-12-23 | 2020-10-23 | 迈克菲有限责任公司 | Decrypting transport layer security traffic without a broker |
| CN114172645A (en) * | 2021-12-06 | 2022-03-11 | 北京天融信网络安全技术有限公司 | Communication bypass auditing method and device, electronic equipment and storage medium |
| CN114499913A (en) * | 2020-10-26 | 2022-05-13 | 华为技术有限公司 | Encrypted message detection method and protection equipment |
| CN115514583A (en) * | 2022-11-21 | 2022-12-23 | 北京长亭未来科技有限公司 | Flow acquisition and blocking method, system, equipment and storage medium |
-
2023
- 2023-02-15 CN CN202310114441.3A patent/CN116032657A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110870277A (en) * | 2017-06-26 | 2020-03-06 | 微软技术许可有限责任公司 | Introducing middleboxes into secure communication between a client and a server |
| CN111819824A (en) * | 2017-12-23 | 2020-10-23 | 迈克菲有限责任公司 | Decrypting transport layer security traffic without a broker |
| US20200177566A1 (en) * | 2018-11-29 | 2020-06-04 | Checkpoint Software Technologies Ltd. | Method and system for cooperative inspection of encrypted sessions |
| CN114499913A (en) * | 2020-10-26 | 2022-05-13 | 华为技术有限公司 | Encrypted message detection method and protection equipment |
| CN114172645A (en) * | 2021-12-06 | 2022-03-11 | 北京天融信网络安全技术有限公司 | Communication bypass auditing method and device, electronic equipment and storage medium |
| CN115514583A (en) * | 2022-11-21 | 2022-12-23 | 北京长亭未来科技有限公司 | Flow acquisition and blocking method, system, equipment and storage medium |
Non-Patent Citations (1)
| Title |
|---|
| 舒剑: "《电子商务中的认证协议研究》" * |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11477037B2 (en) | Providing forward secrecy in a terminating SSL/TLS connection proxy using ephemeral Diffie-Hellman key exchange | |
| US10091240B2 (en) | Providing forward secrecy in a terminating TLS connection proxy | |
| CN110190955B (en) | Information processing method and device based on secure socket layer protocol authentication | |
| JP5744172B2 (en) | Proxy SSL handoff via intermediate stream renegotiation | |
| US7353380B2 (en) | Method and apparatus for providing secure streaming data transmission facilities using unreliable protocols | |
| US8179818B2 (en) | Proxy terminal, server apparatus, proxy terminal communication path setting method, and server apparatus communication path setting method | |
| CN109413060B (en) | Message processing method, device, equipment and storage medium | |
| CN113067828B (en) | Message processing method, device, server, computer equipment and storage medium | |
| JP4107213B2 (en) | Packet judgment device | |
| CN114448730B (en) | Packet forwarding method and device based on block chain network and transaction processing method | |
| CN101436933A (en) | HTTPS encipher access method, system and apparatus | |
| CN110493367A (en) | The non-public server of unaddressed IPv6, client computer and communication means | |
| CN114938312B (en) | Data transmission method and device | |
| CN112839062B (en) | Port hiding method, device and equipment with mixed authentication signals | |
| US10015208B2 (en) | Single proxies in secure communication using service function chaining | |
| CN107276996A (en) | The transmission method and system of a kind of journal file | |
| EP3216163B1 (en) | Providing forward secrecy in a terminating ssl/tls connection proxy using ephemeral diffie-hellman key exchange | |
| CN114095195B (en) | Method, network device, and non-transitory computer readable medium for adaptive control of secure socket layer proxy | |
| US20240106811A1 (en) | Systems and methods for network privacy | |
| CN116032657A (en) | Flow monitoring method, system and electronic equipment | |
| CN114244569B (en) | SSL VPN remote access method, system and computer equipment | |
| Risterucci et al. | A new secure virtual connector approach for communication within large distributed systems | |
| Manangi et al. | Analysis of Security Features in 5 Layer Internet Model |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20230428 |
|
| RJ01 | Rejection of invention patent application after publication |