CN111628976B - 一种报文处理方法、装置、设备及介质 - Google Patents
一种报文处理方法、装置、设备及介质 Download PDFInfo
- Publication number
- CN111628976B CN111628976B CN202010411052.3A CN202010411052A CN111628976B CN 111628976 B CN111628976 B CN 111628976B CN 202010411052 A CN202010411052 A CN 202010411052A CN 111628976 B CN111628976 B CN 111628976B
- Authority
- CN
- China
- Prior art keywords
- data
- server
- client
- message
- verification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
- H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
- H04L69/162—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields involving adaptations of sockets based mechanisms
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
- H04L9/0869—Generation of secret information including derivation or calculation of cryptographic keys or passwords involving random numbers or seeds
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Hardware Design (AREA)
- Computing Systems (AREA)
- General Engineering & Computer Science (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本申请公开了一种报文处理方法、装置、设备及介质，应用于网络安全技术领域，用以解决使用用户态TCP协议栈处理加密数据报文时存在资源消耗大、处理效率低的问题。具体为：接收第一加密数据报文，利用与发送端协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据；确定明文数据的内容审计通过时，利用与接收端协商的数据传输密钥，对明文数据进行加密，得到第二加密数据；基于第二加密数据的数据长度获得可靠传输参数；将第二加密数据和可靠传输参数封装为第二加密数据报文发送至接收端，从而在网络中间设备无需使用用户态TCP协议栈的情况下，实现了对加密数据报文的处理，进而降低了资源消耗，提高了处理效率。
Description
技术领域
本申请涉及网络安全技术领域，尤其涉及一种报文处理方法、装置、设备及介质。
背景技术
在通信网络中，安全套接层(Secure Sockets Layer，SSL)加密流量占比变得越来越大，而防火墙等网络中间设备，通常需要对SSL加密流量进行内容检测，以识别出敏感数据。
目前，为了能够对SSL加密流量进行内容检测，防火墙等网络中间设备通常采用中间人方式，分别与客户端和服务器建立传输控制协议(Transmission Control Protocol，TCP)连接和SSL连接，从而实现对SSL加密流量的解密还原、内容检测、再加密和转发等操作。
实际应用中，由于防火墙等网络中间设备通常会接入很大流量，因此，出于性能考虑，防火墙等网络中间设备不会通过内核收发加密数据报文，而是通过用户态直接从网卡接收加密数据报文，并对接收到的加密数据报文进行解密还原、内容检测、再加密等操作后进行转发，这种通过用户态的TCP协议栈处理加密数据报文的方式，由于用户态的TCP协议栈的实现机制较为复杂，网络中间设备在处理SSL加密流量时，不仅需要消耗大量内存和中央处理器(Central Processing Unit，CPU)等资源，而且，加密数据报文的处理效率较低。
发明内容
本申请实施例提供了一种报文处理方法、装置、设备及介质，用以解决现有技术中的通过用户态的TCP协议栈处理加密数据报文时存在资源消耗较大、处理效率较低的问题。
本申请实施例提供的技术方案如下：
一方面，本申请实施例提供了一种报文处理方法，包括：
通过透传TCP三次握手报文使客户端与服务器建立TCP连接，并基于TCP连接，分别与客户端和服务器建立SSL连接；
接收第一加密数据报文，其中，第一加密数据报文的发送端为客户端和服务器中的一个，接收端为客户端和服务器中的另一个；
利用与发送端建立SSL连接时协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据；
对明文数据进行内容审计，并确定明文数据的内容审计通过的情况下，利用与接收端建立SSL连接时协商的数据传输密钥，对明文数据进行加密，得到第二加密数据；
基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数；
将第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至接收端。
在一种可能的实施方式中，通过透传TCP三次握手报文使客户端与服务器建立TCP连接，包括：
接收客户端向服务器发送的TCP连接请求报文，基于TCP连接请求报文中的五元组，建立TCP流表，将TCP连接请求报文中的序号和确认号记录至TCP流表，并将TCP连接请求报文透传至服务器；
接收服务器向客户端发送的TCP连接请求确认报文，将TCP连接请求确认报文中的序号和确认号记录至TCP流表，并将TCP连接请求确认报文透传至客户端；
接收客户端向服务器发送的TCP连接确认报文，将TCP连接确认报文中的序号和确认号记录至TCP流表，并将TCP连接确认报文透传至服务器；
确定客户端与服务器之间的TCP连接建立完成。
在一种可能的实施方式中，基于TCP连接，分别与客户端和服务器建立SSL连接，包括：
接收客户端向服务器发送的客户端握手报文，并创建接受协程和连接协程；
通过接受协程模拟服务器与客户端建立SSL连接，并通过连接协程模拟客户端与服务器建立SSL连接。
在一种可能的实施方式中，通过接受协程模拟服务器与客户端建立SSL连接，包括通过接受协程模拟服务器执行以下操作：
从客户端握手报文中，获取客户端支持的各个加密算法以及客户端生成的第一随机数，并从客户端支持的各个加密算法中，选取一个加密算法作为第一加密算法；
生成第二随机数，并基于第一加密算法、第二随机数和网络中间设备的私有证书，生成服务器握手数据；
基于服务器握手数据的长度和客户端握手报文中的可靠传输参数，重新获得可靠传输参数；
将服务器握手数据和重新获得的可靠传输参数封装为服务器握手报文发送至客户端；
接收客户端返回的客户端验证报文，其中，客户端验证报文是，客户端确定服务器握手报文中网络中间设备的私有证书的合法性验证通过时，利用网络中间设备的私有证书的公钥，对生成的第三随机数进行加密，得到加密随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端的数据传输密钥后，基于SSL连接过程中的所有会话数据，获得第一握手验证数据，以及利用客户端的数据传输密钥，对第一握手验证数据进行加密，得到第一加密验证数据并进行封装后获得的；
利用网络中间设备的私有证书的私钥，对客户端验证报文中的加密随机数进行解密，得到第三随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端的数据传输密钥；
利用客户端的数据传输密钥，对客户端验证报文中的第一加密验证数据进行解密，得到第一握手验证数据，并对第一握手验证数据进行验证；
确定第一握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第二握手验证数据，并利用客户端的数据传输密钥，对第二握手验证数据进行加密，得到第二加密验证数据；
基于第二加密验证数据的长度和客户端验证报文中的可靠传输参数，重新获得可靠传输参数；
将第二加密验证数据和重新获得的可靠传输参数封装为服务器验证报文返回至客户端，以使客户端对服务器验证报文中的第二握手验证数据进行验证，并在服务器验证报文中的第二握手验证数据验证通过时，确定与客户端的SSL连接建立完成。
在一种可能的实施方式中，通过连接协程模拟客户端与服务器建立SSL连接，包括通过连接协程模拟客户端执行以下操作：
生成第四随机数，并基于第四随机数和网络中间设备支持的各个加密算法，生成客户端握手数据；
基于客户端握手数据和客户端握手报文中的可靠传输参数，重新获得可靠传输参数，并将客户端握手数据和重新获得的可靠传输参数重新封装为客户端握手报文发送至服务器；
接收服务器返回的服务器握手报文，其中，服务器握手报文是，服务器从接收到的客户端握手报文中，获取第四随机数和网络中间设备支持的各个加密算法后，从网络中间设备支持的各个加密算法中，选取一个加密算法作为第二加密算法，并生成第五随机数时，对第二加密算法、第五随机数和服务器的私有证书进行封装后获得的；
从服务器握手报文中，获取服务器选择的第二加密算法、服务器生成的第五随机数和服务器的私有证书，并对服务器的私有证书进行合法性验证；
确定服务器的私有证书的合法性验证通过时，生成第六随机数，并利用服务器的私有证书的公钥，对第六随机数进行加密，得到加密随机数；
基于第四随机数、第五随机数和第六随机数，生成服务器的数据传输密钥，并基于SSL连接过程中的所有会话数据，获得第三握手验证数据，以及利用服务器的数据传输密钥，对第三握手验证数据进行加密，得到第三加密验证数据；
基于加密随机数和第三加密验证数据，生成客户端验证数据，并基于客户端验证数据的长度和服务器握手报文中的可靠传输参数，重新获得可靠传输参数，以及将客户端验证数据和重新获得的可靠传输参数封装为客户端验证报文返回至服务器；
接收服务器返回的服务器验证报文，其中，服务器验证报文是，服务器利用服务器的私有证书的私钥，对客户端验证报文中的加密随机数进行解密，得到第六随机数后，基于第四随机数、第五随机数和第六随机数，生成服务器的数据传输密钥，并利用服务器的数据传输密钥，对客户端验证报文中的第三加密验证数据进行解密，得到第三握手验证数据后，确定第三握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第四握手验证数据，并利用服务器的数据传输密钥，对第四握手验证数据进行加密，得到第四加密验证数据并进行封装后获得的；
利用服务器的数据传输密钥，对服务器验证报文中的第四加密验证数据进行解密，得到第四握手验证数据，对第四握手验证数据进行验证，并在第四握手验证数据验证通过时，确定与服务器的SSL连接建立完成。
在一种可能的实施方式中，可靠传输参数包括序号、确认号、TCP校验和以及互联网协议(Internet Protocol，IP)校验和。
另一方面，本申请实施例提供了一种报文处理装置，包括：
连接建立单元，用于通过透传TCP三次握手报文使客户端与服务器建立TCP连接，并基于TCP连接，分别与客户端和服务器建立SSL连接；
报文接收单元，用于接收第一加密数据报文，其中，第一加密数据报文的发送端为客户端和服务器中的一个，接收端为客户端和服务器中的另一个；
数据解密单元，用于利用与发送端建立SSL连接时协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据；
审计加密单元，用于对明文数据进行内容审计，并确定明文数据的内容审计通过的情况下，利用与接收端建立SSL连接时协商的数据传输密钥，对明文数据进行加密，得到第二加密数据；
参数获取单元，用于基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数；
数据封装单元，用于将第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至接收端。
在一种可能的实施方式中，在通过透传TCP三次握手报文使客户端与服务器建立TCP连接时，连接建立单元具体用于：
接收客户端向服务器发送的TCP连接请求报文，基于TCP连接请求报文中的五元组，建立TCP流表，将TCP连接请求报文中的序号和确认号记录至TCP流表，并将TCP连接请求报文透传至服务器；
接收服务器向客户端发送的TCP连接请求确认报文，将TCP连接请求确认报文中的序号和确认号记录至TCP流表，并将TCP连接请求确认报文透传至客户端；
接收客户端向服务器发送的TCP连接确认报文，将TCP连接确认报文中的序号和确认号记录至TCP流表，并将TCP连接确认报文透传至服务器；
确定客户端与服务器之间的TCP连接建立完成。
在一种可能的实施方式中，在基于TCP连接，分别与客户端和服务器建立SSL连接时，连接建立单元具体用于：
接收客户端向服务器发送的客户端握手报文，并创建接受协程和连接协程；
通过接受协程模拟服务器与客户端建立SSL连接，并通过连接协程模拟客户端与服务器建立SSL连接。
在一种可能的实施方式中，在通过接受协程模拟服务器与客户端建立SSL连接时，连接建立单元具体用于通过接受协程模拟服务器执行以下操作：
从客户端握手报文中，获取客户端支持的各个加密算法以及客户端生成的第一随机数，并从客户端支持的各个加密算法中，选取一个加密算法作为第一加密算法；
生成第二随机数，并基于第一加密算法、第二随机数和网络中间设备的私有证书，生成服务器握手数据；
基于服务器握手数据的长度和客户端握手报文中的可靠传输参数，重新获得可靠传输参数；
将服务器握手数据和重新获得的可靠传输参数封装为服务器握手报文发送至客户端；
接收客户端返回的客户端验证报文，其中，客户端验证报文是，客户端确定服务器握手报文中网络中间设备的私有证书的合法性验证通过时，利用网络中间设备的私有证书的公钥，对生成的第三随机数进行加密，得到加密随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端的数据传输密钥后，基于SSL连接过程中的所有会话数据，获得第一握手验证数据，以及利用客户端的数据传输密钥，对第一握手验证数据进行加密，得到第一加密验证数据并进行封装后获得的；
利用网络中间设备的私有证书的私钥，对客户端验证报文中的加密随机数进行解密，得到第三随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端的数据传输密钥；
利用客户端的数据传输密钥，对客户端验证报文中的第一加密验证数据进行解密，得到第一握手验证数据，并对第一握手验证数据进行验证；
确定第一握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第二握手验证数据，并利用客户端的数据传输密钥，对第二握手验证数据进行加密，得到第二加密验证数据；
基于第二加密验证数据的长度和客户端验证报文中的可靠传输参数，重新获得可靠传输参数；
将第二加密验证数据和重新获得的可靠传输参数封装为服务器验证报文返回至客户端，以使客户端对服务器验证报文中的第二握手验证数据进行验证，并在服务器验证报文中的第二握手验证数据验证通过时，确定与客户端的SSL连接建立完成。
在一种可能的实施方式中，在通过连接协程模拟客户端与服务器建立SSL连接时，连接建立单元具体用于通过连接协程模拟客户端执行以下操作：
生成第四随机数，并基于第四随机数和网络中间设备支持的各个加密算法，生成客户端握手数据；
基于客户端握手数据和客户端握手报文中的可靠传输参数，重新获得可靠传输参数，并将客户端握手数据和重新获得的可靠传输参数重新封装为客户端握手报文发送至服务器；
接收服务器返回的服务器握手报文，其中，服务器握手报文是，服务器从接收到的客户端握手报文中，获取第四随机数和网络中间设备支持的各个加密算法后，从网络中间设备支持的各个加密算法中，选取一个加密算法作为第二加密算法，并生成第五随机数时，对第二加密算法、第五随机数和服务器的私有证书进行封装后获得的；
从服务器握手报文中，获取服务器选择的第二加密算法、服务器生成的第五随机数和服务器的私有证书，并对服务器的私有证书进行合法性验证；
确定服务器的私有证书的合法性验证通过时，生成第六随机数，并利用服务器的私有证书的公钥，对第六随机数进行加密，得到加密随机数；
基于第四随机数、第五随机数和第六随机数，生成服务器的数据传输密钥，并基于SSL连接过程中的所有会话数据，获得第三握手验证数据，以及利用服务器的数据传输密钥，对第三握手验证数据进行加密，得到第三加密验证数据；
基于加密随机数和第三加密验证数据，生成客户端验证数据，并基于客户端验证数据的长度和服务器握手报文中的可靠传输参数，重新获得可靠传输参数，以及将客户端验证数据和重新获得的可靠传输参数封装为客户端验证报文返回至服务器；
接收服务器返回的服务器验证报文，其中，服务器验证报文是，服务器利用服务器的私有证书的私钥，对客户端验证报文中的加密随机数进行解密，得到第六随机数后，基于第四随机数、第五随机数和第六随机数，生成服务器的数据传输密钥，并利用服务器的数据传输密钥，对客户端验证报文中的第三加密验证数据进行解密，得到第三握手验证数据后，确定第三握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第四握手验证数据，并利用服务器的数据传输密钥，对第四握手验证数据进行加密，得到第四加密验证数据并进行封装后获得的；
利用服务器的数据传输密钥，对服务器验证报文中的第四加密验证数据进行解密，得到第四握手验证数据，对第四握手验证数据进行验证，并在第四握手验证数据验证通过时，确定与服务器的SSL连接建立完成。
在一种可能的实施方式中，可靠传输参数包括序号、确认号、TCP校验和以及IP校验和。
另一方面，本申请实施例提供了一种报文处理设备，包括：存储器、处理器和存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现本申请实施例提供的报文处理方法。
另一方面，本申请实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机指令，计算机指令被处理器执行时实现本申请实施例提供的报文处理方法。
本申请实施例的有益效果如下：
本申请实施例中，网络中间设备通过透传TCP三次握手报文使客户端与服务器建立TCP连接，无需与客户端和服务器分别建立TCP连接，进而不需要维护TCP协议栈，而且，在处理加密数据报文时，只需要重新计算可靠传输参数并重新封装加密数据报文即可，从而在无需维护TCP协议栈的情况下，实现了对加密数据报文的处理，进而降低了资源消耗，提高了处理效率。
本申请的其它特征和优点将在随后的说明书中阐述，并且，部分地可以从说明书中变得显而易见，或者通过实施本申请而了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中特别指出的结构来实现和获得。
附图说明
此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：
图1为本申请实施例中客户端、网络中间设备和服务器之间TCP连接和SSL连接的传统连接方案示意图；
图2为本申请实施例中客户端、网络中间设备和服务器之间TCP连接和SSL连接示意图；
图3A为本申请实施例中报文处理方法的概况流程示意图；
图3B为本申请实施例中客户端与服务器之间的TCP连接建立方法的流程示意图；
图3C为本申请实施例中网络中间设备与客户端之间的SSL连接建立方法的流程示意图；
图3D为本申请实施例中网络中间设备与服务器之间的SSL连接建立方法的流程示意图；
图4为本申请实施例中报文处理方法的具体流程示意图；
图5为本申请实施例中报文处理装置的功能结构示意图；
图6为本申请实施例中报文处理设备的硬件结构示意图。
具体实施方式
为了使本申请的目的、技术方案及有益效果更加清楚明白，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，并不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
为便于本领域技术人员更好地理解本申请，下面先对本申请涉及的技术用语进行简单介绍。
1、客户端，是安装在手机、计算机、个人数字助理(Personal Digital Assistant，PDA)、智能电视等终端设备上的应用程序，例如，网页浏览器等。
2、服务器，是为客户端提供数据库服务、计算服务等各类服务的后台运行设备。
3、网络中间设备，是对客户端和服务器发送的加密数据报文执行解密还原、内容检测、再加密和转发等操作的后台运行设备。
4、可靠传输参数，是用于确保数据可靠传输的参数，本申请中，可靠传输参数包括但不限于：序号(Sequence，Seq)、确认号(Acknowledgement，Ack)、TCP校验和(TCPChecksum)以及IP校验和(IP Checksum)等。
5、协程，是一种程序组件，本申请中，协程包括但不限于：接受(Accept)协程和连接(Connect)协程，其中，一个TCP连接对应一个Accept协程和一个Connect协程。
6、TCP流表，是用于记录网络中间设备对加密数据报文进行处理时涉及的SSL会话数据、协程数据、可靠传输参数等各项数据的数据表，本申请中，一个TCP连接对应TCP流表中的一条信息。
需要说明的是，本申请中提及的“第一”、“第二”、“第三”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样的用语在适当情况下可以互换，以便本申请描述的实施例能够以除本申请图示或描述的内容以外的顺序实施。
在介绍了本申请涉及的技术用语后，接下来，对本申请实施例的应用场景和设计思想进行简单介绍。
目前，参阅图1所示，为了使网络中间设备101可以对SSL加密流量进行内容检测，传统方案是，网络中间设备101分别与客户端102和服务器103建立TCP连接和SSL连接，并通过用户态的TCP协议栈，对接收到的加密数据报文进行解密还原、内容检测、再加密和转发等操作，这种通过用户态的TCP协议栈处理加密数据报文的方式，由于用户态的TCP协议栈的实现机制较为复杂，网络中间设备101在处理加密数据报文时，不仅需要消耗大量内存和CPU等资源，而且，加密数据报文的处理效率较低。
为此，本申请实施例中，参阅图2所示，网络中间设备101通过透传TCP三次握手报文使客户端102与服务器103建立TCP连接，并基于该TCP连接，分别与客户端102和服务器103建立SSL连接，在接收到第一加密数据报文时，确定第一加密数据报文的发送端和接收端后，利用与发送端建立SSL连接时协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据，并对明文数据进行内容审计，确定明文数据的内容审计通过的情况下，利用与接收端建立SSL连接时协商的数据传输密钥，对明文数据进行加密，得到第二加密数据，以及基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数，并将第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至接收端。这样，网络中间设备101通过透传TCP三次握手报文使客户端102与服务器103建立TCP连接，无需与客户端102和服务器103分别建立TCP连接，进而不需要维护TCP协议栈，而且，在处理加密数据报文时，只需要重新计算可靠传输参数并重新封装加密数据报文即可，从而在无需维护TCP协议栈的情况下，实现了对加密数据报文的处理，进而降低了资源消耗，提高了处理效率。
在介绍了本申请实施例的应用场景和设计思想之后，下面对本申请实施例提供的技术方案进行详细说明。
本申请实施例提供了一种报文处理方法，应用于网络中间设备101，参阅图3A所示，本申请实施例提供的报文处理方法的概况流程如下：
步骤300：网络中间设备101通过透传TCP三次握手报文使客户端102与服务器103建立TCP连接，并基于TCP连接，分别与客户端102和服务器103建立SSL连接。
实际应用中，参阅图3B所示，网络中间设备101在通过透传TCP三次握手报文使客户端102与服务器103建立TCP连接时，可以采用但不限于以下方式：
步骤3000：网络中间设备101接收客户端102向服务器103发送的TCP连接请求报文(下述称TCP SYN报文)。
步骤3001：网络中间设备101确定该TCP SYN报文是TCP数据流的首个报文，基于该TCP SYN报文中的五元组，为该TCP数据流创建TCP流表。
步骤3002：网络中间设备101将该TCP SYN报文中的可靠传输参数(包括但不限于：Seq和Ack)记录至该TCP流表。
步骤3003：网络中间设备101将该TCP SYN报文透传至服务器103。
步骤3004：网络中间设备101接收服务器103向客户端102发送的TCP连接请求确认报文(下述称TCP SYN ACK报文)。
步骤3005：网络中间设备101将该TCP SYN ACK报文中的可靠传输参数(包括但不限于：Seq和Ack)记录至该TCP流表。
步骤3006：网络中间设备101将该TCP SYN ACK报文透传至客户端102。
步骤3007：网络中间设备101接收客户端102向服务器103发送的TCP连接确认报文(下述称TCP ACK报文)。
步骤3008：网络中间设备101将该TCP ACK报文中的可靠传输参数(包括但不限于：Seq和Ack)记录至该TCP流表。
步骤3009：网络中间设备101将该TCP ACK报文透传至客户端102。
步骤3010：网络中间设备101确定客户端102与服务器103之间的TCP连接建立完成。
实际应用中，网络中间设备101在通过透传TCP三次握手报文使客户端102与服务器103建立TCP连接后，可以进一步基于该TCP连接，分别与客户端102和服务器103建立SSL连接，具体的，网络中间设备101可以在接收到客户端102向服务器103发送的客户端握手报文(下述称Client Hello报文)时，创建接受协程(下述称Accept协程)和连接协程(下述称Connect协程)，通过Accept协程模拟服务器103与客户端102建立SSL连接，并通过Connect协程模拟客户端102与服务器103建立SSL连接。
值得说的是，本申请实施例中，网络中间设备101创建Accept协程和Connect协程后，还可以将Accept协程的协程信息和Connect协程的协程信息记录至TCP流表，以便后续在与客户端102建立SSL连接的过程中，可以根据TCP流表记录的Accept协程的协程信息，对Accept协程启用状态进行控制，并在与服务器103建立SSL连接的过程中，可以根据TCP流表记录的Connect协程的协程信息，对Connect协程的启用状态进行控制。
在具体实施时，参阅图3C所示，网络中间设备101在通过Accept协程模拟服务器103与客户端102建立SSL连接时，可以通过Accept协程模拟服务器103执行以下操作：
步骤3011：网络中间设备101从Client Hello报文中，获取客户端102支持的各个加密算法以及客户端102生成的第一随机数，并从客户端102支持的各个加密算法中，选取一个加密算法作为第一加密算法。
值得说的是，本申请实施例中，网络中间设备101还可以将Client Hello报文中的可靠传输参数记录至TCP流表，以便后续可以根据TCP流表记录的Client Hello报文中的可靠传输参数，重新获得可靠传输参数。
步骤3012：网络中间设备101生成第二随机数，并基于第一加密算法、第二随机数和网络中间设备101的私有证书，生成服务器握手数据。
步骤3013：网络中间设备101基于服务器握手数据的长度和Client Hello报文中的可靠传输参数，重新获得可靠传输参数。
在具体实施时，网络中间设备101在基于服务器握手数据的长度和Client Hello报文中的可靠传输参数，重新获得可靠传输参数时，可以采用但不限于以下方式：
首先，网络中间设备101基于服务器握手数据的长度和Client Hello报文中的Seq，重新计算Seq，获得新Seq，具体的，网络中间设备101可以从TCP流表中，获取ClientHello报文中的Seq，并将服务器握手数据的长度与Client Hello报文中的Seq的和确定为新Seq。
然后，网络中间设备101基于新Seq，重新计算Ack，获得新Ack，具体的，网络中间设备101可以将新Seq与1的和确定为新Ack。
其次，网络中间设备101将TCP首部和TCP数据的数据位按位相加后取反，获得新TCP Checksum，并将IP首部的数据位按位相加后取反，获得新IP Checksum。
最后，网络中间设备101将新Seq、新Ack、新TCP Checksum和新IP Checksum确定为重新获得的可靠传输参数。
步骤3014：网络中间设备101将服务器握手数据和重新获得的可靠传输参数封装为服务器握手报文(下述称Sever Hello报文)发送至客户端102。
值得说的是，本申请实施例中，网络中间设备101将Sever Hello报文发送至客户端102后，可以挂起Accept协程。
步骤3015：网络中间设备101接收客户端102返回的客户端验证报文(下述称Client Verification报文)，其中，Client Verification报文是，客户端102确定SeverHello报文中网络中间设备101的私有证书的合法性验证通过时，利用网络中间设备101的私有证书的公钥，对生成的第三随机数进行加密，得到加密随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端102的数据传输密钥后，基于SSL连接过程中的所有会话数据，获得第一握手验证数据，以及利用客户端102的数据传输密钥，对第一握手验证数据进行加密，得到第一加密验证数据并进行封装后获得的。
值得说的是，本申请实施例中，网络中间设备101接收到Client Verification报文后，可以根据Client Verification报文中的五元组，从对应的TCP流表中查找Accept协程的协程信息，并根据查找到的Accept协程的协程信息，唤醒相应的Accept协程继续处理与客户端102之间的SSL连接的建立，即继续执行步骤3016。
步骤3016：网络中间设备101利用网络中间设备101的私有证书的私钥，对ClientVerification报文中的加密随机数进行解密，得到第三随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端102的数据传输密钥。
步骤3017：网络中间设备101利用客户端102的数据传输密钥，对ClientVerification报文中的第一加密验证数据进行解密，得到第一握手验证数据，并对第一握手验证数据进行验证。
步骤3018：网络中间设备101确定第一握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第二握手验证数据，并利用客户端102的数据传输密钥，对第二握手验证数据进行加密，得到第二加密验证数据。
步骤3019：网络中间设备101基于第二加密验证数据的长度和ClientVerification报文中的可靠传输参数，重新获得可靠传输参数。
在具体实施时，网络中间设备101在基于第二加密验证数据的长度和ClientVerification报文中的可靠传输参数，重新获得可靠传输参数时，可以采用但不限于以下方式：
首先，网络中间设备101基于第二加密验证数据的长度和Client Verification报文中的Seq，重新计算Seq，获得新Seq，具体的，网络中间设备101可以将第二加密验证数据的长度与Client Verification报文中的Seq的和确定为新Seq。
然后，网络中间设备101基于新Seq，重新计算Ack，获得新Ack，具体的，网络中间设备101可以将新Seq与1的和确定为新Ack。
其次，网络中间设备101将TCP首部和TCP数据的数据位按位相加后取反，获得新TCP Checksum，并将IP首部的数据位按位相加后取反，获得新IP Checksum。
最后，网络中间设备101将新Seq、新Ack、新TCP Checksum和新IP Checksum确定为重新获得的可靠传输参数。
步骤3020：网络中间设备101将第二加密验证数据和重新获得的可靠传输参数封装为服务器验证报文(即Sever Verification报文)返回至客户端102，以使客户端102对Sever Verification报文中的第二握手验证数据进行验证，并在Sever Verification报文中的第二握手验证数据验证通过时，确定与客户端102的SSL连接建立完成。
值得说的是，本申请实施例中，网络中间设备101确定与客户端102的SSL连接建立完成后，可以挂起Accept协程。
在具体实施时，参阅图3D所示，网络中间设备101在通过Connect协程模拟客户端102与服务器103建立SSL连接时，可以通过Connect协程模拟客户端102执行以下操作：
步骤3021：网络中间设备101生成第四随机数，并基于第四随机数和网络中间设备101支持的各个加密算法，生成客户端握手数据。
步骤3022：网络中间设备101基于客户端握手数据和Client Hello报文中的可靠传输参数，重新获得可靠传输参数。
在具体实施时，网络中间设备101在基于客户端握手数据和Client Hello报文中的可靠传输参数，重新获得可靠传输参数时，可以采用但不限于以下方式：
首先，网络中间设备101基于客户端握手数据的长度和Client Hello报文中的Seq，重新计算Seq，获得新Seq，具体的，网络中间设备101可以将客户端握手数据的长度与Client Hello报文中的Seq的和确定为新Seq。
然后，网络中间设备101基于新Seq，重新计算Ack，获得新Ack，具体的，网络中间设备101可以将新Seq与1的和确定为新Ack。
其次，网络中间设备101将TCP首部和TCP数据的数据位按位相加后取反，获得新TCP Checksum，并将IP首部的数据位按位相加后取反，获得新IP Checksum。
最后，网络中间设备101将新Seq、新Ack、新TCP Checksum和新IP Checksum确定为重新获得的可靠传输参数。
步骤3023：网络中间设备101将客户端握手数据和重新获得的可靠传输参数重新封装为Client Hello报文发送至服务器103。
值得说的是，本申请实施例中，网络中间设备101将Client Hello报文发送至服务器103后，可以挂起Connect协程。
步骤3024：网络中间设备101接收服务器103返回的Sever Hello报文，其中，SeverHello报文是，服务器103从接收到的Client Hello报文中，获取第四随机数和网络中间设备101支持的各个加密算法后，从网络中间设备101支持的各个加密算法中，选取一个加密算法作为第二加密算法，并生成第五随机数时，对第二加密算法、第五随机数和服务器103的私有证书进行封装后获得的。
值得说的是，本申请实施例中，网络中间设备101接收到Sever Hello报文后，可以根据Sever Hello报文中的五元组，从对应的TCP流表中查找Connect协程的协程信息，并根据查找到的Connect协程的协程信息，唤醒相应的Connect协程继续处理与服务器103之间的SSL连接的建立，即继续执行步骤3025。
步骤3025：网络中间设备101从Sever Hello报文中，获取服务器103选择的第二加密算法、服务器103生成的第五随机数和服务器103的私有证书，并对服务器103的私有证书进行合法性验证。
步骤3026：网络中间设备101确定服务器103的私有证书的合法性验证通过时，生成第六随机数，并利用服务器103的私有证书的公钥，对第六随机数进行加密，得到加密随机数。
步骤3027：网络中间设备101基于第四随机数、第五随机数和第六随机数，生成服务器103的数据传输密钥，并基于SSL连接过程中的所有会话数据，获得第三握手验证数据，以及利用服务器103的数据传输密钥，对第三握手验证数据进行加密，得到第三加密验证数据。
步骤3028：网络中间设备101基于加密随机数和第三加密验证数据，生成客户端验证数据，并基于客户端验证数据的长度和Sever Hello报文中的可靠传输参数，重新获得可靠传输参数。
在具体实施时，网络中间设备101在基于客户端验证数据的长度和Sever Hello报文中的可靠传输参数，重新获得可靠传输参数时，可以采用但不限于以下方式：
首先，网络中间设备101基于客户端验证数据的长度和Sever Hello报文中的Seq，重新计算Seq，获得新Seq，具体的，网络中间设备101可以将客户端验证数据的长度与SeverHello报文中的Seq的和确定为新Seq。
然后，网络中间设备101基于新Seq，重新计算Ack，获得新Ack，具体的，网络中间设备101可以将新Seq与1的和确定为新Ack。
其次，网络中间设备101将TCP首部和TCP数据的数据位按位相加后取反，获得新TCP Checksum，并将IP首部的数据位按位相加后取反，获得新IP Checksum。
最后，网络中间设备101将新Seq、新Ack、新TCP Checksum和新IP Checksum确定为重新获得的可靠传输参数。
步骤3029：网络中间设备101将客户端验证数据和重新获得的可靠传输参数封装为Client Verification报文返回至服务器103。
值得说的是，本申请实施例中，网络中间设备101将Client Verification报文发送至服务器103后，可以挂起Connect协程。
步骤3030：网络中间设备101接收服务器103返回的Sever Verification报文，其中，Sever Verification报文是，服务器103利用服务器103的私有证书的私钥，对ClientVerification报文中的加密随机数进行解密，得到第六随机数后，基于第四随机数、第五随机数和第六随机数，生成服务器103的数据传输密钥，并利用服务器103的数据传输密钥，对Client Verification报文中的第三加密验证数据进行解密，得到第三握手验证数据后，确定第三握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第四握手验证数据，并利用服务器103的数据传输密钥，对第四握手验证数据进行加密，得到第四加密验证数据并进行封装后获得的。
值得说的是，本申请实施例中，网络中间设备101接收到Sever Verification报文后，可以根据Sever Verification报文中的五元组，从对应的TCP流表中查找Connect协程的协程信息，并根据查找到的Connect协程的协程信息，唤醒相应的Connect协程继续处理与服务器103之间的SSL连接的建立，即继续执行步骤3031。
步骤3031：网络中间设备101利用服务器103的数据传输密钥，对SeverVerification报文中的第四加密验证数据进行解密，得到第四握手验证数据。
步骤3032：网络中间设备101对第四握手验证数据进行验证，并在第四握手验证数据验证通过时，确定与服务器103的SSL连接建立完成。
值得说的是，本申请实施例中，网络中间设备101确定与服务器103的SSL连接建立完成后，可以挂起Connect协程。
步骤301：网络中间设备101接收第一加密数据报文，其中，第一加密数据报文的发送端为客户端102和服务器103中的一个，接收端为客户端102和服务器103中的另一个。
值得说的是，本申请实施例中，网络中间设备101接收到第一加密数据报文后，若第一加密数据报文的发送端为客户端102，则可以根据第一加密数据报文中的五元组，从对应的TCP流表中查找Accept协程的协程信息，并根据查找到的Accept协程的协程信息，唤醒相应的Accept协程继续处理第一加密数据报文，即继续执行步骤302；若第一加密数据报文的发送端为服务器103，则可以根据第一加密数据报文中的五元组，从对应的TCP流表中查找Connect协程的协程信息，并根据查找到的Connect协程的协程信息，唤醒相应的Connect协程继续处理第一加密数据报文，即继续执行步骤302。
步骤302：网络中间设备101利用与发送端建立SSL连接时协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据。
值得说的是，本申请实施例中，网络中间设备101在与客户端102建立SSL连接的过程中，还可以将与客户端102协商的第一加密算法、客户端102的数据传输密钥等客户端102的SSL会话数据记录至TCP流表，并在与服务器103建立SSL连接的过程中，还可以将与服务器103协商的第二加密算法、服务器103的数据传输密钥等服务器103的SSL会话数据记录至TCP流表。这样，网络中间设备101在接收到第一加密数据报文时，若第一加密数据报文的发送端为客户端102，则可以通过唤醒的Accept协程，根据第一加密数据报文中的五元组，从对应的TCP流表中查找客户端102的SSL会话数据，并利用客户端102的SSL会话数据中包含的客户端102的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据；若第一加密数据报文的发送端为服务器103，则可以通过唤醒的Connect协程，根据第一加密数据报文中的五元组，从对应的TCP流表中查找服务器103的SSL会话数据，并利用服务器103的SSL会话数据中包含的服务器103的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据。
步骤303：网络中间设备101对明文数据进行内容审计，并确定明文数据的内容审计通过的情况下，利用与接收端建立SSL连接时协商的数据传输密钥，对明文数据进行加密，得到第二加密数据。
实际应用中，若第一加密数据报文的发送端为客户端102，则网络中间设备101确定明文数据的内容审计通过的情况下，可以利用客户端102的数据传输密钥，对明文数据进行加密，得到第二加密数据；若第一加密数据报文的发送端为服务器103，则网络中间设备101确定明文数据的内容审计通过的情况下，可以利用服务器103的数据传输密钥，对明文数据进行加密，得到第二加密数据。
步骤304：网络中间设备101基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数。
在具体实施时，网络中间设备101在基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数时，可以采用但不限于以下方式：
首先，网络中间设备101基于第二加密数据的长度和第一加密数据报文中的Seq，重新计算Seq，获得新Seq，具体的，网络中间设备101可以将第二加密数据的长度与第一加密数据报文中的Seq的和确定为新Seq。
然后，网络中间设备101基于新Seq，重新计算Ack，获得新Ack，具体的，网络中间设备101可以将新Seq与1的和确定为新Ack。
其次，网络中间设备101将TCP首部和TCP数据的数据位按位相加后取反，获得新TCP Checksum，并将IP首部的数据位按位相加后取反，获得新IP Checksum。
最后，网络中间设备101将新Seq、新Ack、新TCP Checksum和新IP Checksum确定为重新获得的可靠传输参数。
步骤305：网络中间设备101将第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至接收端。
实际应用中，若第一加密数据报文的发送端为客户端102，则网络中间设备101可以将第二加密数据报文发送至服务器103，进一步的，网络中间设备101还可以挂起Accept协程，当再次接收到客户端102发送的第一加密数据报文时，唤醒Accept协程处理该第一加密数据报文；若第一加密数据报文的发送端为服务器103，则网络中间设备101可以将第二加密数据报文发送至客户端102，进一步的，网络中间设备101还可以挂起Connect协程，当再次接收到服务器103发送的第一加密数据报文时，唤醒Connect协程处理该第一加密数据报文。
下面结合具体应用场景，对本申请实施例提供的报文处理方法作进一步详细说明，参阅图4所示，本申请实施例提供的报文处理方法的具体流程如下：
步骤401：网络中间设备101启动，并初始化出入接口和SSL数据库。
步骤402：客户端102向服务器103发送TCP SYN报文。
步骤403：网络中间设备101接收到客户端102向服务器103发送的TCP SYN报文时，确定该TCP SYN报文是TCP数据流的首个报文，并基于该TCP SYN报文中的五元组，为该TCP数据流创建TCP流表，并将该TCP SYN报文中的可靠传输参数(包括但不限于：Seq和Ack)记录至TCP流表。
步骤404：网络中间设备101将该TCP SYN报文透传至服务器103。
步骤405：服务器103向客户端102发送TCP SYN ACK报文。
步骤406：网络中间设备101接收到服务器103向客户端102发送的TCP SYN ACK报文时，将该TCP SYN ACK报文中的可靠传输参数(包括但不限于：Seq和Ack)记录至TCP流表。
步骤407：网络中间设备101将该TCP SYN ACK报文透传至客户端102。
步骤408：客户端102向服务器103发送TCP ACK报文。
步骤409：网络中间设备101接收到客户端102向服务器103发送的TCP ACK报文时，将该TCP ACK报文中的可靠传输参数(包括但不限于：Seq和Ack)记录至该TCP流表。
步骤410：网络中间设备101将该TCP ACK报文透传至服务器103。
步骤411：网络中间设备101确定客户端102与服务器103之间的TCP连接建立完成。
步骤412：客户端102向服务器103发送Client Hello报文。
步骤413：网络中间设备101接收到客户端102向服务器103发送的Client Hello报文时，创建Accept协程和Connect协程，并将Accept协程的协程信息和Connect协程的协程信息记录至TCP流表。
步骤414：网络中间设备101启用Accept协程，从Client Hello报文中，获取客户端102支持的各个加密算法以及客户端102生成的第一随机数，并从客户端102支持的各个加密算法中，选取一个加密算法作为第一加密算法。
步骤415：网络中间设备101生成第二随机数，并基于第一加密算法、第二随机数和网络中间设备101的私有证书，生成服务器握手数据。
步骤416：网络中间设备101基于服务器握手数据的长度和Client Hello报文中的可靠传输参数，重新获得可靠传输参数。其中，步骤417的实现方式与上述描述方式相同，重复之处不再赘述。
步骤417：网络中间设备101将服务器握手数据和重新获得的可靠传输参数封装为Sever Hello报文发送至客户端102。
步骤418：网络中间设备101挂起Accept协程。
步骤419：客户端102接收到Sever Hello报文时，对Sever Hello报文中网络中间设备101的私有证书的合法性进行验证。
步骤420：客户端102确定Sever Hello报文中网络中间设备101的私有证书的合法性验证通过时，生成第三随机数，并利用网络中间设备101的私有证书的公钥，对生成的第三随机数进行加密，得到加密随机数。
步骤421：客户端102基于第一随机数、第二随机数和第三随机数，生成客户端102的数据传输密钥后，基于SSL连接过程中的所有会话数据，生成第一握手验证数据，并利用客户端102的数据传输密钥，对第一握手验证数据进行加密，得到第一加密验证数据。
步骤422：客户端102将第一加密验证数据封装成Client Verification报文并发送。
步骤423：网络中间设备101接收到客户端102发送的Client Verification报文时，根据Client Verification报文中的五元组，从对应的TCP流表中查找Accept协程的协程信息。
步骤424：网络中间设备101根据查找到的Accept协程的协程信息，唤醒Accept协程，利用网络中间设备101的私有证书的私钥，对Client Verification报文中的加密随机数进行解密，得到第三随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端102的数据传输密钥。
步骤425：网络中间设备101利用客户端102的数据传输密钥，对ClientVerification报文中的第一加密验证数据进行解密，得到第一握手验证数据，并对第一握手验证数据进行验证。
步骤426：网络中间设备101确定第一握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第二握手验证数据，并利用客户端102的数据传输密钥，对第二握手验证数据进行加密，得到第二加密验证数据。
步骤427：网络中间设备101基于第二加密验证数据的长度和ClientVerification报文中的可靠传输参数，重新获得可靠传输参数。其中，步骤427的实现方式与上述描述方式相同，重复之处不再赘述。
步骤428：网络中间设备101将第二加密验证数据和重新获得的可靠传输参数封装为Sever Verification报文返回至客户端102。
步骤429：网络中间设备101挂起Accept协程。
步骤430：客户端102接收到Sever Verification报文时，利用客户端102的数据传输密钥，对Sever Verification报文中的第二加密验证数据进行解密，得到第二握手验证数据。
步骤431：客户端102对Sever Verification报文中的第二握手验证数据进行验证，并在Sever Verification报文中的第二握手验证数据验证通过时，确定与客户端102的SSL连接建立完成。
步骤432：网络中间设备101启用Connect协程，生成第四随机数，并基于第四随机数和网络中间设备101支持的各个加密算法，生成客户端握手数据。
步骤433：网络中间设备101基于客户端握手数据和Client Hello报文中的可靠传输参数，重新获得可靠传输参数。其中，步骤433的实现方式与上述描述方式相同，重复之处不再赘述。
步骤434：网络中间设备101将客户端握手数据和重新获得的可靠传输参数重新封装为Client Hello报文发送至服务器103。
步骤435：网络中间设备101挂起Connect协程。
步骤436：服务器103接收到Client Hello报文时，从Client Hello报文中，获取第四随机数和网络中间设备101支持的各个加密算法，并从网络中间设备101支持的各个加密算法中，选取一个加密算法作为第二加密算法，并生成第五随机数。
步骤437：服务器103将第二加密算法、第五随机数和服务器103的私有证书封装成Sever Hello报文并发送。
步骤438：网络中间设备101接收到服务器103发送的Sever Hello报文时，根据Sever Hello报文中的五元组，从对应的TCP流表中查找Connect协程的协程信息。
步骤439：网络中间设备101根据查找到的Connect协程的协程信息，唤醒Connect协程，从Sever Hello报文中，获取服务器103选择的第二加密算法、服务器103生成的第五随机数和服务器103的私有证书，并对服务器103的私有证书进行合法性验证。
步骤440：网络中间设备101确定服务器103的私有证书的合法性验证通过时，生成第六随机数，并利用服务器103的私有证书的公钥，对第六随机数进行加密，得到加密随机数。
步骤441：网络中间设备101基于第四随机数、第五随机数和第六随机数，生成服务器103的数据传输密钥，并基于SSL连接过程中的所有会话数据，获得第三握手验证数据。
步骤442：网络中间设备101利用服务器103的数据传输密钥，对第三握手验证数据进行加密，得到第三加密验证数据，并基于加密随机数和第三加密验证数据，生成客户端验证数据。
步骤443：网络中间设备101基于客户端验证数据的长度和Sever Hello报文中的可靠传输参数，重新获得可靠传输参数。其中，步骤443的实现方式与上述描述方式相同，重复之处不再赘述。
步骤444：网络中间设备101将客户端验证数据和重新获得的可靠传输参数封装为Client Verification报文返回至服务器103。
步骤445：服务器103接收到Client Verification报文时，利用服务器103的私有证书的私钥，对Client Verification报文中的加密随机数进行解密，得到第六随机数，并基于第四随机数、第五随机数和第六随机数，生成服务器103的数据传输密钥。
步骤446：服务器103利用服务器103的数据传输密钥，对Client Verification报文中的第三加密验证数据进行解密，得到第三握手验证数据，并对第三握手验证数据进行验证。
步骤447：服务器103确定第三握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第四握手验证数据，并利用服务器103的数据传输密钥，对第四握手验证数据进行加密，得到第四加密验证数据。
步骤448：服务器103将第四加密验证数据封装为Sever Verification报文并发送。
步骤449：网络中间设备101接收到服务器103发送的Sever Verification报文时，根据Sever Verification报文中的五元组，从对应的TCP流表中查找Connect协程的协程信息。
步骤450：网络中间设备101根据查找到的Connect协程的协程信息，唤醒Connect协程，利用服务器103的数据传输密钥，对Sever Verification报文中的第四加密验证数据进行解密，得到第四握手验证数据。
步骤451：网络中间设备101对第四握手验证数据进行验证，并在第四握手验证数据验证通过时，确定与服务器103的SSL连接建立完成。
步骤452：网络中间设备101挂起Connect协程。
步骤453：客户端102发送第一加密数据报文。
步骤454：网络中间设备101接收到客户端102发送的第一加密数据报文时，根据第一加密数据报文中的五元组，从对应的TCP流表中查找Accept协程的协程信息。
步骤455：网络中间设备101根据查找到的Accept协程的协程信息，唤醒Accept协程，利用与客户端102建立SSL连接时协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据。
步骤456：网络中间设备101对明文数据进行内容审计，并确定明文数据的内容审计通过的情况下，利用与服务器103建立SSL连接时协商的数据传输密钥，对明文数据进行加密，得到第二加密数据。
步骤457：网络中间设备101基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数。其中，步骤457的实现方式与上述描述方式相同，重复之处不再赘述。
步骤458：网络中间设备101将第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至服务器103。
步骤459：服务器103接收到第二加密数据报文时，利用服务器103的数据传输密钥，对第二加密数据报文中的第二加密数据进行解密，得到明文数据，并基于明文数据，生成响应数据。
步骤460：服务器103将响应数据作为明文数据，并利用服务器103的数据传输密钥，对明文数据进行加密，得到第一加密数据。
步骤461：服务器103将第一加密数据封装为第一加密数据报文并发送。
步骤462：网络中间设备101接收到服务器103发送的第一加密数据报文时，根据第一加密数据报文中的五元组，从对应的TCP流表中查找Connect协程的协程信息。
步骤463：网络中间设备101根据查找到的Connect协程的协程信息，唤醒Connect协程，利用与服务器103建立SSL连接时协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据。
步骤464：网络中间设备101对明文数据进行内容审计，并确定明文数据的内容审计通过的情况下，利用与客户端102建立SSL连接时协商的数据传输密钥，对明文数据进行加密，得到第二加密数据。
步骤465：网络中间设备101基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数。其中，步骤433的实现方式与上述描述方式相同，重复之处不再赘述。
步骤466：网络中间设备101将第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至客户端102进行处理。
本申请实施例中，客户端102接收到第二加密数据报文时，利用客户端102的数据传输密钥，对第二加密数据报文中的第二加密数据进行解密，得到明文数据后，可以根据实际需求，确定是否结束会话；若确定继续会话，则可以基于明文数据，生成响应数据，并将响应数据作为明文数据后，利用客户端102的数据传输密钥，对明文数据进行加密，得到第一加密数据，以及将第一加密数据封装为第一加密数据报文并返回步骤453，直至会话结束；若确定结束会话，则客户端102可以发起TCP连接关闭请求，网络中间设备101接收到TCP连接关闭请求时，可以通过修改TCP连接关闭请求中的可靠传输参数再重新封装发送至服务器103，使客户端102或服务器103之间的TCP连接断开，并进一步删除TCP流表中与该TCP连接对应的SSL会话数据、协程数据、可靠传输参数等各项数据，至此，本次TCP数据流的处理流程结束。当然，同样的，若服务器103根据实际需求，确定结束会话，则可以发起TCP连接关闭请求，网络中间设备101接收到TCP连接关闭请求时，可以通过修改TCP连接关闭请求中的可靠传输参数再重新封装发送至服务器103，使客户端102或服务器103之间的TCP连接断开，并进一步删除TCP流表中与该TCP连接对应的SSL会话数据、协程数据、可靠传输参数等各项数据，至此，本次TCP数据流的处理流程结束。
基于上述实施例，本申请实施例提供了一种报文处理装置，应用于网络中间设备101，参阅图5所示，本申请实施例提供的报文处理装置500至少包括：
连接建立单元501，用于通过透传TCP三次握手报文使客户端与服务器建立TCP连接，并基于TCP连接，分别与客户端和服务器建立SSL连接；
报文接收单元502，用于接收第一加密数据报文，其中，第一加密数据报文的发送端为客户端和服务器中的一个，接收端为客户端和服务器中的另一个；
数据解密单元503，用于利用与发送端建立SSL连接时协商的数据传输密钥，对第一加密数据报文中的第一加密数据进行解密，得到明文数据；
审计加密单元504，用于对明文数据进行内容审计，并确定明文数据的内容审计通过的情况下，利用与接收端建立SSL连接时协商的数据传输密钥，对明文数据进行加密，得到第二加密数据；
参数获取单元505，用于基于第二加密数据的数据长度和第一加密数据报文中的可靠传输参数，重新获得可靠传输参数；
数据封装单元506，用于将第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至接收端。
在一种可能的实施方式中，在通过透传TCP三次握手报文使客户端与服务器建立TCP连接时，连接建立单元501具体用于：
接收客户端向服务器发送的TCP连接请求报文，基于TCP连接请求报文中的五元组，建立TCP流表，将TCP连接请求报文中的序号和确认号记录至TCP流表，并将TCP连接请求报文透传至服务器；
接收服务器向客户端发送的TCP连接请求确认报文，将TCP连接请求确认报文中的序号和确认号记录至TCP流表，并将TCP连接请求确认报文透传至客户端；
接收客户端向服务器发送的TCP连接确认报文，将TCP连接确认报文中的序号和确认号记录至TCP流表，并将TCP连接确认报文透传至服务器；
确定客户端与服务器之间的TCP连接建立完成。
在一种可能的实施方式中，在基于TCP连接，分别与客户端和服务器建立SSL连接时，连接建立单元501具体用于：
接收客户端向服务器发送的客户端握手报文，并创建接受协程和连接协程；
通过接受协程模拟服务器与客户端建立SSL连接，并通过连接协程模拟客户端与服务器建立SSL连接。
在一种可能的实施方式中，在通过接受协程模拟服务器与客户端建立SSL连接时，连接建立单元501具体用于通过接受协程模拟服务器执行以下操作：
从客户端握手报文中，获取客户端支持的各个加密算法以及客户端生成的第一随机数，并从客户端支持的各个加密算法中，选取一个加密算法作为第一加密算法；
生成第二随机数，并基于第一加密算法、第二随机数和网络中间设备的私有证书，生成服务器握手数据；
基于服务器握手数据的长度和客户端握手报文中的可靠传输参数，重新获得可靠传输参数；
将服务器握手数据和重新获得的可靠传输参数封装为服务器握手报文发送至客户端；
接收客户端返回的客户端验证报文，其中，客户端验证报文是，客户端确定服务器握手报文中网络中间设备的私有证书的合法性验证通过时，利用网络中间设备的私有证书的公钥，对生成的第三随机数进行加密，得到加密随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端的数据传输密钥后，基于SSL连接过程中的所有会话数据，获得第一握手验证数据，以及利用客户端的数据传输密钥，对第一握手验证数据进行加密，得到第一加密验证数据并进行封装后获得的；
利用网络中间设备的私有证书的私钥，对客户端验证报文中的加密随机数进行解密，得到第三随机数，并基于第一随机数、第二随机数和第三随机数，生成客户端的数据传输密钥；
利用客户端的数据传输密钥，对客户端验证报文中的第一加密验证数据进行解密，得到第一握手验证数据，并对第一握手验证数据进行验证；
确定第一握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第二握手验证数据，并利用客户端的数据传输密钥，对第二握手验证数据进行加密，得到第二加密验证数据；
基于第二加密验证数据的长度和客户端验证报文中的可靠传输参数，重新获得可靠传输参数；
将第二加密验证数据和重新获得的可靠传输参数封装为服务器验证报文返回至客户端，以使客户端对服务器验证报文中的第二握手验证数据进行验证，并在服务器验证报文中的第二握手验证数据验证通过时，确定与客户端的SSL连接建立完成。
在一种可能的实施方式中，在通过连接协程模拟客户端与服务器建立SSL连接时，连接建立单元501具体用于通过连接协程模拟客户端执行以下操作：
生成第四随机数，并基于第四随机数和网络中间设备支持的各个加密算法，生成客户端握手数据；
基于客户端握手数据和客户端握手报文中的可靠传输参数，重新获得可靠传输参数，并将客户端握手数据和重新获得的可靠传输参数重新封装为客户端握手报文发送至服务器；
接收服务器返回的服务器握手报文，其中，服务器握手报文是，服务器从接收到的客户端握手报文中，获取第四随机数和网络中间设备支持的各个加密算法后，从网络中间设备支持的各个加密算法中，选取一个加密算法作为第二加密算法，并生成第五随机数时，对第二加密算法、第五随机数和服务器的私有证书进行封装后获得的；
从服务器握手报文中，获取服务器选择的第二加密算法、服务器生成的第五随机数和服务器的私有证书，并对服务器的私有证书进行合法性验证；
确定服务器的私有证书的合法性验证通过时，生成第六随机数，并利用服务器的私有证书的公钥，对第六随机数进行加密，得到加密随机数；
基于第四随机数、第五随机数和第六随机数，生成服务器的数据传输密钥，并基于SSL连接过程中的所有会话数据，获得第三握手验证数据，以及利用服务器的数据传输密钥，对第三握手验证数据进行加密，得到第三加密验证数据；
基于加密随机数和第三加密验证数据，生成客户端验证数据，并基于客户端验证数据的长度和服务器握手报文中的可靠传输参数，重新获得可靠传输参数，以及将客户端验证数据和重新获得的可靠传输参数封装为客户端验证报文返回至服务器；
接收服务器返回的服务器验证报文，其中，服务器验证报文是，服务器利用服务器的私有证书的私钥，对客户端验证报文中的加密随机数进行解密，得到第六随机数后，基于第四随机数、第五随机数和第六随机数，生成服务器的数据传输密钥，并利用服务器的数据传输密钥，对客户端验证报文中的第三加密验证数据进行解密，得到第三握手验证数据后，确定第三握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第四握手验证数据，并利用服务器的数据传输密钥，对第四握手验证数据进行加密，得到第四加密验证数据并进行封装后获得的；
利用服务器的数据传输密钥，对服务器验证报文中的第四加密验证数据进行解密，得到第四握手验证数据，对第四握手验证数据进行验证，并在第四握手验证数据验证通过时，确定与服务器的SSL连接建立完成。
在一种可能的实施方式中，可靠传输参数包括序号、确认号、TCP校验和以及IP校验和。
需要说明的是，本申请实施例提供的报文处理装置500解决技术问题的原理与本申请实施例提供的报文处理方法相似，因此，本申请实施例提供的报文处理装置500的实施可以参见本申请实施例提供的报文处理方法的实施，重复之处不再赘述。
在介绍了本申请实施例提供的报文处理方法和装置之后，接下来，对本申请实施例提供的报文处理设备进行简单介绍。
参阅图6所示，本申请实施例提供的报文处理设备600至少包括：处理器601、存储器602和存储在存储器602上并可在处理器601上运行的计算机程序，处理器601执行计算机程序时实现本申请实施例提供的报文处理方法。
需要说明的是，图6所示的报文处理设备600仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
本申请实施例提供的报文处理设备600还可以包括连接不同组件(包括处理器601和存储器602)的总线603。其中，总线603表示几类总线结构中的一种或多种，包括存储器总线、***总线、局域总线等。
存储器602可以包括易失性存储器形式的可读介质，例如随机存储器(RandomAccess Memory，RAM)6021和/或高速缓存存储器6022，还可以进一步包括只读存储器(ReadOnly Memory，ROM)6023。
存储器602还可以包括具有一组(至少一个)程序模块6024的程序工具6025，程序模块6024包括但不限于：操作子***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。
报文处理设备600也可以与一个或多个外部设备604(例如键盘、遥控器等)通信，还可以与一个或者多个使得用户能与报文处理设备600交互的设备通信(例如手机、电脑等)，和/或，与使得报文处理设备600与一个或多个其它报文处理设备600进行通信的任何设备(例如路由器、调制解调器等)通信。这种通信可以通过输入/输出(Input/Output，I/O)接口605进行。并且，报文处理设备600还可以通过网络适配器606与一个或者多个网络(例如局域网(Local Area Network，LAN)，广域网(Wide Area Network，WAN)和/或公共网络，例如因特网)通信。如图6所示，网络适配器606通过总线603与报文处理设备600的其它模块通信。应当理解，尽管图6中未示出，可以结合报文处理设备600使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、磁盘阵列(Redundant Arrays of Independent Disks，RAID)子***、磁带驱动器以及数据备份存储子***等。
接下来，对本申请实施例提供的计算机可读存储介质进行介绍，本申请实施例提供的计算机可读存储介质存储有计算机指令，计算机指令被处理器执行时实现本申请实施例提供的报文处理方法。具体地，该可执行程序可以内置或者安装在报文处理设备600中，这样，报文处理设备600就可以通过执行内置或者安装的可执行程序实现本申请实施例提供的报文处理方法。
此外，本申请实施例提供的报文处理方法还可以实现为一种程序产品，该程序产品包括程序代码，当该程序产品可以在报文处理设备600上运行时，该程序代码用于使报文处理设备600执行本申请实施例提供的报文处理方法。
本申请实施例提供的程序产品可以采用一个或多个可读介质的任意组合，其中，可读介质可以是可读信号介质或者可读存储介质，而可读存储介质可以是但不限于是电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合，具体地，可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、RAM、ROM、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、光纤、便携式紧凑盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。
本申请实施例提供的程序产品可以采用CD-ROM并包括程序代码，还可以在计算设备上运行。然而，本申请实施例提供的程序产品不限于此，在本申请实施例中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。
应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本申请的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。
此外，尽管在附图中以特定顺序描述了本申请方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请实施例进行各种改动和变型而不脱离本申请实施例的精神和范围。这样，倘若本申请实施例的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。
Claims (10)
1.一种报文处理方法，其特征在于，应用于网络中间设备，包括：
通过透传传输控制协议TCP三次握手报文使客户端与服务器建立TCP连接，并接收所述客户端向所述服务器发送的客户端握手报文，并创建接受协程和连接协程，通过所述接受协程模拟所述服务器与所述客户端建立SSL连接，并通过所述连接协程模拟所述客户端与所述服务器建立SSL连接；
接收第一加密数据报文，其中，所述第一加密数据报文的发送端为所述客户端和所述服务器中的一个，接收端为所述客户端和所述服务器中的另一个；
利用与所述发送端建立SSL连接时协商的数据传输密钥，对所述第一加密数据报文中的第一加密数据进行解密，得到明文数据；
对所述明文数据进行内容审计，并确定所述明文数据的内容审计通过的情况下，利用与所述接收端建立SSL连接时协商的数据传输密钥，对所述明文数据进行加密，得到第二加密数据；
基于所述第二加密数据的数据长度和所述第一加密数据报文中的可靠传输参数，重新获得可靠传输参数；
将所述第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至所述接收端；
其中，通过所述接受协程模拟所述服务器与所述客户端建立SSL连接，包括通过所述接受协程模拟所述服务器执行以下操作：
从所述客户端握手报文中，获取所述客户端支持的各个加密算法以及所述客户端生成的第一随机数，并从所述客户端支持的各个加密算法中，选取一个加密算法作为第一加密算法；
生成第二随机数，并基于所述第一加密算法、所述第二随机数和所述网络中间设备的私有证书，生成服务器握手数据；
基于所述服务器握手数据的长度和所述客户端握手报文中的可靠传输参数，重新获得可靠传输参数；
将所述服务器握手数据和重新获得的可靠传输参数封装为服务器握手报文发送至所述客户端；
接收所述客户端返回的客户端验证报文，其中，所述客户端验证报文是，所述客户端确定所述服务器握手报文中所述网络中间设备的私有证书的合法性验证通过时，利用所述网络中间设备的私有证书的公钥，对生成的第三随机数进行加密，得到加密随机数，并基于所述第一随机数、所述第二随机数和所述第三随机数，生成所述客户端的数据传输密钥后，基于SSL连接过程中的所有会话数据，获得第一握手验证数据，以及利用所述客户端的数据传输密钥，对所述第一握手验证数据进行加密，得到第一加密验证数据并进行封装后获得的；
利用所述网络中间设备的私有证书的私钥，对所述客户端验证报文中的所述加密随机数进行解密，得到所述第三随机数，并基于所述第一随机数、所述第二随机数和所述第三随机数，生成客户端的数据传输密钥；
利用所述客户端的数据传输密钥，对所述客户端验证报文中的所述第一加密验证数据进行解密，得到所述第一握手验证数据，并对所述第一握手验证数据进行验证；
确定所述第一握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第二握手验证数据，并利用所述客户端的数据传输密钥，对所述第二握手验证数据进行加密，得到第二加密验证数据；
基于所述第二加密验证数据的长度和所述客户端验证报文中的可靠传输参数，重新获得可靠传输参数；
将所述第二加密验证数据和重新获得的可靠传输参数封装为服务器验证报文返回至所述客户端，以使所述客户端对所述服务器验证报文中的所述第二握手验证数据进行验证，并在所述服务器验证报文中的所述第二握手验证数据验证通过时，确定与所述客户端的SSL连接建立完成。
2.如权利要求1所述的报文处理方法，其特征在于，通过透传TCP三次握手报文使所述客户端与所述服务器建立TCP连接，包括：
接收所述客户端向所述服务器发送的TCP连接请求报文，基于所述TCP连接请求报文中的五元组，建立TCP流表，将所述TCP连接请求报文中的序号和确认号记录至所述TCP流表，并将所述TCP连接请求报文透传至所述服务器；
接收所述服务器向所述客户端发送的TCP连接请求确认报文，将所述TCP连接请求确认报文中的序号和确认号记录至所述TCP流表，并将所述TCP连接请求确认报文透传至所述客户端；
接收所述客户端向所述服务器发送的TCP连接确认报文，将所述TCP连接确认报文中的序号和确认号记录至所述TCP流表，并将所述TCP连接确认报文透传至所述服务器；
确定所述客户端与所述服务器之间的TCP连接建立完成。
3.如权利要求1所述的报文处理方法，其特征在于，通过所述连接协程模拟所述客户端与所述服务器建立SSL连接，包括通过所述连接协程模拟所述客户端执行以下操作：
生成第四随机数，并基于所述第四随机数和所述网络中间设备支持的各个加密算法，生成客户端握手数据；
基于所述客户端握手数据和所述客户端握手报文中的可靠传输参数，重新获得可靠传输参数，并将所述客户端握手数据和重新获得的可靠传输参数重新封装为客户端握手报文发送至所述服务器；
接收所述服务器返回的服务器握手报文，其中，所述服务器握手报文是，所述服务器从接收到的客户端握手报文中，获取所述第四随机数和所述网络中间设备支持的各个加密算法后，从所述网络中间设备支持的各个加密算法中，选取一个加密算法作为第二加密算法，并生成第五随机数时，对所述第二加密算法、所述第五随机数和所述服务器的私有证书进行封装后获得的；
从所述服务器握手报文中，获取所述服务器选择的所述第二加密算法、所述服务器生成的所述第五随机数和所述服务器的私有证书，并对所述服务器的私有证书进行合法性验证；
确定所述服务器的私有证书的合法性验证通过时，生成第六随机数，并利用所述服务器的私有证书的公钥，对所述第六随机数进行加密，得到加密随机数；
基于所述第四随机数、所述第五随机数和所述第六随机数，生成所述服务器的数据传输密钥，并基于SSL连接过程中的所有会话数据，获得第三握手验证数据，以及利用所述服务器的数据传输密钥，对所述第三握手验证数据进行加密，得到第三加密验证数据；
基于所述加密随机数和所述第三加密验证数据，生成客户端验证数据，并基于所述客户端验证数据的长度和所述服务器握手报文中的可靠传输参数，重新获得可靠传输参数，以及将所述客户端验证数据和重新获得的可靠传输参数封装为客户端验证报文返回至所述服务器；
接收所述服务器返回的服务器验证报文，其中，所述服务器验证报文是，所述服务器利用所述服务器的私有证书的私钥，对所述客户端验证报文中的所述加密随机数进行解密，得到所述第六随机数后，基于所述第四随机数、所述第五随机数和所述第六随机数，生成所述服务器的数据传输密钥，并利用所述服务器的数据传输密钥，对所述客户端验证报文中的所述第三加密验证数据进行解密，得到所述第三握手验证数据后，确定所述第三握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第四握手验证数据，并利用所述服务器的数据传输密钥，对所述第四握手验证数据进行加密，得到第四加密验证数据并进行封装后获得的；
利用所述服务器的数据传输密钥，对所述服务器验证报文中的所述第四加密验证数据进行解密，得到所述第四握手验证数据，对所述第四握手验证数据进行验证，并在所述第四握手验证数据验证通过时，确定与所述服务器的SSL连接建立完成。
4.如权利要求1或3所述的报文处理方法，其特征在于，所述可靠传输参数包括序号、确认号、TCP校验和以及互联网协议IP校验和。
5.一种报文处理装置，其特征在于，包括：
连接建立单元，用于通过透传传输控制协议TCP三次握手报文使客户端与服务器建立TCP连接，并接收所述客户端向所述服务器发送的客户端握手报文，并创建接受协程和连接协程，通过所述接受协程模拟所述服务器与所述客户端建立SSL连接，并通过所述连接协程模拟所述客户端与所述服务器建立SSL连接；
报文接收单元，用于接收第一加密数据报文，其中，所述第一加密数据报文的发送端为所述客户端和所述服务器中的一个，接收端为所述客户端和所述服务器中的另一个；
数据解密单元，用于利用与所述发送端建立SSL连接时协商的数据传输密钥，对所述第一加密数据报文中的第一加密数据进行解密，得到明文数据；
审计加密单元，用于对所述明文数据进行内容审计，并确定所述明文数据的内容审计通过的情况下，利用与所述接收端建立SSL连接时协商的数据传输密钥，对所述明文数据进行加密，得到第二加密数据；
参数获取单元，用于基于所述第二加密数据的数据长度和所述第一加密数据报文中的可靠传输参数，重新获得可靠传输参数；
数据封装单元，用于将所述第二加密数据和重新获得的可靠传输参数封装为第二加密数据报文发送至所述接收端；
其中，在通过所述接受协程模拟所述服务器与所述客户端建立SSL连接时，所述连接建立单元具体用于通过所述接受协程模拟所述服务器执行以下操作：
从所述客户端握手报文中，获取所述客户端支持的各个加密算法以及所述客户端生成的第一随机数，并从所述客户端支持的各个加密算法中，选取一个加密算法作为第一加密算法；
生成第二随机数，并基于所述第一加密算法、所述第二随机数和网络中间设备的私有证书，生成服务器握手数据；
基于所述服务器握手数据的长度和所述客户端握手报文中的可靠传输参数，重新获得可靠传输参数；
将所述服务器握手数据和重新获得的可靠传输参数封装为服务器握手报文发送至所述客户端；
接收所述客户端返回的客户端验证报文，其中，所述客户端验证报文是，所述客户端确定所述服务器握手报文中所述网络中间设备的私有证书的合法性验证通过时，利用所述网络中间设备的私有证书的公钥，对生成的第三随机数进行加密，得到加密随机数，并基于所述第一随机数、所述第二随机数和所述第三随机数，生成所述客户端的数据传输密钥后，基于SSL连接过程中的所有会话数据，获得第一握手验证数据，以及利用所述客户端的数据传输密钥，对所述第一握手验证数据进行加密，得到第一加密验证数据并进行封装后获得的；
利用所述网络中间设备的私有证书的私钥，对所述客户端验证报文中的所述加密随机数进行解密，得到所述第三随机数，并基于所述第一随机数、所述第二随机数和所述第三随机数，生成客户端的数据传输密钥；
利用所述客户端的数据传输密钥，对所述客户端验证报文中的所述第一加密验证数据进行解密，得到所述第一握手验证数据，并对所述第一握手验证数据进行验证；
确定所述第一握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第二握手验证数据，并利用所述客户端的数据传输密钥，对所述第二握手验证数据进行加密，得到第二加密验证数据；
基于所述第二加密验证数据的长度和所述客户端验证报文中的可靠传输参数，重新获得可靠传输参数；
将所述第二加密验证数据和重新获得的可靠传输参数封装为服务器验证报文返回至所述客户端，以使所述客户端对所述服务器验证报文中的所述第二握手验证数据进行验证，并在所述服务器验证报文中的所述第二握手验证数据验证通过时，确定与所述客户端的SSL连接建立完成。
6.如权利要求5所述的报文处理装置，其特征在于，在通过透传TCP三次握手报文使所述客户端与所述服务器建立TCP连接时，所述连接建立单元具体用于：
接收所述客户端向所述服务器发送的TCP连接请求报文，基于所述TCP连接请求报文中的五元组，建立TCP流表，将所述TCP连接请求报文中的序号和确认号记录至所述TCP流表，并将所述TCP连接请求报文透传至所述服务器；
接收所述服务器向所述客户端发送的TCP连接请求确认报文，将所述TCP连接请求确认报文中的序号和确认号记录至所述TCP流表，并将所述TCP连接请求确认报文透传至所述客户端；
接收所述客户端向所述服务器发送的TCP连接确认报文，将所述TCP连接确认报文中的序号和确认号记录至所述TCP流表，并将所述TCP连接确认报文透传至所述服务器；
确定所述客户端与所述服务器之间的TCP连接建立完成。
7.如权利要求5所述的报文处理装置，其特征在于，在通过所述连接协程模拟所述客户端与所述服务器建立SSL连接时，所述连接建立单元具体用于通过所述连接协程模拟所述客户端执行以下操作：
生成第四随机数，并基于所述第四随机数和网络中间设备支持的各个加密算法，生成客户端握手数据；
基于所述客户端握手数据和所述客户端握手报文中的可靠传输参数，重新获得可靠传输参数，并将所述客户端握手数据和重新获得的可靠传输参数重新封装为客户端握手报文发送至所述服务器；
接收所述服务器返回的服务器握手报文，其中，所述服务器握手报文是，所述服务器从接收到的客户端握手报文中，获取所述第四随机数和所述网络中间设备支持的各个加密算法后，从所述网络中间设备支持的各个加密算法中，选取一个加密算法作为第二加密算法，并生成第五随机数时，对所述第二加密算法、所述第五随机数和所述服务器的私有证书进行封装后获得的；
从所述服务器握手报文中，获取所述服务器选择的所述第二加密算法、所述服务器生成的所述第五随机数和所述服务器的私有证书，并对所述服务器的私有证书进行合法性验证；
确定所述服务器的私有证书的合法性验证通过时，生成第六随机数，并利用所述服务器的私有证书的公钥，对所述第六随机数进行加密，得到加密随机数；
基于所述第四随机数、所述第五随机数和所述第六随机数，生成所述服务器的数据传输密钥，并基于SSL连接过程中的所有会话数据，获得第三握手验证数据，以及利用所述服务器的数据传输密钥，对所述第三握手验证数据进行加密，得到第三加密验证数据；
基于所述加密随机数和所述第三加密验证数据，生成客户端验证数据，并基于所述客户端验证数据的长度和所述服务器握手报文中的可靠传输参数，重新获得可靠传输参数，以及将所述客户端验证数据和重新获得的可靠传输参数封装为客户端验证报文返回至所述服务器；
接收所述服务器返回的服务器验证报文，其中，所述服务器验证报文是，所述服务器利用所述服务器的私有证书的私钥，对所述客户端验证报文中的所述加密随机数进行解密，得到所述第六随机数后，基于所述第四随机数、所述第五随机数和所述第六随机数，生成所述服务器的数据传输密钥，并利用所述服务器的数据传输密钥，对所述客户端验证报文中的所述第三加密验证数据进行解密，得到所述第三握手验证数据后，确定所述第三握手验证数据验证通过时，基于SSL连接过程中的所有会话数据，获得第四握手验证数据，并利用所述服务器的数据传输密钥，对所述第四握手验证数据进行加密，得到第四加密验证数据并进行封装后获得的；
利用所述服务器的数据传输密钥，对所述服务器验证报文中的所述第四加密验证数据进行解密，得到所述第四握手验证数据，对所述第四握手验证数据进行验证，并在所述第四握手验证数据验证通过时，确定与所述服务器的SSL连接建立完成。
8.如权利要求5或7所述的报文处理装置，其特征在于，所述可靠传输参数包括序号、确认号、TCP校验和以及互联网协议IP校验和。
9.一种报文处理设备，其特征在于，包括：存储器、处理器和存储在所述存储器上并可在所述处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现如权利要求1-4任一项所述的报文处理方法。
10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令被处理器执行时实现如权利要求1-4任一项所述的报文处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010411052.3A CN111628976B (zh) | 2020-05-15 | 2020-05-15 | 一种报文处理方法、装置、设备及介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010411052.3A CN111628976B (zh) | 2020-05-15 | 2020-05-15 | 一种报文处理方法、装置、设备及介质 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111628976A CN111628976A (zh) | 2020-09-04 |
| CN111628976B true CN111628976B (zh) | 2022-06-07 |
Family
ID=72261162
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010411052.3A Active CN111628976B (zh) | 2020-05-15 | 2020-05-15 | 一种报文处理方法、装置、设备及介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111628976B (zh) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112491921A (zh) * | 2020-12-07 | 2021-03-12 | 中国电子信息产业集团有限公司第六研究所 | 一种基于区块链的分布式网关数据保护***及保护方法 |
| CN113452757B (zh) * | 2021-06-03 | 2022-03-22 | 深信服科技股份有限公司 | 解密方法、终端设备及计算机可读存储介质 |
| CN113746755B (zh) * | 2021-07-30 | 2023-10-20 | 咪咕文化科技有限公司 | 数据处理方法、装置、设备及计算机可读存储介质 |
| CN114143061B (zh) * | 2021-11-25 | 2023-06-02 | 郑州信大信息技术研究院有限公司 | 基于用户态协议栈实现数据安全可靠传输的方法及*** |
| CN114139192B (zh) * | 2022-02-07 | 2022-07-05 | 奇安信科技集团股份有限公司 | 加密流量处理方法、装置、电子设备、介质及程序 |
| CN114553567B (zh) * | 2022-02-25 | 2024-02-06 | 蚂蚁区块链科技(上海)有限公司 | 多方安全计算中的网络传输方法、***、存储介质及计算设备 |
| CN114726575B (zh) * | 2022-03-02 | 2023-12-29 | 三未信安科技股份有限公司 | 一种检测加密流量关键数据的方法及*** |
| CN115189969B (zh) * | 2022-09-09 | 2023-01-03 | 北京安盟信息技术股份有限公司 | 一种网络加密通信方法、装置、介质及设备 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101515896A (zh) * | 2009-03-20 | 2009-08-26 | 成都市华为赛门铁克科技有限公司 | 安全套接字层协议报文转发方法、装置、***及交换机 |
| CN102263826A (zh) * | 2011-08-11 | 2011-11-30 | 华为技术有限公司 | 一种传输层建立连接的方法和装置 |
| CN105119894A (zh) * | 2015-07-16 | 2015-12-02 | 上海慧银信息科技有限公司 | 基于硬件安全模块的通信***及通信方法 |
| CN106302391A (zh) * | 2016-07-27 | 2017-01-04 | 上海华为技术有限公司 | 一种加密数据传输方法和代理服务器 |
| CN109413060A (zh) * | 2018-10-19 | 2019-03-01 | 深信服科技股份有限公司 | 报文处理方法、装置、设备及存储介质 |
| WO2019045424A1 (ko) * | 2017-08-29 | 2019-03-07 | 주식회사 수산아이앤티 | 보안을 위한 보안 소켓 계층 복호화 방법 |
| CN109802928A (zh) * | 2017-11-17 | 2019-05-24 | 中兴通讯股份有限公司 | 一种ssl/tls代理方法、装置、设备及存储介质 |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9680918B2 (en) * | 2014-06-30 | 2017-06-13 | Fortinet, Inc. | Socket application program interface (API) for efficient data transactions |
-
2020
- 2020-05-15 CN CN202010411052.3A patent/CN111628976B/zh active Active
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101515896A (zh) * | 2009-03-20 | 2009-08-26 | 成都市华为赛门铁克科技有限公司 | 安全套接字层协议报文转发方法、装置、***及交换机 |
| CN102263826A (zh) * | 2011-08-11 | 2011-11-30 | 华为技术有限公司 | 一种传输层建立连接的方法和装置 |
| CN105119894A (zh) * | 2015-07-16 | 2015-12-02 | 上海慧银信息科技有限公司 | 基于硬件安全模块的通信***及通信方法 |
| CN106302391A (zh) * | 2016-07-27 | 2017-01-04 | 上海华为技术有限公司 | 一种加密数据传输方法和代理服务器 |
| WO2019045424A1 (ko) * | 2017-08-29 | 2019-03-07 | 주식회사 수산아이앤티 | 보안을 위한 보안 소켓 계층 복호화 방법 |
| CN109802928A (zh) * | 2017-11-17 | 2019-05-24 | 中兴通讯股份有限公司 | 一种ssl/tls代理方法、装置、设备及存储介质 |
| CN109413060A (zh) * | 2018-10-19 | 2019-03-01 | 深信服科技股份有限公司 | 报文处理方法、装置、设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN111628976A (zh) | 2020-09-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111628976B (zh) | 一种报文处理方法、装置、设备及介质 | |
| US11502854B2 (en) | Transparently scalable virtual hardware security module | |
| US10785261B2 (en) | Techniques for secure session reestablishment | |
| US9172682B2 (en) | Local authentication in proxy SSL tunnels using a client-side proxy agent | |
| CN103763315B (zh) | 一种应用于移动设备云存储的可信数据存取控制方法 | |
| JP2018534884A (ja) | クライアント−クラウドまたはリモートサーバーの安全なデータまたはファイル・オブジェクト暗号化ゲートウェイ | |
| US20200351107A1 (en) | Secure authentication of remote equipment | |
| WO2019178942A1 (zh) | 一种进行ssl握手的方法和*** | |
| CN101304310B (zh) | 一种加固网络ssl服务的方法 | |
| WO2012088889A1 (zh) | 基于浏览器的数据通讯方法、设备和数据交互*** | |
| CN111756751B (zh) | 报文传输方法、装置及电子设备 | |
| US20030016819A1 (en) | Secure socket layer (SSL) load generation with handshake replay | |
| CN111600914B (zh) | 一种数据传输方法、服务端和客户端 | |
| CN107172001B (zh) | 网站代理服务器的控制方法及装置、密钥代理服务器 | |
| Hou et al. | Design and prototype implementation of a blockchain-enabled LoRa system with edge computing | |
| WO2004042537A2 (en) | System and method for securing digital messages | |
| US9961055B1 (en) | Inaccessibility of data to server involved in secure communication | |
| US20080306875A1 (en) | Method and system for secure network connection | |
| US10218682B1 (en) | Secure network protocol cryptographic processing | |
| Huang et al. | Implementing publish/subscribe pattern for CoAP in fog computing environment | |
| CN114553957B (zh) | 兼容国密和国际https传输的业务***和方法 | |
| CN211352206U (zh) | 基于量子密钥分发的IPSec VPN密码机 | |
| JP2007036389A (ja) | Ｔｌｓセッション情報の引継ぎ方法及びコンピュータシステム | |
| CN114301967B (zh) | 窄带物联网控制方法、装置及设备 | |
| CN116248268A (zh) | 国密握手请求的处理方法、设备及可读存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |