Traffic data packet processing method, device, system, equipment and storage medium

Abstract

The present disclosure relates to the technical field of network communication, and discloses a traffic data packet processing method, device, system, equipment and storage medium. The method comprises: obtaining a target data packet, the target data packet being a traffic data packet generated when a client establishes a connection with a server, the target data packet comprising a session ticket between the client and the server; based on unique identification information of the session ticket, pulling key information corresponding to the session ticket; decrypting the session ticket based on the key information to obtain a message key corresponding to the session ticket; and decrypting a message carried by the target data packet based on the message key to obtain target plaintext information. Through the technical solution of the present disclosure, the decryption of encrypted data packets is realized, the packet capture is not required to be invaded, the network link between the client and the server is not affected, and the performance of the network link and the security of data packet capture are ensured.

Description

Technical Field

[0001] This disclosure relates to the field of network communication technology, specifically to a method, apparatus, system, device, and storage medium for processing traffic data packets. Background Technology

[0002] For the development of a web application, packet capture is an important debugging technique during performance tuning, troubleshooting, and maintenance. Packet capture can be categorized based on its location: client-side packet capture, network link packet capture, and server-side packet capture. However, both client-side and server-side packet capture can negatively impact user experience or server performance; therefore, network link packet capture is typically chosen as the preferred debugging method for web applications.

[0003] Existing network packet capture methods primarily focus on capturing and clustering packets at the IP or TCP layer, making it difficult to decrypt encrypted data at the application layer. Alternatively, man-in-the-middle proxies can be used, but these compromise the security of the original client and are intrusive, potentially impacting the overall network performance due to the performance of the capture tool itself. Therefore, securely capturing and decrypting data packets in network links has become a critical issue that needs to be addressed during application debugging. Summary of the Invention

[0004] In view of this, the present disclosure provides a method, apparatus, system, device, and storage medium for processing traffic data packets, in order to solve the problem that existing packet capture methods are difficult to securely capture and decrypt data packets in network links.

[0005] According to a first aspect, embodiments of this disclosure provide a method for processing traffic data packets, comprising: acquiring a target data packet, the target data packet being a traffic data packet generated by a client and a server establishing a connection, the target data packet including a session ticket between the client and the server; retrieving key information corresponding to the session ticket based on the unique identifier information of the session ticket; decrypting the session ticket based on the key information to obtain a message key corresponding to the session ticket; and decrypting the message carried in the target data packet based on the message key to obtain target plaintext information.

[0006] The traffic data packet processing method provided in this disclosure acquires traffic data packets during the connection establishment process between the client and the server, identifies target data packets including session tickets, and then retrieves the corresponding key information based on the unique identifier information of the session ticket for decryption to obtain the message information carried by the target data packet. This allows relevant technicians to perform application debugging based on the message information. This method achieves decryption of encrypted data packets without intrusive packet capture, and does not affect the network link between the client and the server, ensuring network link performance and data packet capture security.

[0007] According to a second aspect, embodiments of this disclosure provide a traffic data packet processing apparatus, comprising: a traffic receiving module, configured to acquire a target data packet, wherein the target data packet is a traffic data packet generated when a client and a server establish a connection, and the target data packet includes a session ticket between the client and the server; a key updating module, configured to retrieve key information corresponding to the session ticket based on the unique identifier information of the session ticket; and a decryption module, configured to decrypt the session ticket based on the key information to obtain a message key corresponding to the session ticket; and to decrypt the message carried in the target data packet based on the message key to obtain target plaintext information.

[0008] The traffic data packet processing apparatus provided in this embodiment acquires traffic data packets during the connection establishment process between the client and the server, identifies target data packets including session tickets, and then retrieves the corresponding key information based on the unique identifier information of the session ticket for decryption to obtain the message information carried by the target data packet. This allows relevant technicians to perform application debugging based on the message information. The apparatus is deployed in a bypass manner, enabling decryption of encrypted data packets without intrusive packet capture, thus not affecting the network link between the client and the server, ensuring network link performance and data packet capture security.

[0009] According to a third aspect, embodiments of this disclosure provide a traffic data packet processing system, including: a client and a server; a traffic redirection device deployed on the transmission link between the client and the server, used to capture traffic data packets generated when a connection is established between the client and the server; a key management device communicatively connected to the server, used to manage key information of the server's encrypted session ticket; and a packet capture device deployed in bypass mode, the packet capture device being communicatively connected to both the traffic redirection device and the key management device, used to execute the traffic data packet processing method described in the first aspect or any embodiment of the first aspect.

[0010] The traffic data packet processing system provided in this disclosure uses a traffic diversion device to redirect traffic data packets during the connection establishment process between the client and the server to a bypass-deployed traffic data packet processing device. This processing device retrieves the corresponding key information from a key management device to decrypt the session ticket generated by the server, thereby obtaining the message information carried by the target data packet. This message information allows technical personnel to perform application debugging. This system achieves decryption of encrypted data packets without intrusive packet capture, thus avoiding impact on the network link between the client and the server, ensuring network link performance and data packet capture security.

[0011] According to a fourth aspect, this disclosure provides an electronic device, including: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the computer instructions to perform the data packet processing method described in the first aspect or any embodiment of the first aspect.

[0012] According to a fifth aspect, embodiments of this disclosure provide a computer-readable storage medium storing computer instructions for causing a computer to perform the traffic data packet processing method according to the first aspect or any embodiment of the first aspect.

[0013] It should be noted that the beneficial effects of the server and computer-readable storage medium provided in the embodiments of this disclosure can be found in the description of the corresponding content in the method for processing traffic data packets, and will not be repeated here. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the specific embodiments of this disclosure or 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 this disclosure. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of a traffic data packet processing system according to an embodiment of the present disclosure;

[0016] Figure 2 This is a flowchart of a method for processing traffic data packets according to an embodiment of the present disclosure;

[0017] Figure 3 This is another flowchart of a method for processing traffic data packets according to an embodiment of the present disclosure;

[0018] Figure 4This is another schematic diagram of a traffic data packet processing system according to an embodiment of the present disclosure;

[0019] Figure 5 This is yet another flowchart of a method for processing traffic data packets according to an embodiment of the present disclosure;

[0020] Figure 6 This is a structural block diagram of a traffic data packet processing apparatus according to an embodiment of the present disclosure;

[0021] Figure 7 This is another structural block diagram of a traffic data packet processing apparatus according to an embodiment of the present disclosure;

[0022] Figure 8 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this disclosure. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0024] For the development of a web application, packet capture is an important debugging technique during performance tuning, troubleshooting, and maintenance. Packet capture can be categorized based on its location: client-side packet capture, network link packet capture, and server-side packet capture. However, both client-side and server-side packet capture can negatively impact user experience or server performance; therefore, network link packet capture is typically chosen as the preferred debugging method for web applications.

[0025] Currently, common network packet capture methods include: 1) Packet capture and clustering based on the IP or TCP layer, but this is difficult to achieve parsing of application-layer encrypted data. However, most network applications now use encrypted transmission, and simply displaying packets at the network layer is often insufficient. 2) Using a man-in-the-middle proxy for packet capture. This method uses a man-in-the-middle packet capture tool as both a server and a client, integrating it into the existing client-server communication link. The tool acts as a man-in-the-middle server, establishing a TLS connection with the original client, and simultaneously as a man-in-the-middle client, establishing a TLS connection with the target server. This allows the capture of plaintext data sent by both the original client and the target server. However, to simulate the TLS connection between the target server and the original client, the man-in-the-middle server often employs two methods: either the original client trusts the certificate issued by the man-in-the-middle server, or the target server's certificate is imported into the man-in-the-middle server. The former introduces inconvenience or compromises the original client's security, while the latter introduces the possibility of certificate loss. Meanwhile, man-in-the-middle packet sniffing tools are connected in the communication link between the client and the server. Since they are intrusive packet sniffing tools, the performance of the entire transmission link may be affected by the performance of the packet sniffing tool itself.

[0026] Based on this, the technical solution of this application deploys a packet capture device in bypass mode on the communication link between the client and the server. This device captures traffic data packets during the connection establishment process between the client and the server, identifies target data packets including session tickets, and then retrieves the corresponding key information based on the unique identifier of the session ticket for decryption. This decryption operation yields the message information carried by the target data packet, allowing technical personnel to perform application debugging based on this message information. Therefore, this method avoids intrusive packet capture, does not affect the network link between the client and the server, achieves decryption of encrypted data packets, and ensures both network link performance and data packet capture security.

[0027] This disclosure provides a system for processing traffic data packets, such as... Figure 1 As shown, the traffic data packet processing system may include: client 11, server 12, traffic redirection device 13, key management device 14, and packet capture device 15.

[0028] The traffic redirection device 13 is deployed on the transmission link between the client 11 and the server 12, and is used to capture the traffic data packets generated when the connection is established between the client 11 and the server 12. Specifically, the traffic redirection device 13 is connected in series in the transmission link between the client 11 and the server 12. The traffic redirection device 13 can be a router, switch, or multi-port repeater HUB, or other device capable of traffic redirection.

[0029] The key management device 14 is communicatively connected to the server 12 and is used to manage and store the key information of the encrypted dialogue tickets of the server 12. Specifically, the key management device 14 is deployed on the server 12 side and interconnected with the packet capture device 15. It can provide key management services for multiple server devices and packet capture devices simultaneously, thereby decoupling the packet capture device 15 from the server 12.

[0030] Packet capture device 15 is deployed in bypass mode and is communicatively connected to traffic redirection device 13 and key management device 14. Specifically, packet capture device 15 is used to obtain traffic data packets during the communication connection process between client 11 and server 12 from traffic redirection device 13, and parse traffic data packets containing session tickets, i.e., target data packets, from the traffic data packets; retrieve key information corresponding to the session tickets from key management device 14 to decrypt the session tickets in the target data packets to obtain the message key corresponding to the session tickets; and then decrypt the messages carried in the target data packets using the message key to obtain the target plaintext information.

[0031] It should be noted that, considering packet capture security, packet capture device 15 and server 12 can be deployed in the same intranet environment, which can be a traditional network or a cloud environment, without specific limitations here.

[0032] The traffic data packet processing system provided in this embodiment uses a traffic diversion device to redirect traffic data packets during the connection establishment process between the client and the server to a bypass-deployed traffic data packet processing device. This processing device retrieves the corresponding key information from the key management device to decrypt the session ticket generated by the server, thereby obtaining the message information carried by the target data packet. This message information allows relevant technicians to perform application debugging. This system achieves decryption of encrypted data packets without intrusive packet capture, thus avoiding impact on the network link between the client and the server, ensuring network link performance and data packet capture security.

[0033] According to an embodiment of the present disclosure, an embodiment of a method for processing traffic data packets is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0034] This embodiment provides a method for processing traffic data packets, which can be used in the packet capture device of the traffic data packet processing system described above. The packet capture device can be an electronic device such as a server. Figure 2This is a flowchart of a traffic data packet processing method according to an embodiment of the present disclosure, such as... Figure 2 As shown, the process includes the following steps:

[0035] S11, Obtain the target data packet.

[0036] The target data packet is the traffic data packet generated when the client and the server establish a connection. The target data packet includes the dialogue ticket between the client and the server.

[0037] A traffic redirection device is set up in the transmission link between the client and the server. The traffic redirection device acts as a node in the transmission link between the client and the server, forming a communication link: client <=> traffic redirection device <=> server, such as... Figure 1 As shown. This traffic redirection device is interconnected with the packet capture device. It can redirect the traffic data packets between the client and the server during the connection establishment process to the packet capture device. That is, the packet capture device is deployed in bypass mode and passively receives all traffic data packets redirected to it by the traffic redirection device. In this way, packet capture is performed in a non-intrusive manner, which can avoid the problem of the performance of the transmission link being affected by the performance of the packet capture device itself.

[0038] Correspondingly, packet capture devices can acquire traffic data packets during the communication connection process between the client and the server, and parse out traffic data packets containing the session ticket from these traffic data packets. The traffic data packet containing the session ticket is the target data packet.

[0039] A session ticket is a ticket information generated by the server based on the current session. Specifically, when the client and server establish a connection for the first time, the server generates a ticket information, namely a sessionTicket, based on information such as the session identifier, certificate, cipher suite, and master key. The server sends the sessionTicket to the client, which then saves it. When the client initiates another TLS connection establishment request to the server, it will attach the locally stored sessionTicket. Upon receiving the connection establishment request, the server recovers the key information based on the sessionTicket and completes key negotiation without performing asymmetric encryption and decryption, thus saving computational resources.

[0040] The process of establishing a connection between a client and a server includes both initial connection establishment and subsequent connection establishment. Specifically, when a client establishes a connection with a server for the first time, the connection establishment process is as follows:

[0041] (1) The client sends an empty sessionTicket Hello message to the server;

[0042] (2) The server replies to the client with a Hello message indicating that the sessionTicket is empty;

[0043] (3) The client sends a Finished message to the server when the sessionTicket is empty;

[0044] (4) The server replies with a Finished message and attaches a valid sessionTicket.

[0045] During the initial connection establishment process, the packet capture device can obtain the traffic data packets from (1) to (4) above through the traffic redirection device, and obtain the sessionTicket in step (4) from the traffic data packets, and obtain the symmetric key used for subsequent data encryption through the same encryption algorithm as the server.

[0046] Specifically, when the client and server are not establishing a connection for the first time, the connection establishment process is as follows:

[0047] (1) The Hello message sent by the client will include a sessionTicket;

[0048] (2) The server obtains the data encryption key through the sessionTicket in the Hello message and generates a new sessionTicket based on the information of this connection and returns it to the client.

[0049] Similarly, during the process of establishing a connection for the first time, the packet capture device can obtain the traffic data packets from (1) to (2) above through the traffic diversion device, and obtain the sessionTicket in step (2) from the traffic data packets. The symmetric key used for subsequent data encryption is obtained by parsing the data packets using the same encryption algorithm as the server.

[0050] S12, based on the unique identifier information of the dialogue ticket, retrieve the key information corresponding to the dialogue ticket.

[0051] The unique identifier is used to characterize the uniqueness of the session ticket. The unique identifier of the session ticket can be the server's IP address, the server's MAC address, or a combination of the server's IP address and MAC address. Of course, it can also be other identifiers that can characterize the uniqueness of the session ticket, without specific limitations here.

[0052] The key information consists of the encryption and decryption keys used by the server to encrypt the session ticket. The packet capture device needs the decryption key to decrypt the session ticket. When the packet capture device obtains the encrypted session ticket and needs to parse it, it can retrieve the corresponding key information from the location where the key information is stored or from the device itself, based on the unique identifier of the session ticket.

[0053] S13, decrypt the dialogue ticket based on the key information to obtain the message key corresponding to the dialogue ticket.

[0054] The packet capture device and the server can pre-agree to use the same encryption and decryption algorithm. After the packet capture device obtains the encrypted session ticket and its corresponding key information, it can use the agreed encryption and decryption algorithm to decrypt the encrypted session ticket and obtain the message key carried in the session ticket. This message key is the key used by the client and server to encrypt communication data.

[0055] S14: Decrypt the message carried in the target data packet based on the message key to obtain the target plaintext information.

[0056] The packet capture device can use this message key to parse the messages carried in the target data packets generated during the communication between the client and the server, and obtain the plaintext information corresponding to the target data packets.

[0057] Furthermore, the packet capture device can push the decrypted target plaintext information to technicians, allowing them to determine whether the development or debugging of the network application meets the requirements. This push can be sent via email or displayed on the technician's monitor, tablet, or other interactive device; no specific limitation is made here.

[0058] The traffic data packet processing method provided in this embodiment acquires traffic data packets during the connection establishment process between the client and the server, identifies the target data packet including the session ticket, and then retrieves the corresponding key information based on the unique identifier information of the session ticket for decryption to obtain the message information carried by the target data packet. This allows relevant technicians to perform application debugging based on the message information. This method achieves decryption of encrypted data packets without intrusive packet capture, and does not affect the network link between the client and the server, ensuring network link performance and data packet capture security.

[0059] This embodiment provides a method for processing traffic data packets, which can be used in the packet capture device of the traffic data packet processing system described above. The packet capture device can be an electronic device such as a server. Figure 3 This is a flowchart of a traffic data packet processing method according to an embodiment of the present disclosure, such as... Figure 3 As shown, the process includes the following steps:

[0060] S21, Obtain the target data packet. This target data packet is the traffic data packet generated when the client and server establish a connection, and it includes the session ticket between the client and server.

[0061] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0062] S22, based on the unique identifier information of the dialogue ticket, retrieve the key information corresponding to the dialogue ticket.

[0063] Specifically, step S22 above may include:

[0064] S221, Determine whether the key information corresponding to the session ticket is cached locally.

[0065] After decrypting the session ticket using the key information, the packet capture device caches the key information locally. This allows for the subsequent parsing of session tickets encrypted by the same server without needing to retrieve the key information again, thus saving retrieval time and further improving packet capture efficiency.

[0066] When the packet capture device obtains a session ticket, it first checks whether the key information for that session ticket is cached locally. If the key information corresponding to the session ticket is not cached locally, step S223 is executed. Otherwise, the session ticket is decrypted using the cached key information.

[0067] S222, retrieve key information from a preset location based on the unique identifier information. This preset location stores the key used for the encrypted dialogue ticket.

[0068] When the key information corresponding to the session ticket is not cached locally, it means that the packet capture device has not retrieved the key information for that session ticket. In this case, the packet capture device can retrieve the corresponding key information from a preset location based on the unique identifier information. The key information stored in the preset location is indexed by the unique identifier information of the session ticket.

[0069] The preset location can be a key management device connected to the packet capture device, a cloud storage space, or a server-side storage space. There are no specific limitations here, as long as the packet capture device can retrieve the corresponding key information.

[0070] Taking a key management device as an example, this device is deployed on the server side and interconnected with the packet capture device. It can simultaneously provide key management services to multiple server-side devices and packet capture devices, thus decoupling the packet capture device from the server. Figure 4As shown in the diagram. At this point, the traffic redirection device still acts as a node in the communication link between the client and the server, copying and redirecting the traffic data packets generated between the client and the server to the packet capture device. The server sends the key information used by its encrypted session ticket to the key management device, and pushes a change message to the key management device when the server changes its key information. The key management device updates the key information, saves the key information using the server's IP address + MAC address as an index value, and notifies the packet capture device of the key information change. When parsing the session ticket, the packet capture device retrieves the key information of the corresponding encrypted session ticket used by the server from the key management device, and retrieves the updated key information from the key management device when the key information changes, to avoid the packet capture device being unable to decode the session ticket due to key information changes.

[0071] As an optional implementation, the key information of the dialogue ticket is randomly generated based on preset rules and updated after a preset time interval.

[0072] The server and the packet capture device pre-agree on the encryption / decryption algorithm to be used, and generate a session ticket based on the key information and the agreed-upon algorithm. The key information used for the encrypted session ticket can be randomly generated according to preset rules, such as using a cryptographically secure random number generator according to RFC4086. Furthermore, to ensure the security of the session ticket key information, this key information can be changed periodically, i.e., updated every preset time interval. This preset time interval can be set according to actual needs and is not specifically limited here.

[0073] S23, decrypt the dialogue ticket based on the key information to obtain the message key corresponding to the dialogue ticket.

[0074] Specifically, step S23 above may include:

[0075] S231, determine whether the dialogue ticket has been successfully decrypted.

[0076] When decrypting a session ticket using key information, the packet capture device can detect whether the session ticket has been successfully decrypted, i.e., whether plaintext information for the session ticket has been obtained. If the session ticket has been successfully decrypted, step S232 is executed; otherwise, step S233 is executed.

[0077] S232, parse the message key from the dialogue ticket and cache the key information.

[0078] Once the session ticket is successfully decrypted, the packet capture device can obtain the plaintext information of the session ticket and parse it to extract the message key for the encrypted communication data negotiated between the client and the server. Simultaneously, the packet capture device can cache the key information from the successfully decrypted session ticket locally so that it can directly perform decryption operations when receiving the same session ticket again.

[0079] S233, determine whether the decryption count threshold has been reached.

[0080] The decryption threshold is a pre-set maximum number of retries. When decryption of a session ticket fails, the packet capture device can retry the decryption operation using the key information and accumulate the number of retries resulting from the current decryption failure. Each time the packet capture device accumulates a retrieval count, it compares the current retrieval count with the decryption threshold to determine if the threshold has been reached. If the threshold is reached, step S234 is executed; otherwise, other operations are performed. These other operations could be either successful decryption (caching the key information locally) or failed decryption (retrying decryption again). No specific limitations are specified for these other operations.

[0081] S234, cache decryption failed.

[0082] When the decryption attempt threshold is reached, it indicates that the packet capture device has failed to decrypt the dialogue ticket. At this time, the packet capture device can cache the decryption failure status. This decryption failure status indicates that the TCP connection between the client and the server cannot be decrypted, so that technicians can use this information to debug network applications.

[0083] S24, decrypt the message carried in the target data packet based on the message key to obtain the target plaintext information.

[0084] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0085] The traffic data packet processing method provided in this embodiment improves packet capture efficiency by determining whether the local machine contains the key information capable of decrypting the session ticket. If the corresponding key information exists locally, the session ticket can be directly decrypted, thus improving packet capture efficiency. When the corresponding key information is not found locally, it is retrieved from a preset location for decryption of the session ticket, thereby preventing the leakage of the encryption key at the code level and ensuring key security. Simultaneously, this preset location can store and manage keys for the session ticket from multiple servers and packet capture devices, achieving decoupling between the packet capture device and the server. Determining whether the session ticket can be successfully decrypted ensures the security of target data packet decryption. When session ticket decryption fails, its failure status is recorded for subsequent debugging by technical personnel.

[0086] This embodiment provides a method for processing traffic data packets, which can be used in the packet capture device of the traffic data packet processing system described above. The packet capture device can be an electronic device such as a server. Figure 5 This is a flowchart of a traffic data packet processing method according to an embodiment of the present disclosure, such as... Figure 5 As shown, the process includes the following steps:

[0087] S31, Obtain the target data packet.

[0088] The target data packet is the traffic data packet generated when the client and the server establish a connection. The target data packet includes the dialogue ticket between the client and the server.

[0089] Specifically, step S31 above may include:

[0090] S311, Obtain the traffic data packets between the client and the server, including the negotiation data packets.

[0091] The negotiation data packet is the data packet that the client and server negotiate the encryption key to establish a connection; that is, the data packet carrying the negotiation message. Traffic data packets between the client and server include data packets carrying negotiation messages and data packets carrying data messages.

[0092] The traffic redirection device directs the traffic data packets generated in the transmission link between the client and the server to the packet capture device, which in turn can receive the traffic data packets.

[0093] S312 determines whether the traffic data packet is a negotiated data packet.

[0094] The packet capture device parses the header of the received traffic data packets to determine whether they are negotiation data packets. If the traffic data packet is a negotiation data packet, step S313 is executed; otherwise, step S315 is executed.

[0095] S313, determine whether the traffic data packet carries a session ticket.

