Data transmission method, apparatus, transmission node, and storage medium

Abstract

This invention provides a data transmission method, apparatus, transmission node, and storage medium, applied to a virtual service configured in a target transmission node. The method includes: receiving a TCP connection request packet sent by a client to a server to establish a TCP connection with the client; if the first TCP data packet received from the client based on the TCP connection is a target SSL handshake packet, then completing an SSL handshake based on the TCP connection; the target SSL handshake packet is the first handshake packet in the SSL handshake process; decrypting the SSL data packet sent by the client after completing the SSL handshake to perform security checks on the plaintext corresponding to the SSL data packet; if the plaintext passes the security check, then sending the ciphertext obtained by encrypting the plaintext to the server. By determining whether the first TCP data packet is a target SSL handshake packet, all SSL data packets can be monitored and security checks performed, ensuring communication security.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a data transmission method, apparatus, transmission node, and storage medium. Background Technology

[0002] In the field of information security, for clients and servers that use Secure Sockets Layer (SSL) to encrypt and transmit data during communication, in order to ensure the security of communication between the client and the server, some transmission nodes are usually configured between the client and the server. These transmission nodes are used to listen for SSL data packets transmitted between the client and the server.

[0003] Generally, the transmission node is configured according to the SSL data packet listening port corresponding to the server. For example, if the SSL data packet listening port corresponding to the server is 443, the transmission node is configured to listen on port 443, thereby enabling the listening of packets destined for port 443.

[0004] However, in practical applications, the SSL datagram listening ports for different servers accessed by the client may be different, and even the SSL datagram listening ports for the same server may change. Therefore, configuring and maintaining transport nodes presents challenges, including difficulties and incomplete configurations, which can lead to some SSL datagrams bypassing the listening port, posing a security risk. Summary of the Invention

[0005] This invention provides a data transmission method, apparatus, transmission node, and storage medium for identifying SSL data packets and performing security monitoring on all SSL data packets to ensure secure communication between the client and the server.

[0006] In a first aspect, embodiments of the present invention provide a data transmission method applied to a virtual service configured in a target transmission node, wherein the target transmission node is located between a client and a server to which the client intends to transmit data, the method comprising:

[0007] Receive the TCP connection request packet sent by the client to the server in order to establish a TCP connection with the client;

[0008] If the first TCP data packet sent by the client and received based on the TCP connection is a target SSL handshake packet, then the SSL handshake is completed based on the TCP connection; wherein, the target SSL handshake packet is the first handshake packet in the SSL handshake process;

[0009] Decrypt the SSL data packet sent by the client after completing the SSL handshake, so as to perform security detection on the plaintext corresponding to the SSL data packet;

[0010] If the plaintext passes the security check, the ciphertext obtained by encrypting the plaintext is sent to the server.

[0011] Secondly, embodiments of the present invention provide a data transmission apparatus applied to a virtual service configured in a target transmission node, wherein the target transmission node is located between a client and a server to which the client intends to transmit data, the apparatus comprising:

[0012] The receiving module is used to receive the TCP connection request packet sent by the client to the server, so as to establish a TCP connection with the client;

[0013] The processing module is configured to complete an SSL handshake based on the TCP connection if the first TCP data packet received from the client based on the TCP connection is a target SSL handshake packet; wherein the target SSL handshake packet is the first handshake packet in the SSL handshake process.

[0014] The security detection module is used to decrypt the SSL data packets sent by the client after completing the SSL handshake, so as to perform security detection on the plaintext corresponding to the SSL data packets;

[0015] The sending module is used to send the ciphertext obtained by encrypting the plaintext to the server if the plaintext passes the security test.

[0016] Thirdly, embodiments of the present invention provide a transmission node, including: a memory, a processor, and a communication interface; wherein, the memory stores executable code, and when the executable code is executed by the processor, the processor can at least implement the data transmission method as described in the first aspect.

[0017] Fourthly, embodiments of the present invention provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the data transmission method as described in the first aspect.

[0018] In the solution provided by this embodiment of the invention, to ensure the communication security between the client and the server, a target transmission node is set up between the client and the server that are transmitting data. This target node is configured with a virtual service. When the client wants to transmit data with the server, firstly, the virtual service in the target transmission node receives the TCP connection request packet sent by the client to the server and establishes a TCP connection with the client. Then, by determining whether the first TCP data packet sent by the client is a target SSL handshake packet, it is determined whether subsequent TCP data packets transmitted by the client based on the TCP connection are SSL data packets. The target SSL handshake packet is the first handshake packet in the SSL handshake process. If the first TCP data packet received from the client based on the TCP connection is the target SSL handshake packet, it indicates that after completing the SSL handshake with the client based on the TCP connection, all data packets transmitted by the client based on the TCP connection are SSL data packets. Then, the SSL data packets sent by the client after completing the SSL handshake are decrypted to perform security checks on the plaintext corresponding to the SSL data packets; if the plaintext passes the security check, the ciphertext obtained by encrypting the plaintext is sent to the server. In this solution, security checks on all SSL data packets passing through the target transmission node are achieved by determining whether the first TCP data packet sent by the client is the first handshake packet in the SSL handshake process. Attached Figure Description

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

[0020] Figure 1 A schematic diagram of a data transmission system provided in an embodiment of the present invention;

[0021] Figure 2 An interactive flowchart of a data transmission method provided in an embodiment of the present invention;

[0022] Figure 3 An interactive flowchart of a data transmission method provided in another embodiment of the present invention;

[0023] Figure 4 A schematic diagram of another data transmission system provided in an embodiment of the present invention;

[0024] Figure 5 This is a schematic diagram of the structure of a data transmission device provided in an embodiment of the present invention;

[0025] Figure 6 To and Figure 5 The illustrated embodiment provides a schematic diagram of the structure of the transmission node corresponding to the data transmission device. Detailed Implementation

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

[0027] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this invention. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the invention as detailed in the appended claims.

[0028] Furthermore, the timing of the steps in the following method embodiments is merely an example and not a strict limitation.

[0029] The Hypertext Transfer Protocol (HTTP) is a simple request-response protocol that runs on top of the Transmission Control Protocol (TCP). It specifies what messages a client might send to a server and what responses it might receive. Because in standard HTTP, the client and server exchange data in plaintext directly via a TCP connection, HTTP is unsuitable for transmitting sensitive information such as credit card numbers, passwords, and other payment information.

[0030] To ensure secure transmission of sensitive data, the Secure Sockets Layer (SSL) protocol was designed to encrypt data transmitted via HTTP, commonly known as HTTPS. Simply put, HTTPS is a network protocol built upon SSL and HTTP, enabling encrypted transmission and authentication. SSL runs on top of TCP.

[0031] When the client and server transmit encrypted data via the HTTPS protocol, firstly, the client and server establish a TCP connection through a three-way TCP handshake. Then, based on this TCP connection, a four-way SSL handshake is completed between the client and server. After the SSL handshake is completed, the client and server begin encrypted data transmission. The specific processes of the TCP and SSL handshakes can be found in relevant technologies and will not be elaborated upon in this embodiment.

[0032] In fact, all messages transmitted over a TCP connection can be considered TCP data packets. In this embodiment, for ease of explanation, TCP data packets for HTTPS encrypted data transmission are further divided into SSL handshake messages and SSL data packets. The SSL handshake message corresponds to the four SSL handshake steps, while the SSL data packet is the encrypted data packet transmitted after the SSL handshake is completed.

[0033] In related technologies, to ensure secure communication between clients and servers using HTTPS for data transmission, SSL data packets are typically monitored. Generally, this is achieved by a transport node located between the client and server listening on a specific port on the server. For example, since the default port number for HTTPS is 443, the transport node listens on port 443, monitoring all TCP data packets destined for port 443. However, this method has two drawbacks. First, SSL data packets destined for ports other than 443 can bypass the monitoring. Second, because server ports can be reconfigured, if the server's port 443 does not correspond to the HTTPS protocol, it may incorrectly monitor some non-SSL data packets destined for port 443, such as TCP data packets transmitted using the HTTP protocol.

[0034] To address this, embodiments of the present invention provide a data transmission method that, by determining whether the data packets transmitted by the client and the server are SSL data packets, enables the monitoring and security detection of all SSL data packets.

[0035] Figure 1 This is a schematic diagram of a data transmission system provided in an embodiment of the present invention. Figure 1 As shown, the data transmission system includes a client, a server, and a target transmission node.

[0036] Understandably, in practical applications, several transmission nodes may be set up between clients and servers to transmit data. In this embodiment, the target transmission node refers to the transmission node that performs security checks on the SSL data packets transmitted between the client and the server. The target transmission node is configured with a virtual service. Data sent by the client to the server is transmitted to the server via the virtual service in the target transmission node, and the security checks on the SSL data packets are completed based on this virtual service.

[0037] Figure 2 This is an interactive flowchart illustrating a data transmission method provided in an embodiment of the present invention. In this embodiment, the description is from the perspective of a virtual service configured in the target transmission node, such as... Figure 2 As shown, the method includes the following steps:

[0038] 201. Receive the TCP connection request packet sent by the client to the server in order to establish a TCP connection with the client.

[0039] 202. If the first TCP datagram sent by the client received over the TCP connection is the target SSL handshake message, then the SSL handshake is completed over the TCP connection.

[0040] The target SSL handshake message is the first handshake message in the SSL handshake process.

[0041] 203. Decrypt the SSL data packets sent by the client after completing the SSL handshake to perform security checks on the plaintext corresponding to the SSL data packets.

[0042] 204. If the plaintext corresponding to the SSL datagram passes the security check, the ciphertext obtained by encrypting the plaintext will be sent to the server.

[0043] In this embodiment, the virtual service configured in the target transmission node can act as a proxy server to establish a TCP connection with the client.

[0044] In practical applications, users can set the IP address and port of the virtual service to the target state, such as IP address 0 and port 0, so that the virtual service is in a state that can receive TCP connection request packets sent by the client.

[0045] In step 201, the client sends a TCP connection request packet, which is the first data packet in the three-way TCP handshake, also known as the SYN packet. After receiving the SYN packet, the client continues the TCP handshake to establish a TCP connection. Subsequently, all data transmission between the client and the virtual service is based on this TCP connection.

[0046] In practice, if the client and server transmit encrypted data using the HTTPS protocol, the first TCP datagram sent by the client after establishing the TCP connection is the first handshake message in the SSL handshake process, i.e., the SSL client hello message. Furthermore, all TCP datagrams transmitted after the SSL handshake is completed are SSL datagrams. Therefore, in this embodiment, the problem of determining the SSL datagram is transformed into determining whether the first TCP datagram is the first handshake message in the SSL handshake process (i.e., the target SSL handshake message).

[0047] In practice, based on the TCP connection, if the first TCP datagram sent by the receiving client is a target SSL handshake message, it indicates that the client and server are transmitting encrypted data using the HTTPS protocol, requiring SSL datagram security checks. Therefore, after completing the SSL handshake, subsequent TCP datagrams sent by the client, i.e., SSL datagrams, undergo security checks.

[0048] If the first TCP datagram is not the target SSL handshake message, it indicates that the data transmission between the client and the server is not based on the HTTPS protocol, and subsequent TCP datagrams sent by the client are also not SSL datagrams, and will not be subject to security checks in this virtual service. Optionally, if the first TCP datagram is not the target SSL handshake message, then subsequent TCP datagrams are allowed to be transmitted.

[0049] Optionally, if the target byte value in the first TCP data packet is a preset byte value, then the first TCP data packet is determined to be the target SSL handshake packet, wherein the preset byte value matches the first handshake packet of the SSL handshake, namely the SSLclient hello packet.

[0050] In practical applications, preset byte values ​​can be set based on the message characteristics of the SSL client hello message to parse the first TCP datagram. For example, for the first TCP datagram, check if its first byte value is the preset byte value 0x16. If not, it is not an SSL client hello message. If it is, then check if the subsequent byte values ​​are preset byte values ​​in sequence. For example, check if the second and third byte values ​​are between SSL3.0 (0x0300) and TLS1.3 (0x0304), if the fourth and fifth byte values ​​are the total TCP data length minus 5, if the sixth byte value is 0x01, if the seventh to ninth byte values ​​are the total TCP data length minus 9, and if the tenth and eleventh byte values ​​are between SSL3.0 (0x0300) and TLS1.2 (0x0303). If the result of any of these checks is negative, then the first TCP datagram is not an SSL client hello message. If all eleven bytes of the first TCP datagram are preset byte values, then the first TCP datagram is determined to be an SSL client hello message.

[0051] If the first TCP datagram is an SSL client hello message, then the SSL handshake is completed based on the TCP connection, and the client receives the SSL datagram sent after completing the SSL handshake.

[0052] Since SSL datagrams are actually encrypted, the received SSL datagrams must be decrypted before security checks are performed to obtain the plaintext corresponding to the SSL datagrams. Then, security checks are performed on the plaintext corresponding to the SSL datagrams. If the plaintext passes the security check, the ciphertext obtained by encrypting the plaintext is sent to the server.

[0053] In practice, the virtual service proxy for the aforementioned client encrypts the plaintext to obtain the corresponding ciphertext, encapsulates the ciphertext, and sends it to the server. The destination port, source IP address, and destination IP address of the encapsulated ciphertext are identical to those of the SSL datagram.

[0054] When encapsulating the above ciphertext, optionally, the destination port of the TCP connection request packet can be used to encapsulate the ciphertext, keeping the source IP address and destination IP address unchanged before sending it to the server.

[0055] In this embodiment, for any data transmission between the client and the server, it is determined whether the transmitted TCP data packet is an SSL data packet. Therefore, it is possible to perform security detection on all SSL data packets and ensure the communication security between the client and the server.

[0056] However, in practical applications, parsing all TCP data packets to determine if they are SSL data packets can lead to significant performance overhead for virtual services on the target transmission node. To address this issue, a method is provided... Figure 3 The data transmission method shown.

[0057] Figure 3 An interactive flowchart of another data transmission method provided in an embodiment of the present invention is shown below. Figure 3 As shown, the method applies to a virtual service configured in a target transmission node, which pre-stores SSL data packet transmission records. The method includes the following steps:

[0058] 301. Receive the TCP connection request packet sent by the client to the server.

[0059] 302. If the pre-stored SSL data packet transmission record contains the destination IP address and destination port corresponding to the TCP connection request packet, then establish a TCP connection with the client and complete the SSL handshake based on the TCP connection.

[0060] 303. If the pre-stored SSL data packet transmission record does not contain the destination IP address and destination port corresponding to the TCP connection request packet, then establish a TCP connection with the client and determine whether the first TCP data packet sent by the client based on the TCP connection is the target SSL handshake packet.

[0061] The target SSL handshake message is the first handshake message in the SSL handshake process.

[0062] 304. If the first TCP datagram sent by the client received over the TCP connection is the target SSL handshake message, then the SSL handshake is completed over the TCP connection.

[0063] 305. Decrypt the SSL data packets sent by the client after completing the SSL handshake to perform security checks on the plaintext corresponding to the SSL data packets.

[0064] 306. If the plaintext corresponding to the SSL datagram passes the security check, the ciphertext obtained by encrypting the plaintext will be sent to the server.

[0065] The specific implementation process of steps 301 and 304 to 306 can be referred to the aforementioned embodiments, and will not be repeated in this embodiment.

[0066] In this embodiment, to reduce the performance overhead of parsing whether all TCP data packets are SSL data packets, an SSL data packet transmission record is cached in the virtual service. This SSL data packet transmission record contains the IP address and corresponding port of the server that transmitted SSL data packets.

[0067] Optionally, SSL datagram transmission records are collected by the user and stored in the virtual service's cache; or, the virtual service records the IP address and port of the server corresponding to the SSL datagram based on the results of historically parsing whether TCP datagrams are SSL datagrams, in order to generate SSL datagram transmission records; or, the virtual service updates the SSL datagram transmission records collected by the user and stored in the virtual service's cache based on the results of historically parsing whether TCP datagrams are SSL datagrams.

[0068] It is understandable that, for the same client and server, if data encryption is to be transmitted based on HTTPS, the TCP connection request packet, the first TCP datagram, and the SSL datagram sent by the client actually correspond to the same destination port and destination IP.

[0069] Based on this, after receiving the TCP connection request packet sent by the client, it can be first determined whether the destination port and destination IP address corresponding to the TCP connection packet match the record in the SSL data packet transmission record. That is, the pre-stored SSL data packet transmission record contains the destination IP address and destination port corresponding to the TCP connection request packet.

[0070] If a match is found, it indicates that the client and server are transmitting encrypted data using the HTTPS protocol. The server continues to establish a TCP connection with the client and completes the SSL handshake based on that TCP connection. If a match is not found, a TCP connection is established with the client, and it is determined whether the first TCP datagram received from the client via that TCP connection is the target SSL handshake message.

[0071] Understandably, compared to parsing the first TCP datagram to determine if it is the target SSL handshake message, determining whether the SSL datagram transmission record contains the destination port and destination IP address of the TCP connection request packet results in less performance overhead, higher processing efficiency, and less communication latency between the client and server.

[0072] In the aforementioned embodiments, the virtual service in the target transmission node implements multiple functions, including: a proxy server, a proxy client, and security detection. In practical applications, these functions can be decoupled and implemented through different devices to improve processing efficiency.

[0073] Figure 4 This is a schematic diagram of another data transmission system provided in an embodiment of the present invention. Figure 4 As shown, optionally, the target transmission node includes two load balancing devices and several security detection devices. Specifically, based on the data transmission direction from client to server, the load balancing device closer to the client is called the inbound device, which has a virtual service configured to proxy the server; the load balancing device closer to the server is called the outbound device, which also has a virtual service configured to proxy the client. Several security devices are used to perform security checks on the plaintext corresponding to the SSL data packets.

[0074] Because the data transmission method in this solution actually detects and judges packets, and after determining that a packet is an SSL data packet, it listens to and performs security checks on it, rather than listening to a specific port. Based on the method provided by this embodiment of the invention, it is possible to listen to any port transmitting SSL data packets. Therefore, in practical applications, there can be more than one server, and the ports corresponding to the HTTPS protocol set by each server can be different. For example, server 1 sets the HTTPS protocol to port 443, server 2 sets the HTTPS protocol to port 444, server 3 sets the HTTPS protocol to port 445, ..., server n sets the HTTPS protocol to port 8443, etc. Compared with related technologies, this solution does not have the problem of partially bypassing the listening for SSL data, nor does it incorrectly listen to non-SSL data packets.

[0075] In summary, the data transmission process in this implementation includes: the virtual service in the inbound device establishes a TCP connection with the client to determine whether the TCP data packet sent by the client is an SSL data packet; if so, the SSL handshake is completed, and the received SSL data packet is decrypted and sent to different security devices for detection through a load balancing algorithm; after the security devices have completed their detection, the plaintext is sent to the outbound device, and the virtual service of the outbound device re-encrypts the plaintext and sends the ciphertext to the server.

[0076] The process of the virtual service proxy server in the inbound device establishing a TCP connection with the client and determining whether the TCP data packet sent by the client is an SSL data packet, and the process of the virtual service proxy client in the outbound device sending the plaintext corresponding to the SSL data packet that has passed the security check to the server, can be referred to the aforementioned embodiments, and will not be repeated in this embodiment.

[0077] It's worth noting that if the virtual service in the inbound device pre-stores SSL datagram transmission records, and these records contain the destination port and destination IP address of the TCP connection request packet, then the virtual service in the inbound device must not only send the plaintext corresponding to the decrypted SSL datagram to the security device for security testing, but also send the destination port P1 corresponding to the TCP connection request packet to the outbound device. This allows the virtual service in the outbound device to encapsulate the plaintext into ciphertext using destination port P1. When the SSL datagram is transmitted in plaintext between the inbound device, security device, and outbound device, the source IP address and destination IP address remain unchanged.

[0078] The data transmission apparatus of one or more embodiments of the present invention will be described in detail below. Those skilled in the art will understand that these apparatuses can be configured using commercially available hardware components through the steps taught in this invention.

[0079] Figure 5 This is a schematic diagram of a data transmission device provided in an embodiment of the present invention. The device is applied to a virtual service configured in a target transmission node, which is located between the client and the server on which the client needs to transmit data. Figure 5 As shown, the device includes: a receiving module 11, a processing module 12, a security detection module 13, and a transmitting module 14.

[0080] The receiving module 11 is used to receive the TCP connection request packet sent by the client to the server in order to establish a TCP connection with the client.

[0081] The processing module 12 is configured to complete an SSL handshake based on the TCP connection if the first TCP data packet sent by the client received based on the TCP connection is a target SSL handshake packet; wherein the target SSL handshake packet is the first handshake packet in the SSL handshake process.

[0082] The security detection module 13 is used to decrypt the SSL data packet sent by the client after completing the SSL handshake, so as to perform security detection on the plaintext corresponding to the SSL data packet.

[0083] The sending module 14 is used to send the ciphertext obtained by encrypting the plaintext to the server if the plaintext passes the security test.

[0084] Optionally, the virtual service may pre-store SSL data packet transmission records.

[0085] The processing module 12 is further configured to: if the SSL data packet transmission record contains the destination IP address and destination port corresponding to the TCP connection request packet, establish a TCP connection with the client and complete an SSL handshake based on the TCP connection; if the SSL data packet transmission record does not contain the destination IP address and destination port corresponding to the TCP connection request packet, establish a TCP connection with the client and determine whether the first TCP data packet sent by the client and received based on the TCP connection is a target SSL handshake packet.

[0086] Optionally, the processing module 12 is further configured to add the destination IP address and the destination port to the SSL data packet transmission record.

[0087] Optionally, the processing module 12 is specifically configured to determine the first TCP data packet as a target SSL handshake packet if the target byte value in the first TCP data packet is a preset byte value, wherein the preset byte value matches the first handshake packet.

[0088] Optionally, the sending module 14 is specifically used to encrypt the plaintext to obtain the corresponding ciphertext; encapsulate the ciphertext to send it to the server, wherein the destination port, source IP address and destination IP address of the encapsulated ciphertext are consistent with the destination port, source IP address and destination IP address of the SSL datagram.

[0089] Optionally, the IP address and port of the virtual service are in a target state to enable the virtual service to receive the TCP connection request packets.

[0090] Figure 5 The device shown can perform the steps described in the foregoing embodiments. For detailed execution process and technical effects, please refer to the description in the foregoing embodiments, which will not be repeated here.

[0091] In one possible design, the above Figure 5 The structure of the data transmission device shown can be implemented as a transmission node, such as... Figure 6 As shown, the transmission node may include: a memory 21, a processor 22, and a communication interface 23. The memory 21 stores executable code, which, when executed by the processor 22, enables the processor 22 to at least implement the data transmission method provided in the foregoing embodiments.

[0092] In addition, embodiments of the present invention provide a non-transitory machine-readable storage medium storing executable code, which, when executed by a processor of an electronic device, enables the processor to at least implement the data transmission method provided in the foregoing embodiments.

[0093] The device embodiments described above are merely illustrative, and the units described as separate components may or may not be physically separate. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0094] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of a necessary general-purpose hardware platform, or by a combination of hardware and software. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a computer product. The present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0095] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A data transmission method, characterized in that, A virtual service configured in a target transmission node, the target transmission node being located between a client and a server from which data is to be transmitted, the method comprising: Receive the TCP connection request packet sent by the client to the server in order to establish a TCP connection with the client; By determining whether the first TCP datagram sent by the client and received through the TCP connection is the first handshake message in the SSL handshake process, it is determined whether subsequent TCP datagrams sent by the client to the server through the TCP connection are SSL datagrams that require security checks in the virtual service or TCP datagrams that do not require security checks in the virtual service. Specifically, if the first TCP datagram sent by the client and received through the TCP connection is the first handshake message in the SSL handshake process, then it is determined that subsequent TCP datagrams sent by the client to the server through the TCP connection are SSL datagrams that require security checks in the virtual service; otherwise, it is determined that subsequent TCP datagrams sent by the client to the server through the TCP connection are TCP datagrams that do not require security checks in the virtual service. If the TCP data packets subsequently sent by the client to the server through the TCP connection are SSL data packets that require security checks in the virtual service, then an SSL handshake is completed based on the TCP connection; the SSL data packets sent by the client after completing the SSL handshake are decrypted to perform security checks on the plaintext corresponding to the SSL data packets; if the plaintext passes the security check, the ciphertext obtained by encrypting the plaintext is sent to the server.

2. The method of claim 1, wherein, The virtual service pre-stores SSL data packet transmission records. After receiving the TCP connection request packet sent by the client to the server, the method further includes: If the SSL data packet transmission record contains the destination IP address and destination port corresponding to the TCP connection request packet, then a TCP connection is established with the client, and an SSL handshake is completed based on the TCP connection; If the SSL datagram transmission record does not contain the destination IP address and destination port corresponding to the TCP connection request packet, a TCP connection is established with the client. By determining whether the first TCP datagram sent by the client based on the TCP connection is the first handshake message in the SSL handshake process, it is determined whether the TCP datagrams subsequently sent by the client to the server through the TCP connection are SSL datagrams that need to be security checked in the virtual service or TCP datagrams that do not need to be security checked in the virtual service.

3. The method of claim 2, wherein, After determining that the first TCP datagram is the first handshake packet in the SSL handshake process, the method further includes: Add the destination IP address and the destination port to the SSL data packet transmission record.

4. The method of claim 1, wherein, Determining that the first TCP data packet is the first handshake packet in the SSL handshake process includes: If the target byte value in the first TCP data packet is a preset byte value, then the first TCP data packet is determined to be the first handshake packet in the SSL handshake process, wherein the preset byte value matches the first handshake packet.

5. The method of claim 1, wherein, Sending the ciphertext obtained by encrypting the plaintext to the server includes: The plaintext is encrypted to obtain the corresponding ciphertext; The ciphertext is encapsulated and sent to the server. The destination port, source IP address, and destination IP address of the encapsulated ciphertext are the same as those of the SSL datagram.

6. The method of claim 1, wherein, The IP address and port of the virtual service are in a target state so that the virtual service is in a state where it can receive the TCP connection request packet.

7. A data transmission apparatus, characterized by comprising: A virtual service configured in a target transmission node, the target transmission node being located between a client and a server from which data is to be transmitted, the apparatus comprising: The receiving module is used to receive the TCP connection request packet sent by the client to the server, so as to establish a TCP connection with the client; The processing module is configured to determine whether subsequent TCP data packets sent by the client through the TCP connection are SSL data packets requiring security checks in the virtual service or not, by judging whether the first TCP data packet received from the client based on the TCP connection is the first handshake packet in the SSL handshake process. Specifically, if the first TCP data packet received from the client based on the TCP connection is the first handshake packet in the SSL handshake process, then it is determined that subsequent TCP data packets sent by the client through the TCP connection are SSL data packets requiring security checks in the virtual service; otherwise, it is determined that subsequent TCP data packets sent by the client through the TCP connection are TCP data packets not requiring security checks in the virtual service. If subsequent TCP data packets sent by the client through the TCP connection are SSL data packets requiring security checks in the virtual service, then the SSL handshake is completed based on the TCP connection. The security detection module is used to decrypt the SSL data packets sent by the client after completing the SSL handshake, so as to perform security detection on the plaintext corresponding to the SSL data packets; The sending module is used to send the ciphertext obtained by encrypting the plaintext to the server if the plaintext passes the security test.

8. The apparatus according to claim 7, characterized in that, The virtual service pre-stores SSL data packet transmission records. The processing module is also used to establish a TCP connection with the client and complete the SSL handshake based on the TCP connection if the SSL data packet transmission record contains the destination IP address and destination port corresponding to the TCP connection request packet. If the SSL datagram transmission record does not contain the destination IP address and destination port corresponding to the TCP connection request packet, a TCP connection is established with the client. By determining whether the first TCP datagram sent by the client based on the TCP connection is the first handshake message in the SSL handshake process, it is determined whether the TCP datagrams subsequently sent by the client to the server through the TCP connection are SSL datagrams that need to be security checked in the virtual service or TCP datagrams that do not need to be security checked in the virtual service.

9. A transmission node, characterized in that, include: The system includes a memory, a processor, and a communication interface; wherein the memory stores executable code, and when the executable code is executed by the processor, the processor performs the data transmission method as described in any one of claims 1 to 6.

10. A non-transitory machine-readable storage medium, characterized in that, The non-transitory machine-readable storage medium stores executable code that, when executed by a processor of an electronic device, causes the processor to perform the data transmission method as described in any one of claims 1 to 6.

Images