[0096] When the traffic data packet is a negotiation data packet, the packet capture device further determines whether the negotiation data packet carries a session ticket. If the traffic data packet carries a session ticket, step S314 is executed; if the traffic data packet does not carry a session ticket, it indicates that the negotiation data packet is a connection establishment negotiation process, and the negotiation data packet does not contain valid information. In this case, decryption is not required, and the next traffic data packet can be processed.

[0097] S314, identify the traffic data packet as the target data packet.

[0098] When a traffic data packet carries a negotiation ticket, it indicates that the negotiation data packet contains valid information, and the packet capture device will decrypt the negotiation data packet as the target data packet.

[0099] S315 checks if a key corresponding to the traffic data packet exists locally.

[0100] When a traffic data packet is not a negotiated data packet, it indicates that the traffic data packet carries a data message. In this case, the packet capture device can check whether the corresponding key is cached locally. If the key corresponding to the traffic data packet is cached locally, step S316 is executed; otherwise, no decryption processing is performed, and the next traffic data packet is processed.

[0101] S316, decrypts the message carried by the traffic data packet based on the key.

[0102] When a key corresponding to a traffic data packet exists locally, it means that the packet capture device can decrypt the traffic data packet. At this time, the locally cached key can be used to decrypt the messages in the traffic data packet to obtain the plaintext information of the data messages carried by the traffic data packet.

[0103] Here, if a data packet is detected as not being a negotiated data packet and the corresponding key is cached locally, the data packet is decrypted; otherwise, the data packet does not need to be decrypted locally and is not processed, thereby improving the decryption efficiency of the data packet.

[0104] S32, based on the unique identifier information of the dialogue ticket, retrieve the key information corresponding to the dialogue ticket. For detailed explanation, please refer to the relevant descriptions in the above embodiments, which will not be repeated here.

[0105] S33, decrypt the dialogue ticket based on the key information to obtain the message key corresponding to the dialogue ticket. For detailed explanation, please refer to the relevant descriptions in the above embodiments; they will not be repeated here.

[0106] As an optional implementation, the following may be included before step S33:

[0107] (1) Obtain the pre-configured data filtering rules.

[0108] (2) Based on the data filtering rules, the traffic data packets generated when the client and the server establish a connection are filtered to obtain the filtered traffic data packets.

[0109] (3) Insert the filtered traffic data packets into a preset queue, which is used to store the target data packets to be decrypted.

[0110] Data filtering rules are used to filter traffic data packets acquired by the packet capture device. These rules are pre-configured in the packet capture device by technicians according to actual needs. The packet capture device can invoke these filtering rules when acquiring traffic data packets.

[0111] Specifically, the data filtering rule can be based on domain name, such as filtering out traffic data packets generated for domain name XXX; it can be based on IP address; it can also be based on MAC address; there are no restrictions on the data filtering rule here.

[0112] The packet capture device filters all traffic data packets directed to it by the traffic redirection device according to pre-set data filtering rules, obtaining traffic data packets that meet the filtering rules. Then, the filtered traffic data packets are inserted into a preset queue to await decryption. This preset queue is a first-in, first-out queue used to store traffic data packets to be decrypted.

[0113] By pre-setting data filtering rules, the target data packets to be decrypted can be determined according to the data filtering rules and inserted into a preset queue to wait for decryption processing, thereby realizing the orderly decryption of the target data packets.

[0114] S34, decrypt the message carried in the target data packet based on the message key to obtain the target plaintext information.

[0115] For detailed explanations, please refer to the relevant descriptions corresponding to the above embodiments, which will not be repeated here.

[0116] The data packet processing method provided in this embodiment, since the dialogue ticket is generated during the process of negotiating and establishing a connection between the client and the server, detects whether the data traffic packet is a negotiation data packet in order to identify the negotiation data packet carrying the dialogue ticket from the data traffic packet, thus ensuring the effectiveness of capturing the target data packet, avoiding the decryption of invalid data traffic packets, and thereby improving the data packet capture efficiency.

[0117] This embodiment also provides a traffic data packet processing apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0118] This embodiment provides a device for processing traffic data packets, such as... Figure 6 As shown, it includes:

[0119] The traffic receiving module 41 is used to acquire target data packets, wherein the target data packets are traffic data packets generated when the client and the server establish a connection, and the target data packets include the dialogue ticket between the client and the server.

[0120] The key update module 42 is used to retrieve the key information corresponding to the dialogue ticket based on the unique identifier information of the dialogue ticket.

[0121] The decryption module 43 is used to decrypt the dialogue ticket based on the key information to obtain the message key corresponding to the dialogue ticket, and to decrypt the message carried by the target data packet based on the message key to obtain the target plaintext information.

[0122] Optionally, such as Figure 7 As shown, the aforementioned data packet processing device may further include:

[0123] Configuration module 44 is used to configure data filtering rules.

[0124] The filtering module 45 is connected in communication with the filtering module and is used to filter traffic data packets based on data filtering rules.

[0125] Specifically, a preset queue 46 for storing traffic data packets to be decrypted can be pre-configured in the traffic data packet processing device, and the filtering module 45 can insert the filtered traffic data packets into the preset queue 46.

[0126] Optionally, such as Figure 7 As shown, the aforementioned data packet processing device may further include:

[0127] The interaction module 47 is connected to the decryption module and is used to receive the target plaintext information pushed by the decryption module and display the target plaintext information.

[0128] The storage module 48 is connected in communication with the decryption module and is used to store the target plaintext information pushed by the decryption module.

[0129] Optionally, the key update module 42 described above may include:

[0130] The first judgment submodule is used to determine whether the key information corresponding to the dialogue ticket is cached locally.

[0131] The fetch submodule is used to fetch key information from a preset location based on a unique identifier when the key information corresponding to the session ticket is not cached locally. This preset location stores the key used to encrypt the session ticket.

[0132] The key information of the dialogue ticket is randomly generated based on preset rules and updated after a preset time interval.

[0133] Optionally, the decryption module 43 may include:

[0134] The second judgment submodule is used to determine whether the dialogue ticket has been successfully decrypted.

[0135] The first parsing submodule is used to parse the message key from the dialogue ticket when the dialogue ticket is successfully decrypted, and to cache the key information.

[0136] The third judgment submodule is used to determine whether the decryption count threshold has been reached when the dialogue ticket decryption fails.

[0137] The caching submodule is used to cache decryption failure statuses when the decryption count threshold is reached.

[0138] Optionally, the above-mentioned traffic receiving module 41 may include:

[0139] The first acquisition submodule is used to acquire traffic data packets between the client and the server, including negotiation data packets.

[0140] The fourth judgment submodule is used to determine whether the traffic data packet is a negotiated data packet.

[0141] The fifth judgment submodule is used to determine whether a traffic data packet carries a dialogue ticket when the traffic data packet is a negotiated data packet.

[0142] The determination submodule is used to identify traffic data packets as target data packets when the traffic data packets carry a session ticket.

[0143] Optionally, the decryption module 43 is further configured to: detect whether a key corresponding to the traffic data packet exists locally; and when a key corresponding to the traffic data packet exists locally, decrypt the message carried by the traffic data packet based on the key.

[0144] The traffic data packet processing device provided in this embodiment acquires traffic data packets during the connection establishment process between the client and the server, identifies target data packets including session tickets, and then retrieves the corresponding key information based on the unique identifier information of the session ticket for decryption to obtain the message information carried by the target data packet. This allows relevant technicians to perform application debugging based on the message information. This device achieves decryption of encrypted data packets without intrusive packet capture, and does not affect the network link between the client and the server, ensuring network link performance and data packet capture security.

[0145] In this embodiment, the data packet processing device is presented in the form of a functional unit. Here, a unit refers to an ASIC circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above functions.

[0146] Further functional descriptions of the above modules are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0147] This disclosure also provides an electronic device having... Figure 6 or Figure 7 The device shown is for processing traffic data packets.

[0148] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an electronic device provided in an optional embodiment of this disclosure, such as... Figure 8 As shown, the electronic device may include: at least one processor 501, such as a central processing unit (CPU), at least one communication interface 503, memory 504, and at least one communication bus 502. The communication bus 502 is used to enable communication between these components. The communication interface 503 may include a display screen or a keyboard; optionally, the communication interface 503 may also include a standard wired interface or a wireless interface. The memory 504 may be high-speed volatile random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory 504 may also be at least one storage device located remotely from the aforementioned processor 501. The processor 501 may be combined with... Figure 6 or Figure 7 The described apparatus has an application program stored in memory 504, and a processor 501 calls the program code stored in memory 504 to perform any of the above method steps.

[0149] The communication bus 502 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The communication bus 502 can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0150] The memory 504 may include volatile memory, such as random-access memory (RAM); the memory may also include non-volatile memory, such as flash memory, hard disk drive (HDD) or solid-state drive (SSD); the memory 504 may also include a combination of the above types of memory.

[0151] The processor 501 can be a central processing unit (CPU), a network processor (NP), or a combination of a CPU and an NP.

[0152] The processor 501 may further include a hardware chip. This hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0153] Optionally, the memory 504 is also used to store program instructions. The processor 501 can call the program instructions to implement the traffic data packet processing method shown in the above embodiments of this application.

[0154] This disclosure also provides a non-transitory computer storage medium storing computer-executable instructions that can execute the data packet processing method in any of the above method embodiments. The storage medium may be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium may also include combinations of the above types of memory.

[0155] Although embodiments of the present disclosure have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for processing traffic data packets, characterized in that, include: Traffic data packets are obtained from traffic redirection devices deployed on the transmission link between the client and the server by using packet capture devices deployed in bypass mode; Determine whether the traffic data packet is a negotiated data packet; When the traffic data packet is a negotiated data packet, determine whether the traffic data packet carries a session ticket; When the traffic data packet carries the session ticket, the traffic data packet is identified as the target data packet. The target data packet is the traffic data packet generated when the client and the server establish a connection. The target data packet includes the session ticket between the client and the server. The session ticket is ticket information generated by the server based on the session identifier, certificate, cipher suite and master key information. Based on the unique identifier information of the dialogue ticket in the target data packet, the key information corresponding to the dialogue ticket is retrieved from the key management device deployed separately from the server. The session ticket is decrypted based on the key information to obtain the message key carried by the session ticket; Based on the message key, the message carried by the target data packet is decrypted to obtain the target plaintext information.

2. The method according to claim 1, characterized in that, The step of retrieving key information corresponding to the dialogue ticket based on the unique identifier information of the dialogue ticket includes: Determine whether the key information corresponding to the dialogue ticket is cached locally; When the key information corresponding to the dialogue ticket is not cached locally, the key information is retrieved from a preset location based on the unique identifier information. The preset location stores the key used to encrypt the dialogue ticket.

3. The method according to claim 2, characterized in that, The step of decrypting the session ticket based on the key information to obtain the message key corresponding to the session ticket includes: Determine whether the dialogue ticket has been successfully decrypted; When the dialogue ticket is successfully decrypted, the message key is parsed from the dialogue ticket and the key information is cached.

4. The method according to claim 3, characterized in that, Also includes: When the decryption of the dialogue ticket fails, determine whether the decryption attempt threshold has been reached; When the decryption count threshold is reached, the cache decryption fails.

5. The method according to claim 1, characterized in that, Also includes: When the traffic data packet is not the negotiated data packet, check if a key corresponding to the traffic data packet exists locally; When a key corresponding to the traffic data packet exists locally, the message carried by the traffic data packet is decrypted based on the key.

6. The method according to claim 1, characterized in that, Also includes: Retrieve pre-configured data filtering rules; Based on the data filtering rules, the traffic data packets generated when the client establishes a connection with the server are filtered to obtain the filtered traffic data packets; The filtered traffic data packets are inserted into a preset queue, which is used to store traffic data packets to be decrypted.

7. The method according to claim 1, characterized in that, The key information of the dialogue ticket is randomly generated based on preset rules and updated after a preset time interval.

8. A device for processing traffic data packets, characterized in that, include: The traffic receiving module is used to acquire traffic data packets from a traffic redirection device deployed on the transmission link between the client and the server through a packet capture device deployed in bypass mode; determine whether the traffic data packet is a negotiation data packet; when the traffic data packet is a negotiation data packet, determine whether the traffic data packet carries a session ticket; when the traffic data packet carries the session ticket, identify the traffic data packet as the target data packet, the target data packet is the traffic data packet generated when the client and the server establish a connection, the target data packet includes the session ticket between the client and the server, the session ticket is ticket information generated by the server based on the session identifier, certificate, cipher suite and master key information; The key update module is used to retrieve the key information corresponding to the dialogue ticket from the key management device deployed separately from the server, based on the unique identification information of the dialogue ticket in the target data packet. The decryption module is used to decrypt the dialogue ticket based on the key information to obtain the message key corresponding to the dialogue ticket; Based on the message key, the message carried by the target data packet is decrypted to obtain the target plaintext information.

9. The apparatus according to claim 8, characterized in that, Also includes: The configuration module is used to configure data filtering rules; A filtering module, communicatively connected to the filtering module, is used to filter the traffic data packets based on the data filtering rules.

10. The apparatus according to claim 8, characterized in that, Also includes: An interaction module, which is communicatively connected to the decryption module, is used to receive the target plaintext information pushed by the decryption module and display the target plaintext information; The storage module is communicatively connected to the decryption module and is used to store the target plaintext information pushed by the decryption module.

11. A system for processing traffic data packets, characterized in that, include: Client and server; A traffic redirection device is deployed on the transmission link between the client and the server to capture traffic data packets generated when a connection is established between the client and the server. A key management device, which is communicatively connected to the server, is used to manage the key information of the server's encrypted dialogue tickets; A packet capture device, deployed in bypass mode, is communicatively connected to the traffic redirection device and the key management device, and is used to execute the traffic data packet processing method according to any one of claims 1-7.

12. An electronic device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the computer instructions to perform the data packet processing method according to any one of claims 1-7.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing a computer to perform the data packet processing method according to any one of claims 1-7.

Images