加密报文的检测方法及防护设备与流程

加密报文的检测方法及防护设备
1.本技术要求于2020年10月26日提交的申请号为202011155469.4、发明名称为“一种加密流量的处理方法及相关装置”的中国专利申请的优先权，其全部内容通过引用结合在本技术中。
技术领域
2.本技术涉及通信技术领域，特别涉及一种加密报文的检测方法及防护设备。


背景技术：

3.在具有多层结构的tcp/ip协议族(tcp/ip protocol suite，或tcp/ip protocols)中，安全套接层/传输层安全(secure socket layer/transport layer security，ssl/tls)位于超文本传输协议(hyper text transfer protocol，http)协议和传输控制协议(transmission control protocol，tcp)协议之间。使用https(基于tls的http，http over tls)进行交互的流量，首先需要像普通http流量一样，建立一条tcp连接，然后需要在这条tcp连接之上，进行ssl/tls握手，建立ssl/tls会话，然后使用ssl/tls会话对http交互内容进行加密，保证数据传输的隐私性、可靠性以及可信性。
4.当客户端与服务器基于ssl/tls传输加密报文时，部署在客户端与服务器之间的防火墙如何对加密报文进行安全性检测成为一个亟需解决的问题。目前主流的解决方案是基于ssl/tls中间人(man-in-the-middle)技术的检测方案。
5.ssl/tls中间人技术的基本原理是，防火墙作为代理服务器和客户端进行ssl/tls握手。同时，防火墙作为代理客户端和服务器进行ssl/tls握手。
6.相关技术在实现ssl/tls中间人技术时，防火墙会作为ssl/tls会话的端点，分别独立的和服务器、客户端设备完成ssl握手。采用上述方法时，防火墙在分别与服务器、客户端设备协商各种加密的密钥、加密参数的过程涉及巨大计算量，这导致防火墙资源占用过多，性能低下。


技术实现要素：

7.本技术实施例提供了一种加密报文的检测方法及防护设备，有助于减少设备资源占用，提升设备性能。所述技术方案如下。
8.第一方面，提供了一种加密报文的检测方法，在该方法中，防护设备向客户端设备和服务器分别发送中间人迪菲-赫尔曼(diffie-hellman，dh)参数，所述防护设备部署于所述客户端设备和所述服务器之间，所述中间人dh参数为所述防护设备生成的dh参数；所述防护设备根据所述中间人dh参数以及客户端dh参数，生成第一会话秘钥，所述客户端dh参数为所述客户端设备生成的dh参数；所述防护设备根据所述中间人dh参数以及服务器dh参数，生成第二会话秘钥，所述服务器dh参数为所述服务器生成的dh参数；所述防护设备接收原始加密报文；如果所述原始加密报文来自于所述客户端设备，所述防护设备使用所述第一会话秘钥对所述原始加密报文进行解密，对解密得到的明文数据进行检测，并使用所述
第二会话秘钥对检测后的数据进行加密得到目标加密报文，向所述服务器发送所述目标加密报文；或，如果所述原始加密报文来自于所述服务器，所述防护设备使用所述第二会话秘钥对所述原始加密报文进行解密，对解密得到的明文数据进行检测，并使用所述第一会话秘钥对检测后的数据进行加密得到目标加密报文，向所述客户端设备发送所述目标加密报文。
9.第一方面提供的方法，将防护设备与客户端设备之间的ssl握手流程、防护设备与服务器之间的ssl握手流程关联起来，防护设备将同一份dh参数分别发给客户端设备以及服务器，并在生成会话密钥时复用两侧的dh参数，从而减少生成dh参数带来的计算量，节省对防火墙等防护设备的资源占用，有助于大幅提升ssl握手速度，提升防护设备的性能。
10.可选地，所述防护设备向客户端设备和服务器分别发送中间人dh参数，包括：所述防护设备接收来自于所述客户端设备的原始客户端密钥交换报文；所述防护设备将所述原始客户端密钥交换报文中的所述客户端dh参数替换为所述中间人dh参数，从而得到目标客户端密钥交换报文；所述防护设备向所述服务器发送所述目标客户端密钥交换报文；所述防护设备接收来自于所述服务器的原始服务器密钥交换报文；所述防护设备将所述原始服务器密钥交换报文中的所述服务器dh参数替换为所述中间人dh参数，从而得到目标服务器密钥交换报文；所述防护设备向所述客户端设备发送所述目标服务器密钥交换报文。
11.通过这种可选方式，使用真实客户端和服务器的握手过程进行驱动，防护设备在两侧发来的握手报文的基础上只需要生成较少的参数、执行报文解析和内容替换，即可实现与两侧的握手，可见减少了大量资源开销。
12.可选地，所述防护设备得到目标服务器密钥交换报文之前，所述方法还包括：所述防护设备将所述原始服务器密钥交换报文中的服务器签名替换为中间人签名，所述中间人签名是使用所述防护设备的私钥对所述中间人dh参数进行签名得到的。
13.通过这种可选方式，防护设备通过将服务器签名替换为中间人签名，使得中间人dh参数随着中间人签名一起传给客户端设备，降低由于签名验证不通过而传输失败的概率，有助于提高传输中间人dh参数的成功率。
14.可选地，所述防护设备根据所述中间人dh参数以及客户端dh参数，生成第一会话秘钥，包括：所述防护设备使用所述中间人dh参数以及所述客户端dh参数，生成第一预主秘钥；所述防护设备使用所述第一预主秘钥、客户端随机数以及服务器随机数，生成所述第一会话秘钥，所述客户端随机数为所述客户端设备生成的随机数，所述服务器随机数为所述服务器生成的随机数；所述防护设备使用所述中间人dh参数以及服务器dh参数，生成第二会话秘钥，包括：所述防护设备使用所述中间人dh参数以及所述服务器dh参数，生成第二预主秘钥；所述防护设备使用所述第二预主秘钥、所述客户端随机数以及所述服务器随机数，生成所述第二会话秘钥。
15.通过这种可选方式，防护设备通过在生成会话密钥时复用客户端设备以及服务器生成的随机数，免去独立生成随机数带来的开销。
16.可选地，所述客户端随机数是所述防护设备从原始客户端问候报文提取到的，所述服务器随机数是所述防护设备从原始服务器问候报文提取到的。
17.通过这种可选方式，防护设备从收到的原始问候报文即可获得随机数，降低了实现复杂度。
18.可选地，所述防护设备向客户端设备和服务器分别发送中间人dh参数之前，所述方法还包括：所述防护设备接收来自于所述客户端设备的原始客户端问候报文，所述原始客户端问候报文包括算法列表；所述防护设备从所述原始客户端问候报文中删除所述算法列表中第一算法的标识，从而得到目标客户端问候报文，所述第一算法为所述防护设备不支持的算法；所述防护设备向所述服务器发送所述目标客户端问候报文。
19.通过这种可选方式，兼顾了安全性和兼容性，灵活性高。
20.可选地，所述防护设备使用所述第一会话秘钥对所述原始加密报文进行解密，包括：所述防护设备通过第二算法，使用所述第一会话秘钥对所述原始加密报文进行解密，所述第二算法为从所述算法列表中删除所述第一算法的标识之后剩余的算法标识对应的算法；所述使用所述第二会话秘钥对检测后的数据进行加密得到目标加密报文，包括：通过所述第二算法，使用所述第二会话秘钥对检测后的数据进行加密得到目标加密报文；所述防护设备使用所述第二会话秘钥对所述原始加密报文进行解密，包括：所述防护设备通过所述第二算法，使用所述第二会话秘钥对所述原始加密报文进行解密；所述使用所述第一会话秘钥对检测后的数据进行加密得到目标加密报文，包括：通过所述第二算法，使用所述第一会话秘钥对检测后的数据进行加密得到目标加密报文。
21.通过这种可选方式，保证客户端、防护设备以及服务器这三方在数据传输阶段使用三方都支持的算法对数据加解密，避免由于防护设备不支持解密所需的算法而导致安全检测失败。
22.可选地，防护设备向客户端设备和服务器分别发送中间人dh参数之前，所述方法还包括：所述防护设备接收来自于所述服务器的原始服务器问候报文；所述防护设备将所述原始服务器问候报文中的服务器证书替换为中间人证书，从而得到目标服务器问候报文，所述服务器证书包括所述服务器的公钥，所述中间人证书包括所述防护设备的公钥；所述防护设备向所述客户端设备发送所述目标服务器问候报文。
23.通过这种可选方式，防护设备通过替换服务器的证书，保证中间人签名通过客户端设备的验证，从而避免随着中间人签名一起传给客户端设备的数据(如中间人dh参数)由于签名验证不通过而传输失败。
24.可选地，所述防护设备包括硬件加速器，所述硬件加速器用于生成所述中间人dh参数、生成会话秘钥、对所述原始加密报文进行解密、或对所述检测后的数据进行加密；若所述硬件加速器用于生成所述会话秘钥，所述防护设备根据所述中间人dh参数以及客户端dh参数，生成第一会话秘钥，包括：所述防护设备将所述中间人dh参数以及所述客户端dh参数输入所述硬件加速器，接收所述硬件加速器生成的第一会话秘钥；所述防护设备根据所述中间人dh参数以及服务器dh参数，生成第二会话秘钥，包括：所述防护设备将所述中间人dh参数以及所述服务器dh参数输入所述硬件加速器，接收所述硬件加速器生成的第二会话秘钥；若所述硬件加速器用于对所述原始加密报文进行解密，所述防护设备使用所述第一会钥对所述原始加密报文进行解密，包括：所述防护设备将所述第一会话秘钥以及所述原始加密报文输入所述硬件加速器，接收所述硬件加速器解密得到的明文数据；所述防护设备使用所述第二会话秘钥对所述原始加密报文进行解密，包括：所述防护设备将所述第二会话秘钥以及所述原始加密报文输入所述硬件加速器，接收所述硬件加速器解密得到的明文数据；若所述硬件加速器用于对所述检测后的数据进行加密，所述使用所述第二会话秘
钥对所述检测后的数据进行加密，包括：所述防护设备将所述第二会话秘钥以及所述检测后的数据输入所述硬件加速器，接收所述硬件加速器加密得到的目标加密报文；所述使用所述第一会话秘钥对所述检测后的数据进行加密，包括：所述防护设备将所述第一会话秘钥以及所述检测后的数据输入所述硬件加速器，接收所述硬件加速器加密得到的目标加密报文。
25.通过这种可选方式，消耗性能的算法部分采用专用加速硬件处理，极大改善资源占用，大幅提升性能。
26.第二方面，提供了一种防护设备，该防护设备具有实现上述第一方面或第一方面任一种可选方式的功能。该防护设备包括至少一个单元，至少一个单元用于实现上述第一方面或第一方面任一种可选方式所提供的方法。
27.在一些实施例中，防护设备中的单元通过软件实现，防护设备中的单元是程序模块。在另一些实施例中，防护设备中的单元通过硬件或固件实现。第二方面提供的防护设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。
28.第三方面，提供了一种防护设备，该防护设备包括处理器和通信接口，该处理器用于执行指令，使得该防护设备执行上述第一方面或第一方面任一种可选方式所提供的方法，所述通信接口用于接收或发送报文。第三方面提供的防护设备的具体细节可参见上述第一方面或第一方面任一种可选方式，此处不再赘述。
29.第四方面，提供了一种计算机可读存储介质，该存储介质中存储有至少一条指令，该指令在计算机上运行时，使得计算机执行上述第一方面或第一方面任一种可选方式所提供的方法。
30.第五方面，提供了一种计算机程序产品，所述计算机程序产品包括一个或多个计算机程序指令，当所述计算机程序指令被计算机加载并运行时，使得所述计算机执行上述第一方面或第一方面任一种可选方式所提供的方法。
31.第六方面，提供了一种芯片，包括存储器和处理器，存储器用于存储计算机指令，处理器用于从存储器中调用并运行该计算机指令，以执行上述第一方面及其第一方面任意可能的实现方式中的方法。
32.第七方面，提供了一种网络系统，该网络系统包括防护设备，该网络系统还包括客户端设备或者服务器，该防护设备用于执行上述第一方面或第一方面任一种可选方式所述的方法。
附图说明
33.图1是本技术实施例提供的一种ssl/tls在协议族中位置的示意图；
34.图2是本技术实施例提供的一种通信双方进行ssl/tls握手的流程图；
35.图3是本技术实施例提供的一种基于ssl/tls中间人代理的检测方案的流程图；
36.图4是本技术实施例提供的一种典型应用场景的示意图；
37.图5是本技术实施例提供的一种防护设备的结构示意图；
38.图6是本技术实施例提供的一种加密报文的检测方法的流程图；
39.图7是本技术实施例提供的一种通信三方交互密钥交换报文的流程图；
40.图8是本技术实施例提供的一种加密报文的检测方法的流程图；
41.图9是本技术实施例提供的一种通信三方交互问候报文的流程图；
42.图10是本技术实施例提供的一种基于ssl/tls中间人代理的检测方案的流程图；
43.图11是本技术实施例提供的一种防护设备的结构示意图。
具体实施方式
44.为使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术实施方式作进一步地详细描述。
45.互联网中ssl/tls加密流量所占的比重越来越多。根据谷歌(google)的相关统计，约90％的流量都是超文本传输安全协议(hypertext transfer protocol secure，https)流量，其中https也被称为http over tls。当前绝大部分网络安全检测技术，是基于对流量的深度识别与解析进行检测的。如果不能解密获得明文，大部分网络安全技术将失效。对于防护设备来说，如何检测加密流量成为热点问题。
46.参考附图1，在具有多层结构的tcp/ip协议族中，ssl/tls位于http协议和tcp协议之间。对于使用https进行交互的流量，通信双方首先需要像普通http流量一样，建立一条传输控制协议(transmission control protocol，tcp)连接。然后通信双方需要在这条tcp连接之上，进行ssl/tls握手，建立ssl/tls会话，然后使用ssl/tls会话对http交互内容进行加密，保证数据传输的隐私性以及可靠、可信。
47.ssl/tls会话主要分为两个阶段：握手阶段和数据传输阶段。
48.在握手阶段，ssl/tls会话的两端设备基于非对称加密(也叫公开秘钥加密)和秘钥协商算法，协商出安全可靠的后续数据传输阶段使用的会话秘钥。
49.在数据传输阶段，ssl/tls会话的两端设备使用握手阶段协商出的算法和会话秘钥，对应用层(如http)数据加密后传输。数据传输阶段也称对称加密处理阶段。
50.这里重点需要关注的是秘钥协商的过程。秘钥协商有很多算法，这些算法大多基于复杂的数学理论，需要大量数学运算。其中，迪菲-赫尔曼(diffie-hellman，dh)算法使用最为广泛。dh算法包括椭圆曲线dh(elliptic curve diffie
–
hellman，ecdh)算法。dh算法能够让通信双方在预先没有对方任何信息的条件下通过不安全信道创建起一个密钥；使用dh算法进行协商的通信双方各自生成dh参数。为简化理解，可将通信双方各自的dh参数分为两部分：公开部分(pub key)和私有部分(private key)。通信双方交换dh参数的公开部分。dh算法保证通信双方使用自己的dh参数(公开部分和私有部分)加上对端dh参数的公开部分，能够计算出一致的秘密(即用于最终生成会话秘钥的关键信息)；而任何第三方，仅仅依靠通信双方公开的dh参数的公开部分无法计算获得这一秘密。
51.请参考附图2，以采用ecdh算法为例，在没有中间人参与的情况下，通信双方的ssl/tls握手过程如附图2所示，包括以下步骤s11至步骤s14。
52.步骤s11、客户端设备向服务器发送客户端问候(client hello)报文，client hello报文包括客户端随机数、客户端支持的版本和算法列表。
53.步骤s12、服务器向客户端设备发送服务器随机数和服务器证书。服务器证书包括服务器的公钥。
54.步骤s13、服务器向客户端设备发送服务器dh参数和服务器签名。其中，服务器签名是服务器使用私钥对客户端随机数、服务器随机数和服务器dh参数进行签名得到的。
55.步骤s14、客户端设备向服务器发送客户端dh参数。
56.之后，客户端设备和服务器这两侧分别使用客户端dh参数和服务器dh参数产生相同的预主秘钥。客户端设备和服务器这两侧分别使用预主秘钥、客户端随机数和服务器随机数生成最终使用的会话秘钥。
57.当防火墙设备等防护设备位于客户端设备和服务器之间的网络时，防护设备为了对客户端设备与服务器之间传输的加密报文检测，防护设备需要对加密流量进行解密。目前主流的解决方案是基于ssl/tls中间人代理的检测方案。ssl/tls中间人代理技术，顾名思义，防护设备需要作为代理服务器和客户端设备进行ssl/tls握手。同时，防护设备作为代理客户端和服务器进行ssl/tls握手。
58.在一些研究中，尝试由防护设备作为ssl/tls会话的端点，防护设备分别独立的和实际服务器、实际客户端完成握手。防护设备进行握手所需的信息都依赖于ssl库软件自动生成，ssl库软件例如openssl(一个开放源代码的软件库包)。具体地，请参考附图3，附图3示出了这种基于ssl/tls中间人代理的检测方案的流程图，附图3所示的方法包括以下步骤s21至步骤s28。附图3所示的流程中，防护设备进行握手时需要中间人dh参数1、中间人dh参数2、中间人随机数1以及中间人随机数2，中间人dh参数1、中间人dh参数2、中间人随机数1以及中间人随机数2都依赖于通过ssl库软件执行复杂计算生成。
59.步骤s21、客户端设备向服务器发送client hello报文。client hello报文包括客户端随机数、支持的版本和算法列表。
60.步骤s22、防护设备接收client hello报文。防护设备从client hello报文提取客户端随机数，根据预先配置的算法列表，使用openssl向服务器发起握手。
61.步骤s23、服务器向客户端设备发送服务器随机数和服务器证书，防护设备接收服务器随机数和服务器证书。服务器证书包括服务器的公钥。
62.步骤s24、服务器向客户端设备发送服务器dh参数和服务器签名。服务器签名是服务器使用私钥对客户端随机数、服务器随机数和服务器dh参数进行签名得到的。
63.步骤s25、防护设备向服务器发送中间人dh参数1。
64.之后，服务器和防护设备使用双方dh参数(中间人dh参数1和服务器dh参数)，生成相同的预主秘钥1。之后，服务器和防护设备使用预主秘钥1、中间人随机数1、服务器随机数生成相同的会话秘钥1。
65.步骤s26、防护设备获得服务器证书后，防护设备重新签发新的证书(中间人证书)，使用openssl和客户端设备继续握手。
66.步骤s27、防护设备向客户端设备发送中间人dh参数2和中间人签名。
67.步骤s28、客户端设备向服务器发送客户端dh参数，防护设备接收客户端dh参数。
68.之后，客户端设备和防护设备使用双方dh参数(客户端dh参数和中间人dh参数2)，生成相同的预主秘钥2。之后，客户端设备和防护设备双方使用预主秘钥、客户端随机数、中间人随机数2生成相同的会话秘钥2。
69.在研究过程中发现，附图3所示的ssl/tls中间人方案不尽完善。一方面，从效率的角度考虑，附图3所示方案中，防护设备进行ssl/tls握手时需要依赖openssl或者其他开源软件，这类开源软件普遍存在性能低下、资源占用高等问题。具体地，整个ssl握手交互过程中涉及很多的参数，这些参数在附图3所示方案中，防护设备都是通过openssl生成和维护
的。从防护设备的角度来看，最好是能实现上述参数的复用，例如直接复用客户端设备或者服务器生成的参数，而不自己生成。但是附图3所示的方案中，防护设备与两端的交互流程彼此割裂而没有关联性，握手所需的参数都由ssl库软件生成，而不能做到参数的复用。此外，通信各方需要各自完成复杂计算以获得不对称秘钥，导致运算开销巨大。另一方面，从安全与兼容性的角度考虑，附图3所示方案可能因为握手阶段协商出不安全的算法，导致数据传输阶段的安全性降低。而如果强制配置安全性高的算法，则可能会引入兼容性问题：原本客户端设备和服务器能够使用一种满足需求的较低安全性算法进行协商，引入防护设备作为中间人后，导致协商失败。
70.有鉴于附图3所示方案中的安全与兼容性问题以及效率差的问题，本技术实施例提出一种无状态的ssl中间人方案，将防护设备与两端的交互流程关联起来，实现了通信双方参数的复用，减少防护设备独立生成参数带来的计算量，从而节省防护设备的资源占用，有助于大幅提升作为ssl中间人代理的防护设备的处理效率。
71.以下结合附图4介绍本技术实施例提供的应用场景。
72.请参考图4，图4是本技术实施例提供的一种典型应用场景的示意图。应用场景包括客户端设备31、服务器32以及防护设备33。下面对客户端设备31、服务器32以及防护设备33分别进行描述。
73.(1)客户端设备31
74.客户端设备31为互联网中发起访问的设备。例如，客户端设备31是已安装浏览器软件的终端设备。客户端设备31包括但不限于个人计算机、移动电话、服务器、笔记本电脑、ip电话、摄像头、平板电脑、可穿戴设备等。例如，客户端设备31为企业内部员工的办公设备。在实际网络系统中，可选地有大量客户端设备，为了简明起见，为了简明起见，图4以一个客户端设备31的情况为例进行说明。
75.(2)服务器32
76.服务器32为互联网中提供服务的设备。例如，服务器32为网页服务器，服务器32用于为客户端设备31中的浏览器软件提供访问网页所需的资源。又如，服务器32为金融服务器，服务器32用于为客户端设备31中的金融客户端软件提供个人金融服务(如银行账户管理、购买金融产品等等)所需的资源。
77.上述客户端设备31和服务器32之间的数据传输可能是双向的，既可能是客户端设备31向服务器32发送数据，也可能是服务器32向客户端设备31发送数据。
78.(3)防护设备33
79.防护设备33部署于客户端设备31与服务器32之间。防护设备33的部署方式包括而不限于直路部署、旁路部署等。防护设备33与客户端设备31与服务器32分别通过网络相连。
80.防护设备33用于对网络中的访问流量实现ssl/tls中间人代理，并对加密流量本地解密后进行安全检测。安全检测包括而不限于入侵防御系统(intrusion prevention system，ips)检测、防病毒(anti virus，av)检测等。防护设备33包括而不限于防火墙、入侵检测系统(intrusion detection system，ids)类设备、ips类设备、安全网关、统一威胁管理(unified threat management，utm)设备、服务器、主机或个人计算机等等。
81.可选地，防护设备33包括ssl/tls代理模块331以及tcp/ip协议栈模块332。ssl/tls代理模块331用于实现ssl/tls代理中的处理任务，例如代替客户端与服务器进行ssl/
tls握手，代替服务器与客户端进行ssl/tls握手等。tcp/ip协议栈模块332用于基于tcp/ip协议传输报文。
82.可选地，防护设备还包括加解密加速器333。加解密加速器333用于通过算法硬件化的手段对涉及生成加密参数、生成会话秘钥、加密或解密的步骤进行加速，从而提升防护设备的性能。
83.附图5是本技术实施例提供的一种防护设备的结构示意图。可选地，具有附图5所示结构的防护设备是附图4中的防护设备33。
84.参见附图5，附图5示出了本技术一个示例性实施例提供的防护设备400的结构示意图，该防护设备400由一般性的总线体系结构来实现。
85.防护设备400包括至少一个处理器401、通信总线402、存储器403以及至少一个网络接口404。
86.处理器401例如是通用中央处理器(central processing unit，cpu)、网络处理器(network processer，np)、图形处理器(graphics processing unit，gpu)、神经网络处理器(neural-network processing units，npu)、数据处理单元(data processing unit，dpu)、微处理器或者一个或多个用于实现本技术方案的集成电路。例如，处理器401包括专用集成电路(application-specific integrated circuit，asic)，可编程逻辑器件(programmable logic device，pld)或其组合。pld例如是复杂可编程逻辑器件(complex programmable logic device，cpld)、现场可编程逻辑门阵列(field-programmable gate array，fpga)、通用阵列逻辑(generic array logic，gal)或其任意组合。
87.通信总线402用于在上述组件之间传送信息。通信总线402可以分为地址总线、数据总线、控制总线等。为便于表示，附图5中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
88.存储器403中保存有实现本技术方法实施例的程序代码410。存储器403例如是只读存储器(read-only memory，rom)或可存储静态信息和指令的其它类型的静态存储设备，又如是随机存取存储器(random access memory，ram)或者可存储信息和指令的其它类型的动态存储设备，又如是电可擦可编程只读存储器(electrically erasable programmable read-only memory，eeprom)、只读光盘(compact disc read-only memory，cd-rom)或其它光盘存储、光碟存储(包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等)、磁盘存储介质或者其它磁存储设备，或者是能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其它介质，但不限于此。存储器403例如是独立存在，并通过通信总线402与处理器401相连接。存储器403也可以和处理器401集成在一起。
89.网络接口404使用任何收发器一类的装置，用于与其它设备或通信网络通信。网络接口404包括有线通信接口，还可以包括无线通信接口。其中，有线通信接口例如可以为以太网接口。以太网接口可以是光接口，电接口或其组合。无线通信接口可以为无线局域网(wireless local area networks，wlan)接口，蜂窝网络通信接口或其组合等。
90.在具体实现中，作为一种实施例，处理器401可以包括一个或多个cpu，如附图5中所示的cpu0和cpu1。
91.可选地，防护设备400还包括硬件加速器405。硬件加速器405用于生成中间人dh参
数、生成会话秘钥、对原始加密报文进行解密、或对检测后的数据进行加密。硬件加速器405通过算法硬件化的手段加速这些步骤的执行。硬件加速器405支持至少一种算法。硬件加速器405支持的算法包括而不限于ssl/tls通信流程在会话协商阶段生成dh参数、会话秘钥、随机数等使用的算法，以及ssl/tls通信流程在数据传输阶段加密以及解密时使用的算法。例如，硬件加速器405支持dh算法(如ecdh算法)等。在一些实施例中，硬件加速器405包括加解密处理器。硬件加速器405包括而不限于现场可编程门阵列(field programmable gate array，fpga)、专用集成芯片(application specific integrated circuit，asic)、系统芯片(system on chip，soc)、中央处理器(central processor unit，cpu)、网络处理器(network processor，np)、数字信号处理电路(digital signal processor，dsp)、微控制器(micro controller unit，mcu)、可编程控制器(programmable logic device，pld)或其他集成芯片。
92.处理器401和硬件加速器405中的每一个例如是一个单核处理器(single-cpu)，又如是一个多核处理器(multi-cpu)。这里的处理器可以指一个或多个设备、电路、和/或用于处理数据(如计算机程序指令)的处理核。
93.在具体实现中，作为一种实施例，防护设备400还可以包括输出设备和输入设备。输出设备和处理器401通信，可以以多种方式来显示信息。例如，输出设备可以是液晶显示器(liquid crystal display，lcd)、发光二级管(light emitting diode，led)显示设备、阴极射线管(cathode ray tube，crt)显示设备或投影仪(projector)等。输入设备和处理器401通信，可以以多种方式接收用户的输入。例如，输入设备可以是鼠标、键盘、触摸屏设备或传感设备等。
94.在附图6描述的流程中，处理器401，用于读取存储器403中存储的程序代码410后，执行以下操作：处理器401指示网络接口404向客户端设备和服务器分别发送中间人dh参数，中间人dh参数为处理器401或者硬件加速器405生成的dh参数；处理器401根据中间人dh参数以及客户端dh参数，生成第一会话秘钥；处理器401根据中间人dh参数以及服务器dh参数，生成第二会话秘钥；网络接口404，用于接收原始加密报文；如果原始加密报文来自于客户端设备，处理器401使用第一会话秘钥对原始加密报文进行解密，对解密得到的明文数据进行检测，并使用第二会话秘钥对检测后的数据进行加密得到目标加密报文，处理器401指示网络接口404向服务器发送目标加密报文；或，如果原始加密报文来自于服务器，处理器401使用第二会话秘钥对原始加密报文进行解密，对解密得到的明文数据进行检测，并使用第一会话秘钥对检测后的数据进行加密得到目标加密报文，处理器401指示网络接口404向客户端设备发送目标加密报文。
95.在一些实施例中，网络接口404，用于接收来自于客户端设备的原始客户端密钥交换报文；处理器401用于读取存储器403中存储的程序代码410后，执行以下操作：将原始客户端密钥交换报文中的客户端dh参数替换为中间人dh参数，从而得到目标客户端密钥交换报文；处理器401指示网络接口404向服务器发送目标客户端密钥交换报文；
96.在一些实施例中，网络接口404，用于接收来自于服务器的原始服务器密钥交换报文；处理器401用于读取存储器403中存储的程序代码410后，执行以下操作：将原始服务器密钥交换报文中的服务器dh参数替换为中间人dh参数，从而得到目标服务器密钥交换报文；指示网络接口404向客户端设备发送目标服务器密钥交换报文。
97.在一些实施例中，处理器401，还用于将原始服务器密钥交换报文中的服务器签名替换为中间人签名。
98.在一些实施例中，处理器401，读取存储器403中存储的程序代码410后，执行以下操作：使用中间人dh参数以及客户端dh参数，生成第一预主秘钥；使用第一预主秘钥、客户端随机数以及服务器随机数，生成第一会话秘钥；使用中间人dh参数以及服务器dh参数，生成第二预主秘钥；使用第二预主秘钥、客户端随机数以及服务器随机数，生成第二会话秘钥。
99.在一些实施例中，处理器401，用于从网络接口404接收到的原始客户端问候报文提取客户端随机数，从网络接口404接收到的原始服务器问候报文提取服务器随机数。
100.在一些实施例中，网络接口404，用于接收来自于客户端设备的原始客户端问候报文；处理器401读取存储器403中存储的程序代码410后，执行以下操作：从原始客户端问候报文中删除算法列表中第一算法的标识，从而得到目标客户端问候报文；指示网络接口404向服务器发送目标客户端问候报文。
101.在一些实施例中，处理器401，用于通过第二算法，使用第一会话秘钥对原始加密报文进行解密；通过第二算法，使用第二会话秘钥对检测后的数据进行加密得到目标加密报文；处理器401读取存储器403中存储的程序代码410后，执行以下操作：通过第二算法，使用第二会话秘钥对原始加密报文进行解密；通过第二算法，使用第一会话秘钥对检测后的数据进行加密得到目标加密报文。
102.在一些实施例中，网络接口404，还用于接收来自于服务器的原始服务器问候报文；处理器401读取存储器403中存储的程序代码410后，执行以下操作：将原始服务器问候报文中的服务器证书替换为中间人证书，从而得到目标服务器问候报文；指示网络接口404向客户端设备发送目标服务器问候报文。
103.在一些实施例中，若硬件加速器405用于生成会话秘钥，处理器401将中间人dh参数以及客户端dh参数输入硬件加速器405，接收硬件加速器405生成的第一会话秘钥；处理器401将中间人dh参数以及服务器dh参数输入硬件加速器405，接收硬件加速器405生成的第二会话秘钥。
104.在一些实施例中，若硬件加速器405用于对原始加密报文进行解密，处理器401将第一会话秘钥以及原始加密报文输入硬件加速器405，接收硬件加速器405解密得到的明文数据；处理器401将第二会话秘钥以及原始加密报文输入硬件加速器405，接收硬件加速器405解密得到的明文数据。
105.在一些实施例中，若硬件加速器405用于对检测后的数据进行加密，处理器401将第二会话秘钥以及检测后的数据输入硬件加速器405，接收硬件加速器405加密得到的目标加密报文；处理器401将第一会话秘钥以及检测后的数据输入硬件加速器405，接收硬件加速器405加密得到的目标加密报文。
106.处理器401、网络接口404、存储器403、硬件加速器405等实现上述功能的更多细节请参考后面方法实施例中的描述。
107.下面结合附图6对本技术实施例提供的加密报文的检测方法进行介绍。附图6是本技术实施例提供的加密报文的检测方法500的流程图。方法500包括步骤s501至步骤s514。
108.可选地，方法500中涉及的客户端设备、服务器以及防护设备的网络部署场景如附
图4所示。方法500中涉及的客户端设备为附图4中的客户端设备31，方法500中服务器为附图4中的服务器32，方法500中防护设备为附图4中的防护设备33。
109.可选地，方法500中防护设备具备附图5所示的结构。
110.方法500的交互主体涉及三类设备—防护设备、客户端设备以及服务器。
111.三类设备的交互涉及各类设备对应的参数。为了区分描述不同设备对应的参数，本实施例使用“中间人”、“客户端”和“服务器”等字样指代不同设备对应的参数。例如，使用“中间人dh参数”指代防护设备生成的dh参数，使用“客户端dh参数”指代客户端设备生成的dh参数，使用“服务器dh参数”指代服务器生成的dh参数。
112.三类设备进行交互时，防护设备扮演着客户端设备与服务器之间中间人的角色。防护设备会转发客户端设备与服务器之间交互的报文，并对客户端设备与服务器之间交互的报文进行修改。为了区分描述防护设备修改前的报文和修改后的报文，本实施例使用“原始”和“目标”等字样指代防护设备修改前的报文和防护设备修改后的报文。例如，用“原始加密报文”指代防护设备接收的加密报文，用“目标加密报文”指代防护设备进行解密、检测、加密等处理后得到的加密报文。
113.步骤s501、防护设备向客户端设备和服务器分别发送中间人dh参数。
114.中间人dh参数为防护设备生成的dh参数。在一些实施例中，中间人dh参数是防护设备通过执行大数运算从而生成的。dh参数为dh算法中的协商参数。dh算法为ssl/tls中使用的密钥协商算法。dh算法包括而不限于ecdh算法。
115.防护设备生成中间人dh参数之后，防护设备将中间人dh参数发送给客户端设备，以便后续防护设备和客户端设备通过双方的dh参数生成会话秘钥。并且，防护设备将中间人dh参数发送给服务器，以便后续防护设备和服务器通过双方的dh参数生成会话秘钥。其中，防护设备向客户端设备发送的中间人dh参数与防护设备向服务器发送的中间人dh参数是相同的。在一些实施例中，防护设备向客户端设备和服务器发送的中间人dh参数具体为防护设备生成的dh参数中的公开部分。dh参数中的公开部分即为dh算法(如ecdh算法)中的公钥。
116.在一些实施例中，防护设备通过对原始服务器密钥交换报文、原始客户端密钥交换报文等原始握手报文进行修改，从而实现步骤s501。具体地，参见附图7，步骤s501例如通过附图7所示的流程实现。附图7所示的流程是对附图6所示的流程中步骤s501的介绍。附图7所示的流程包括以下步骤s5010至步骤s5019。
117.步骤s5010、服务器生成并向客户端设备发送原始服务器密钥(server key exchange)交换报文。
118.原始服务器密钥交换报文包括服务器dh参数。服务器dh参数例如为服务器生成的dh参数的公开部分。在一些实施例中，原始服务器密钥交换报文包括服务器签名。服务器签名是服务器生成的数字签名。具体地，服务器签名是服务器使用服务器的私钥对服务器dh参数进行签名得到的。
119.步骤s5011、防护设备接收来自于服务器的原始服务器密钥交换报文。
120.步骤s5012、防护设备将原始服务器密钥交换报文中的服务器dh参数替换为中间人dh参数，从而得到目标服务器密钥交换报文，目标服务器密钥交换报文包括中间人dh参数。
121.此外，防护设备还将原始服务器密钥交换报文中的服务器签名替换为中间人签名。目标服务器密钥交换报文包括中间人签名。
122.中间人签名是防护设备生成的数字签名。具体地，防护设备使用防护设备的私钥对客户端随机数、服务器随机数和中间人dh参数进行摘要和加密签名后得到中间人签名。
123.步骤s5013、防护设备向客户端设备发送目标服务器密钥交换报文。
124.步骤s5014、客户端设备接收来自于防护设备的目标服务器密钥交换报文，客户端设备从目标服务器密钥交换报文获得中间人dh参数。
125.在一些实施例中，客户端设备从目标服务器密钥交换报文获得中间人签名。客户端设备对中间人签名进行验证。如果中间人签名验证通过，则客户端设备保存中间人dh参数并发送原始客户端密钥交换报文。
126.步骤s5015、客户端设备生成并向服务器发送原始客户端密钥(client key exchange)交换报文，原始客户端密钥交换报文包括客户端dh参数。
127.原始客户端密钥交换报文中的客户端dh参数例如为客户端生成的dh参数的公开部分。
128.步骤s5016、防护设备接收来自于客户端设备的原始客户端密钥交换报文。
129.步骤s5017、防护设备将原始客户端密钥交换报文中的客户端dh参数替换为中间人dh参数，从而得到目标客户端密钥交换报文，目标客户端密钥交换报文包括中间人dh参数。
130.步骤s5018、防护设备向服务器发送目标客户端密钥交换报文。
131.步骤s5019、服务器接收来自于防护设备的目标客户端密钥交换报文，服务器从目标客户端密钥交换报文获得中间人dh参数。
132.通过上述步骤s5010至步骤s5019描述的通信流程，提供了一种类似于设备侧的无状态处理方式，能够在实现参数复用的基础上，进一步减少防护设备的资源开销，并有助于最大程度上保证加入中间人后，相对于无中间人时的兼容性和安全性。下面，对达到这一效果的技术原理进行说明。
133.请参考附图3，传统的实现ssl中间人代理的方案中，防护设备需要各自维护和客户端设备和服务器的连接状态。其中，防护设备和客户端进行握手时，防护设备需要完整地生成发送给客户端设备的每个握手报文；防护设备和服务器进行握手时，防护设备需要完整地生成发送给服务器的每个握手报文，处理流程复杂，可能需要陷入内核。
134.而本实施例在上述步骤s5010至步骤s5019中，使用真实客户端和服务器的握手过程进行驱动，防护设备在两侧发来的握手报文的基础上只需要生成较少的参数、执行报文解析和内容替换，即可实现与两侧的握手，可见减少了大量资源开销。具体地，防护设备与客户端进行握手时，防护设备在真实服务器发来的服务器密钥交换报文的基础上，执行dh参数替换、签名修改等步骤，即可将服务器密钥交换报文发给客户端；防护设备与服务器进行握手时，防护设备在真实客户端发来的客户端密钥交换报文的基础上，执行dh参数替换等步骤，即可将客户端密钥交换报文发给服务器，从而避免了防护设备独立和两端进行ssl握手，不需要使用openssl的复杂处理流程。
135.回到附图6所示的流程中，步骤s502、防护设备根据中间人dh参数以及客户端dh参数，生成第一会话秘钥。
136.客户端dh参数为客户端设备生成的dh参数。第一会话秘钥是指防护设备与客户端设备之间的会话秘钥。
137.在一些实施例中，第一会话秘钥是通过预主密钥结合客户端随机数以及服务器随机数生成的。具体地，防护设备使用中间人dh参数以及客户端dh参数，生成第一预主秘钥；防护设备使用第一预主秘钥、客户端随机数以及服务器随机数，生成第一会话秘钥。其中，客户端随机数为客户端设备生成的随机数，服务器随机数为服务器生成的随机数。
138.步骤s503、防护设备根据中间人dh参数以及服务器dh参数，生成第二会话秘钥。
139.服务器dh参数为服务器生成的dh参数。第二会话秘钥是指防护设备与服务器之间的会话秘钥。
140.在一些实施例中，第二会话秘钥是通过预主密钥结合客户端随机数以及服务器随机数生成的。具体地，防护设备使用中间人dh参数以及服务器dh参数，生成第二预主秘钥；防护设备使用第二预主秘钥、客户端随机数以及服务器随机数，生成第二会话秘钥。
141.防护设备通过执行步骤s501至步骤s503，实现了中间人dh参数的复用，从而极大地减少了运算的开销，大幅提升ssl/tls握手速度。下面结合附图3对这一效果的技术原理进行解释。在传统的方式中，防护设备实现ssl/tls中间人代理时，需要为客户端设备和服务器两侧生成两份中间人dh参数。具体地，请参考附图3，防护设备和客户端设备进行ssl/tls握手时，防护设备生成并向客户端设备发送中间人dh参数1；防护设备和服务器进行ssl/tls握手时，防护设备生成并向服务器发送中间人dh参数2。其中，防护设备发给客户端设备的中间人dh参数1与发给服务器的中间人dh参数2是两份独立的dh参数，需要分别通过dh运算生成。因此，防护设备需要执行大量的复杂计算，导致性能消耗巨大。而本实施例中，防护设备通过将相同的中间人dh参数分别发给客户端设备和服务器，并在与客户端设备和服务器分别协商会话密钥时使用相同的中间人dh参数，从而复用了dh参数，减少生成dh参数所需的运算量。尤其是，在dh参数通过大数运算生成的情况下，显著减少大数运算的开销(即生成中间人dh参数的开销)，仅此一项，预计可提升新建速度接近20％，大幅提升整机处理性能。
142.ssl/tls的通信流程分为会话协商阶段以及数据传输阶段。上述附图6中的步骤s501至步骤s503是对会话协商阶段涉及的步骤的举例说明。以下通过附图6中的步骤s504至步骤s514对数据传输阶段涉及的步骤举例说明。其中，数据传输阶段包括客户端向服务器发送数据的场景或服务器向客户端发送数据的场景，客户端向服务器发送数据的场景的传输过程参见下述步骤s504至步骤s509，服务器向客户端发送数据的场景的传输过程参见下述步骤s510至步骤s514。
143.步骤s504、当客户端设备要向服务器发送数据时，客户端设备使用第一会话秘钥对业务数据进行加密，得到原始加密报文。
144.步骤s505、客户端设备发送原始加密报文。
145.步骤s506、防护设备接收来自于客户端设备的原始加密报文。
146.步骤s507、防护设备使用第一会话秘钥对来自于客户端设备的原始加密报文进行解密，对解密得到的明文数据进行检测，并使用第二会话秘钥对检测后的数据进行加密得到目标加密报文。
147.步骤s508、防护设备向服务器发送目标加密报文。
148.步骤s509、服务器使用第二会话秘钥对目标加密报文进行解密，得到防护设备检测后的明文数据。
149.步骤s510、当服务器要向客户端设备发送数据时，服务器使用第二会话秘钥对业务数据进行加密，得到原始加密报文。服务器发送原始加密报文。
150.步骤s511、防护设备接收来自于服务器的原始加密报文。
151.步骤s512、防护设备使用第二会话秘钥对来自于服务器的原始加密报文进行解密，对解密得到的明文数据进行检测，并使用第一会话秘钥对检测后的数据进行加密得到目标加密报文。
152.步骤s513、防护设备向客户端设备发送目标加密报文。
153.步骤s514、客户端设备使用第一会话秘钥对目标加密报文进行解密，得到防护设备检测后的明文数据。
154.值得说明的一点是，图6示出的步骤s504至步骤s509在先，步骤s510至步骤s514在后仅是示例性地，本实施例对步骤s504至步骤s509与步骤s510至步骤s514的时序不做限定。在一些实施例中，步骤s504至步骤s509与步骤s510至步骤s514顺序执行。例如，先执行步骤s504至步骤s509，再执行步骤s510至步骤s514；又如，先执行步骤s510至步骤s514，再执行步骤s504至步骤s509。在另一些实施例中，步骤s504至步骤s509与步骤s510至步骤s514并行执行，即，同时执行步骤s504至步骤s509以及步骤s510至步骤s514。
155.本实施例提供的方法，将防护设备与客户端设备之间的ssl握手流程、防护设备与服务器之间的ssl握手流程关联起来，防护设备将同一份dh参数分别发给客户端设备以及服务器，并在生成会话密钥时复用两侧的dh参数，从而减少生成dh参数带来的计算量，节省对防火墙等防护设备的资源占用，有助于大幅提升ssl握手速度，提升防护设备的性能。
156.在一些实施例中，防护设备还在客户端发来的算法列表中删除不支持的算法，将删除后的算法列表转发给服务器，使得服务器从来自于客户端、防护设备删除后的算法列表中选择最终协商出的算法，从而将防护设备与客户端之间加解密使用的算法，与防护设备与服务器之间加解密使用的算法关联起来。
157.例如，参见附图8，删除算法的流程例包括下述步骤s521至步骤s526。
158.步骤s521、客户端设备生成并发送原始客户端问候(client hello)报文。
159.原始客户端问候报文是ssl/tls协议中的一种握手报文。原始客户端问候报文包括算法列表以及客户端随机数。原始客户端问候报文中的算法列表和客户端随机数均是客户端设备生成的。
160.原始客户端问候报文中的算法列表用于描述客户端设备支持的至少一种算法。算法列表包括至少一个算法的标识。算法列表用于供服务器选择数据传输阶段加密以及解密时使用的算法。例如，客户端设备发送的客户端问候报文包含下表1所示的算法列表。表1所示的算法列表包含5种算法的标识，这5种算法均是客户端设备支持的算法。
161.表1
162.tls_ecdhe_rsa_with_aes_256_gcm_sha384tls_ecdhe_rsa_with_aes_128_gcm_sha256tls_ecdhe_ecdsa_with_aes_128_gcm_sha256tls_rsa_with_rc4_128_sha
tls_rsa_with_aes_256_cbc_sha
163.步骤s522、防护设备接收来自于客户端设备的原始客户端问候报文。
164.步骤s523、防护设备从原始客户端问候报文中删除算法列表中第一算法的标识，从而得到目标客户端问候报文。
165.步骤s524、防护设备向服务器发送目标客户端问候报文。
166.第一算法为防护设备不支持的算法。第一算法是一种用于对数据加解密的算法。
167.目标客户端问候报文为防护设备删除算法后得到的报文。目标客户端问候报文包括算法列表。目标客户端问候报文中的算法列表包括除第一算法之外的至少一种算法的标识，即防护设备删除后剩余的一些算法的标识。目标客户端问候报文中的算法列表用于描述客户端设备和防护设备均支持的至少一种算法。具体地，由于客户端设备发送的算法列表中的算法是客户端设备支持的算法，而防护设备将其中防护设备不支持的算法删除，因此删除后剩余的算法既能为客户端设备支持，也能为防护设备支持。
168.例如，客户端设备提供表1所示的5种算法供服务器选择。防护设备收到的客户端问候报文包括上表1所示的算法列表。防护设备检查客户端问候报文中的算法列表是否包括防护设备不支持的算法时，发现防护设备不支持表1中的第四种算法“tls_rsa_with_rc4_128_sha”。防护设备将第四种算法“tls_rsa_with_rc4_128_sha”从客户端问候报文的算法列表中删除，从而得到如下表2所示的算法列表。防护设备发给服务器的客户端问候报文的算法列表包括如下表2所示的算法列表。表2所示的算法列表与表1所示的算法列表之间的关系在于，表2所示的算法列表包含表1所示的算法列表中除“tls_rsa_with_rc4_128_sha”之外的其他4种算法的标识。表2示出的4种算法都是防护设备以及客户端设备均支持的算法。其中，“tls_rsa_with_rc4_128_sha”标识的算法是对第一算法的举例说明。
169.表2
170.tls_ecdhe_rsa_with_aes_256_gcm_sha384tls_ecdhe_rsa_with_aes_128_gcm_sha256tls_ecdhe_ecdsa_with_aes_128_gcm_sha256tls_rsa_with_aes_256_cbc_sha
171.步骤s525、服务器接收目标客户端问候报文。
172.步骤s526、服务器根据目标客户端问候报文中的算法列表，从防护设备删除后剩余的算法中选择第二算法。
173.第二算法即为三方(客户端设备、服务器以及防护设备)在握手阶段协商出的算法。第二算法是数据传输阶段三方用来对数据加解密的算法。第二算法为目标客户端问候报文中的算法列表中的一种算法。换句话说，第二算法为从算法列表中删除第一算法的标识之后剩余的算法标识对应的算法。
174.第二算法是防护设备、客户端设备以及服务器均支持的算法。具体地，服务器会根据自身支持的算法，从收到的客户端问候报文中的算法列表选择服务器支持的算法(第二算法)。
175.例如，客户端设备发送表1所示描述5种算法的算法列表，防护设备从中删除一种算法的标识后，向服务器转发表2所示的描述4种算法的算法列表。服务器收到表2所示的算法列表后，服务器发现表2示出的4种算法中，服务器支持第3种算法tls_ecdhe_ecdsa_
with_aes_128_gcm_sha256。服务器选择第3种算法tls_ecdhe_ecdsa_with_aes_128_gcm_sha256。在这个例子中，tls_ecdhe_ecdsa_with_aes_128_gcm_sha256标识的算法是对第二算法的举例说明。
176.在一些实施例中，服务器保存服务器支持的算法列表。服务器对目标客户端问候报文中的算法列表与本地保存的算法列表进行对比。如果找到同时存在于目标客户端问候报文中的算法列表与本地保存的算法列表的算法，则服务器选择该算法(第二算法)。
177.当握手阶段采用上述步骤s521至步骤s526时，后续的数据传输阶段例如通过下述步骤s504’至步骤s514’实现。下述步骤s504’至步骤s514’分别对应于附图6所示的流程中步骤s504至步骤s514。
178.步骤s504’、当客户端设备要向服务器发送数据时，客户端设备通过第二算法，使用第一会话秘钥对业务数据进行加密，得到原始加密报文。
179.在一些实施例中，防护设备根据来自于服务器的原始服务器问候报文，确定服务器选择的算法为第二算法；客户端设备根据来自于防护设备的目标服务器问候报文，确定服务器选择的算法为第二算法。
180.例如，服务器在发送服务器问候报文时，将服务器选择的算法的标识携带在服务器问候报文中并发送包括第二算法的标识的原始服务器问候报文。防护设备接收到原始服务器问候报文后，根据原始服务器问候报文中第二算法的标识，确定服务器选择的算法为第二算法。防护设备对服务器发送的服务器问候报文进行证书替换等处理后生成目标服务器问候报文，目标服务器问候报文中仍然携带第二算法的标识。防护设备向客户端设备发送目标服务器问候报文。客户端设备接收到目标服务器问候报文后，根据目标服务器问候报文中第二算法的标识，确定服务器选择的算法为第二算法。
181.步骤s505’、客户端设备发送原始加密报文。
182.步骤s506’、防护设备接收来自于客户端设备的原始加密报文。
183.步骤s507’、防护设备通过第二算法，使用第一会话秘钥对原始加密报文进行解密，对解密得到的明文数据进行检测。并且，防护设备通过第二算法，使用第二会话秘钥对检测后的数据进行加密得到目标加密报文。
184.步骤s508’、防护设备向服务器发送目标加密报文。
185.步骤s509’、服务器通过第二算法，使用第二会话秘钥对目标加密报文进行解密，得到防护设备检测后的明文数据。
186.步骤s510’、当服务器要向客户端设备发送数据时，服务器通过第二算法，使用第二会话秘钥对业务数据进行加密，得到原始加密报文。服务器发送原始加密报文。
187.步骤s511’、防护设备接收来自于服务器的原始加密报文。
188.步骤s512’、防护设备通过第二算法，使用第二会话秘钥对来自于服务器的原始加密报文进行解密，对解密得到的明文数据进行检测，并通过第二算法，使用第一会话秘钥对检测后的数据进行加密得到目标加密报文。
189.步骤s513’、防护设备向客户端设备发送目标加密报文。
190.步骤s514’、客户端设备通过第二算法，使用第一会话秘钥对目标加密报文进行解密，得到防护设备检测后的明文数据。
191.通过上述流程，一方面，有助于避免数据传输阶段由于防护设备不支持客户端与
服务器协商的算法而导致通信失败，提高数据传输的可靠性和成功率。另一方面，兼顾了安全性和兼容性，保证防护设备使用的算法满足客户端和服务器对流量传输安全性的需求。下面，对达到这种效果的原理进行介绍。
192.一方面，在ssl/tls协议中，客户端通过向服务器发送client hello报文，从而与服务器协商出在后续数据传输时使用的加解密算法。具体地，客户端将自身支持的一系列算法以算法列表的形式携带在client hello报文中发给服务器。服务器收到client hello报文之后，通过client hello报文中的算法列表找到双方都支持的算法，作为协商出的算法告知给客户端。之后，客户端与服务器在数据传输阶段会使用协商出的算法对数据加解密。
193.如果客户端与服务器协商出的算法是防护设备不支持的算法，防护设备收到客户端与服务器之间传输的加密数据时，将无法对加密数据进行解密获得明文数据，也就无法对明文数据进行安全检测，导致安全检测失败。
194.而通过本实施例提供的ssl/tls握手流程，由于防护设备从client hello报文的算法列表中删除了不支持的算法，使得算法列表在删除算法后剩余的每种算法都是防护设备支持的算法。因此，防护设备将删除算法后的client hello报文转发给服务器之后，服务器收到的client hello报文中的算法列表不会包含防护设备不支持的算法。换句话说，服务器收到的client hello报文中的算法列表中的算法都是防护设备支持的算法。因此，服务器从client hello报文中的算法列表中选择算法时，服务器选择的算法(也就是ssl/tls握手阶段协商出来的算法)会是防护设备支持的算法。
195.那么，由于握手阶段协商出的算法是防护设备支持的算法，从而保证客户端、防护设备以及服务器这三方在数据传输阶段使用三方都支持的算法对数据加解密，避免由于防护设备不支持解密所需的算法而导致安全检测失败。
196.一方面，从安全性和兼容性的角度来看，在如附图3所示的传统ssl中间人代理方案中，无法做到安全性和兼容性的兼顾。这是由于，防护设备发给服务器的算法列表是由防护设备自己独立生成的，而与客户端提供的算法列表无关。具体地，运维人员会在防护设备上预先配置算法列表。防护设备预先配置了哪种算法，防护设备与服务器进行握手时，就会将哪种算法放在算法列表中并发给服务器。换句话说，无论客户端之前发的算法列表包含哪些算法，防护设备发给服务器的算法列表都是固定不变的(取决于预先的配置)。
197.而算法的配置有2种选择，要么配置高安全性的算法，要么配置兼容性好但有一定安全风险的算法。如果防护设备配置高安全性的算法，遇到客户端或者服务器无法支持高安全性算法的情况，就会引入兼容性的问题，导致协商失败。如果防护设备配置兼容性好的算法，遇到客户端或者服务器对算法安全性要求高的情况，就会导致安全性降低。
198.而本实施例通过以上交互算法列表的流程，巧妙地解决了这一困境，在安全性和兼容性之间取得了平衡。具体地，算法列表由客户端负责生成，而防护设备对算法列表进行修改。如果客户端需要使用高安全性算法，客户端将包含高安全性算法的列表发给防护设备，防护设备在删除不支持算法后，会将来自客户端的算法列表发给服务器，服务器从删除后剩余的高安全性算法中选择算法后，三方加解密均会使用服务器选择的高安全性算法，从而满足对安全性的需求。如果客户端需要使用兼容性好的算法，客户端将包含高兼容性算法的列表发给防护设备，防护设备在删除不支持算法后，会将来自客户端的算法列表发
给服务器，服务器从删除后剩余的高兼容性算法中选择算法后，三方加解密均会使用服务器选择的高兼容性算法，从而满足对兼容性的需求。总结来看，防护设备与两侧交互时使用的算法不再仅仅取决于固定配置，而是根据客户端对安全性的需求以及服务器的选择确定，从而实现安全性和兼容性的自适应选择，兼顾了安全性和兼容性，灵活性高。
199.在一些实施例中，防护设备还通过替换服务器的证书，保证中间人签名通过客户端设备的验证，从而避免随着中间人签名一起传给客户端设备的数据(如中间人dh参数)由于签名验证不通过而传输失败。
200.例如，请参考附图9，替换证书的流程包括下述步骤s531至步骤s534。
201.步骤s531、服务器生成并发送原始服务器问候(server hello)报文。
202.原始服务器问候报文包括服务器证书。服务器证书包括服务器的公钥。
203.步骤s532、防护设备接收来自于服务器的原始服务器问候报文。
204.步骤s533、防护设备将原始服务器问候报文中的服务器证书替换为中间人证书，从而得到目标服务器问候报文。
205.目标服务器问候报文包括中间人证书。中间人证书包括防护设备的公钥。
206.步骤s534、防护设备向客户端设备发送目标服务器问候报文。
207.客户端设备接收目标服务器问候报文。客户端设备从目标服务器问候报文中的中间人证书获得防护设备的公钥，将防护设备的公钥作为ssl/tls会话中对端的公钥保存。之后，客户端设备与防护设备进行交互时，防护设备使用防护设备的私钥生成中间人签名，客户端设备使用防护设备的公钥对中间人签名进行验证。
208.例如，在附图7所示的流程中，步骤s5013中防护设备发送的目标服务器密钥交换报文包括中间人签名以及中间人dh参数。当客户端设备收到目标服务器密钥交换报文时，客户端设备使用防护设备的公钥对中间人签名进行验证。由于防护设备的公钥与生成中间人签名使用的私钥是一对可互为加解密的密钥，因此中间人签名能够通过客户端设备的验证，客户端设备会保存中间人dh参数并发送原始客户端密钥交换报文。
209.在一些实施例中，防护设备通过提取和转发原始问候报文中的随机数，从而复用客户端设备以及服务器生成的随机数，免去防护设备独立生成随机数带来的开销。
210.具体而言，请参考附图3，在附图3所示的方法中，为了生成防护设备与客户端之间的会话密钥以及防护设备与服务器之间的会话密钥，要求防护设备自己生成两份中间人随机数。具体地，防护设备与服务器交互时，防护设备需要生成中间人随机数1，防护设备将中间人随机数1发给服务器，后续防护设备与服务器均使用中间人随机数1和服务器随机数生成会话密钥2。防护设备与客户端设备进行交互时，防护设备需要生成中间人随机数2，防护设备将中间人随机数2发给客户端设备，后续防护设备与客户端设备均使用中间人随机数2和客户端随机数生成会话密钥1。显然，生成中间人随机数1和中间人随机数2会产生一定的资源开销，耗费防护设备的算力。
211.而本技术的一些实施例中，防护设备收到客户端设备发送的原始客户端问候报文之后，防护设备还从原始客户端问候报文中提取客户端随机数。防护设备发给服务器的目标客户端问候报文包括客户端随机数，从而将客户端设备生成的客户端随机数传给服务器。后续防护设备和服务器均使用客户端随机数以及服务器随机数生成第二会话秘钥，从而复用客户端设备生成的客户端随机数，免去生成中间人随机数1带来的资源开销。防护设
备收到服务器发送的原始服务器问候报文之后，防护设备还从原始服务器问候报文中提取服务器随机数。防护设备发给客户端设备的目标服务器问候报文包括服务器随机数，从而将服务器生成的服务器随机数传给客户端设备。后续防护设备和客户端设备均使用客户端随机数以及服务器随机数生成第一会话秘钥，从而复用服务器生成的服务器随机数，免去生成中间人随机数2带来的资源开销。
212.总结以上描述的dh参数替换、签名替换、证书替换、随机数提取可见，本实施例提供的ssl中间人方案，不再使用openssl库进行完整的黑盒握手流程处理，而是以原始的握手报文为触发，提取原始的握手报文中秘钥协商相关的信息(如dh参数、随机数、签名、证书等)并进行修改，完成会话秘钥的两侧协商。由于不需要使用openssl的复杂处理流程，从而避开了使用openssl很可能需要陷入内核的技术困境，降低方案的实现复杂度，减少防护设备的资源占用。同时，也不需要完全实现ssl交互的库，避免自研ssl库的安全性、兼容性问题。获得了密钥之后，后续的对称处理阶段，可选地也不再使用openssl的会话处理流程，而是由防护设备自己实现ssl记录(ssl record)层的解析。特别地，有利于后续对称加密处理部分的硬件化(使用逻辑、asic等实现该部分的处理)，下面进行具体介绍。
213.在一些实施例中，涉及dh运算、加密和解密的步骤通过硬件加速。具体地，防护设备包括一个或多个硬件加速器。硬件加速器例如为附图4中的加解密加速器333。
214.硬件加速器为执行dh算法或加解密算法的专用硬件。硬件加速器用于对需要采用dh算法或加解密算法的步骤进行加速，从而提升防护设备基于dh算法协商密钥、数据加密或数据解密的性能。
215.硬件加速器包括而不限于现场可编程门阵列(field programmable gate array，fpga)、专用集成芯片(application specific integrated circuit，asic)、系统芯片(system on chip，soc)、中央处理器(central processor unit，cpu)、网络处理器(network processor，np)、数字信号处理电路(digital signal processor，dsp)、微控制器(micro controller unit，mcu)、可编程控制器(programmable logic device，pld)或其他集成芯片。
216.结合附图6所示方法，例如，硬件加速器用于生成会话秘钥、对原始加密报文进行解密、或对检测后的数据进行加密。
217.例如，若硬件加速器用于生成会话秘钥，采用如下方式实现上述步骤s502：防护设备将中间人dh参数以及客户端dh参数输入硬件加速器，接收硬件加速器生成的第一会话秘钥。采用如下方式实现上述步骤s503：防护设备将中间人dh参数以及服务器dh参数输入硬件加速器，接收硬件加速器生成的第二会话秘钥。
218.例如，若硬件加速器用于对原始加密报文进行解密，采用如下方式实现上述步骤s507：防护设备将第一会话秘钥以及原始加密报文输入硬件加速器，接收硬件加速器解密得到的明文数据。采用如下方式实现上述步骤s512：防护设备将第二会话秘钥以及原始加密报文输入硬件加速器，接收硬件加速器解密得到的明文数据。
219.例如，若硬件加速器用于对检测后的数据进行加密，采用如下方式实现上述步骤s507：防护设备将第二会话秘钥以及检测后的数据输入硬件加速器，接收硬件加速器加密得到的目标加密报文。并且，采用如下方式实现上述步骤s512：防护设备将第一会话秘钥以及检测后的数据输入硬件加速器，接收硬件加速器加密得到的目标加密报文。
220.防护设备通过采用硬件加速的手段实现附图6所示方法流程中的步骤，从而将ssl代理中dh运算、加密处理等消耗大量算力的任务从cpu卸载至硬件加速器，也即是最消耗性能算法部分采用专用加速硬件处理，减少ssl代理对cpu算力的占用，极大改善资源占用，大幅提升性能，加速防护设备实现ssl代理的处理流程。
221.下面结合一个实例，对ssl中间人代理方案的完整流程进行说明。
222.下述实例中，上述第一会话秘钥为会话秘钥1，上述第二会话秘钥为会话秘钥2，上述第一预主秘钥为预主秘钥1，上述第二预主秘钥为预主秘钥2，防护设备发给客户端设备和服务器的中间人dh参数为pubkey_fw。防护设备替换掉的客户端dh参数为pubkey_c。防护设备替换掉的服务器dh参数为pubkey_s。其中，pubkey_fw中fw的含义是防火墙(fire wall)。pubkey_s中s的含义是服务器(server)。pubkey_c中c的含义是客户端(client)。
223.如附图10所示，下述实例在握手阶段包括以下步骤s61a至步骤s66b。
224.步骤s61a、客户端设备发送原始client hello报文。原始client hello报文包括客户端随机数以及客户端设备支持的算法列表。
225.步骤s61b、防护设备收到原始client hello报文之后，防护设备解析原始client hello报文，防护设备提取原始client hello报文中的客户端随机数。防护设备检查原始client hello报文的算法列表中是否包含防护设备不支持的算法。如果原始client hello报文的算法列表包含防护设备不支持的算法，则防护设备将防护设备不支持的算法从原始client hello报文中删除，从而得到目标client hello报文。然后，防护设备将目标client hello报文转发给服务器。
226.步骤s62a、服务器收到目标client hello报文后，服务器从目标client hello报文中客户端设备提供的信息中，选择服务器支持的版本、算法。服务器根据选择的算法以及服务器自己生成的随机数(服务器随机数)、服务器证书，生成原始server hello报文。服务器向客户端设备发送原始server hello报文。原始server hello报文包括服务器选择的算法的标识、服务器随机数和服务器证书。服务器证书包括服务器的公钥。
227.步骤s62b、防护设备收到服务器的原始server hello报文。防护设备提取原始server hello报文中的服务器随机数以及算法的标识。防护设备重新生成防护设备重新签发的证书(中间人证书)，将原始server hello报文中的服务器证书替换为中间人证书。中间人证书包括防护设备的公钥。防护设备将目标server hello报文发送给客户端设备。目标server hello报文包括服务器选择的算法的标识。
228.步骤s63a、如果服务器在步骤s62a中根据目标client hello报文的选项，选择使用dh协商算法来协商会话秘钥，则服务器在步骤s63a生成自己的dh参数(服务器dh参数)。并且，服务器使用服务器的私钥对客户端随机数、服务器随机数和服务器dh参数进行签名，得到服务器签名。服务器将dh参数的公开部分(pubkey_s)以及服务器签名携带在原始server key exchange报文中，向客户端设备发送原始server key exchange报文。
229.例如，服务器选择椭圆曲线算法secp256r1协商会话密钥。服务器发送的原始server key exchange报文包含下表3所示的内容。表3中pubkey字段的内容(043c334e8058c5fb31fa8fa517a44d59e9dbeb3705a0612
…
)是服务器dh参数。表3中signature字段的内容(483fa3177932cf6512ba616444e84d7d98349e60fc29e959)是服务器签名。
230.表3
[0231][0232]
表3中pubkey字段的“043c334e8058c5fb31fa8fa517a44d59e9dbeb3705a0612
…”
中
“…”
为省略号，
“…”
表示pubkey字段还包括而省略未示出的内容，也即是dh参数还包括而未示出的部分。本文在后续示出的其他表格中pubkey字段的内容中的省略号的含义与此同理。
[0233]
表3中signature字段的“483fa3177932cf6512ba616444e84d7d98349e60fc29e959
…”
中
“…”
为省略号，
“…”
表示signature字段还包括而省略未示出的内容，也即是签名还包括而未示出的部分。本文在后续示出的其他表格中signature字段的内容中的省略号的含义与此同理。
[0234]
表3中除了pubkey字段以及signature字段之外其他字段的内容含义如下。
[0235]
握手协议字段的内容为服务器密钥交换。握手类型字段(即ssl/tls协议中握手报文的类型)的内容为服务器密钥交换，该握手类型通过值12表示。长度字段的内容为329。ecdh服务器参数字段包括曲线类型字段、曲线名称字段、pubkey长度字段和pubkey字段。曲线类型字段的内容为命名曲线，该曲线类型通过值0x03表示。曲线名称字段的内容为secp256r1，该曲线名称通过值0x0017表示。曲线类型字段和曲线名称字段的内容指示pubkey的生成算法为secp256r1。pubkey长度字段的内容为65。签名算法(生成服务器签名时使用的算法)字段的内容为rsa_pkcs1sha512，该签名算法通过值0x0601表示。签名长度(服务器签名的长度)字段的内容为256。
[0236]
步骤s63b、防护设备收到服务器发送的原始server key exchange报文后，防护设备提取原始server key exchange报文中的pubkey_s(服务器dh参数)。然后，防护设备将原始server key exchange报文中pubkey_s(服务器dh参数)替换为防护设备使用相同算法生成的pubkey_fw(中间人dh参数)。并且，防护设备使用防护设备的私钥，对客户端随机数、服务器随机数和中间人dh参数进行签名，从而重新生成中间人签名。防护设备将原始server key exchange报文中的服务器签名替换为中间人签名。之后，防护设备将目标server key exchange报文发送给客户端设备。
[0237]
例如，防护设备收到的原始server key exchange报文包含表3所示的内容，防护设备将表3中pubkey字段的内容替换为中间人dh参数，防护设备将表3中signature字段的内容替换为中间人签名，从而得到包括如下表4所示的内容的目标server key exchange报
文，将包括如下表4所示的内容的目标server key exchange报文发送给客户端设备。表4中pubkey字段的内容(04083f0c2b627d51d88fff2d2d9fa373328d
…
)是中间人dh参数。表4中signature字段的内容(046f476af7cd0e95f912246656d2bc7b1cccb7f490133e90
…
)是中间人签名。
[0238]
表4
[0239][0240]
表4中除了pubkey字段以及signature字段之外其他字段的内容含义与表3同理，请参考对表3的介绍。
[0241]
对比表3和表4可见，表4中pubkey字段以及signature字段这2个字段的内容与表3不同，表4中这2个字段的内容是防护设备生成的，表4中除了这2个字段之外的其他字段的内容能够直接复用表3，而无需依赖于防护设备自己根据会话状态等复杂的处理逻辑来生成。在一个示例中，防护设备收到服务器发来的包含表3所示内容的原始server key exchange报文之后，修改表3中pubkey字段的内容以及signature字段的内容，即可得到包含表4所示内容的目标server key exchange报文，通过将包含表4所示内容的目标server key exchange报文发给客户端，实现防护设备与客户端之间的握手。显然，这种实现方式简化了防护设备的处理逻辑，节省了防护设备的开销。
[0242]
步骤s64a、客户端设备收到防护设备发出的目标server key exchange报文后，客户端设备生成并发送原始client key exchange报文。原始client key exchange报文包括客户端dh参数。客户端dh参数具体为dh参数的公开部分pubkey_c。
[0243]
例如，客户端设备发送的原始client key exchange报文包括如下表5所示的内容。表5中pubkey字段的内容(0456be94b776d9a32dc00d4f673bb3f9c232b2526575066
…
)是客户端dh参数。
[0244]
表5
[0245]
[0246][0247]
表5中除了pubkey字段之外其他字段的内容含义如下。
[0248]
握手协议字段的内容为客户端密钥交换。握手类型字段的内容为客户端密钥交换，该握手类型通过值16表示。长度字段的内容为66。ecdh客户端参数字段包括pubkey长度字段和pubkey字段。pubkey长度字段的内容为65。
[0249]
步骤s64b、防护设备收到客户端设备的原始client key exchange报文。防护设备提取原始client key exchange报文中的客户端dh参数pubkey_c后，防护设备将原始client key exchange报文中的客户端dh参数pubkey_c替换为防护设备的dh参数pubkey_fw(中间人dh参数)。之后，防护设备将目标client key exchange报文发送给服务器。
[0250]
例如，防护设备收到的原始client key exchange报文包含表5所示的内容，防护设备将表5中pubkey字段的内容替换为中间人dh参数，从而得到包括如下表6所示的内容的目标client key exchange报文，将包括如下表6所示的内容的目标client key exchange报文发送给服务器。表6中pubkey字段的内容(04083f0c2b627d51d88fff2d2d9fa373328d
…
)是中间人dh参数。
[0251]
表6
[0252][0253]
表6中除了pubkey字段之外其他字段的内容含义与表5同理，请参考对表5的介绍。
[0254]
对比表4和表6可见，表4和表6中pubkey字段的内容是相同的，也就是说，防护设备发送给服务器的中间人dh参数，和防护设备发送给客户端设备的中间人dh参数是相同的，可见实现了dh参数的复用，省去分别生成2份dh参数的开销。
[0255]
此外，对比表5和表6可见，表6中pubkey字段的内容与表5不同，表6中pubkey字段的内容是防护设备生成的，表6中除了pubkey字段之外的其他字段的内容能够直接复用表5，而无需依赖于防护设备自己根据会话状态等复杂的处理逻辑来生成。在一个示例中，防护设备收到客户端发来的包含表5所示内容的原始client key exchange报文之后，修改表5中pubkey字段的内容，即可得到包含表6所示内容的目标client key exchange报文，通过将包含表6所示内容的目标client key exchange报文发给服务器，实现防护设备与服务器之间的握手。显然，这种实现方式简化了防护设备的处理逻辑，节省了防护设备的开销。
[0256]
步骤s65a、客户端设备使用客户端设备dh参数私有部分和pubkey_fw进行计算，从而获得预主秘钥1。防护设备使用pubkey_c和防护设备dh参数的私有部分进行计算，从而获得同样的预主秘钥1。
[0257]
步骤s65b、与步骤s65a同理地，服务器使用服务器dh参数私有部分和pubkey_fw进行计算，从而获得预主秘钥2。防护设备使用pubkey_s和防护设备dh参数的私有部分进行计
算，从而获得同样的预主秘钥2。
[0258]
步骤s66a、客户端设备和防护设备各自使用预主秘钥1、客户端随机数以及服务器随机数进行计算，从而获得相同的会话秘钥1。
[0259]
步骤s66b、服务器和防护设备自使用预主秘钥2、客户端随机数以及服务器随机数进行计算，从而获得相同的会话秘钥2。
[0260]
此时，会话协商部分完成，后续客户端设备向服务器发送数据的传输过程如下所示，包括步骤(1-1)至步骤(1-4)。
[0261]
步骤(1-1)客户端设备在向服务器发送数据报文时，客户端设备使用会话秘钥1对明文数据进行加密，得到加密报文，并发送加密报文。
[0262]
步骤(1-2)防护设备收到客户端设备发送的加密报文之后，防护设备使用会话秘钥1进行解密，然后防护设备对解密出的明文数据进行内容检查。
[0263]
步骤(1-3)如果检查发现明文数据无威胁，防护设备使用会话秘钥2对检查后的数据进行加密后发送给服务器。
[0264]
步骤(1-4)服务器接收到来自于防护设备的加密报文之后，服务器使用会话秘钥2对加密报文进行解密。
[0265]
服务器向客户端设备发送数据的传输过程与上述步骤(1-1)至步骤(1-4)类似，包括以下步骤(2-1)至步骤(2-4)。
[0266]
步骤(2-1)服务器在向客户端设备发送数据报文时，服务器使用会话秘钥2对明文数据进行加密，得到加密报文，并发送加密报文。
[0267]
步骤(2-2)防护设备收到服务器发送的加密报文之后，防护设备使用会话秘钥2进行解密，然后防护设备对解密出的明文数据进行内容检查。
[0268]
步骤(2-3)如果检查发现明文数据无威胁，防护设备使用会话秘钥1对检查后的数据进行加密后发送给客户端设备。
[0269]
步骤(2-4)客户端设备接收到来自于防护设备的加密报文之后，客户端设备使用会话秘钥1对加密报文进行解密。
[0270]
步骤(1-1)至步骤(1-4)、步骤(2-1)至步骤(2-4)中，通信三方(客户端设备、防护设备以及服务器)进行加密和解密时采用的算法相同。例如，服务器进行加密和解密时采用的算法为原始server hello报文中算法标识对应的算法。防护设备进行加密和解密时采用的算法为原始server hello报文中算法标识对应的算法。客户端设备进行加密和解密时采用的算法为目标server hello报文中算法标识对应的算法。
[0271]
附图11是本技术实施例提供的另一种防护设备的结构示意图。可选地，具有附图11所示结构的防护设备700是图4中的防护设备33。可选地，具有附图11所示结构的防护设备是图5中的防护设备400。防护设备700包括发送单元701、处理单元702和接收单元703。
[0272]
发送单元701，用于执行s501；处理单元702，用于执行s502；接收单元703，用于执行s506以及s511；如果原始加密报文来自于客户端设备，则处理单元702，还用于执行s507，发送单元701，还用于执行s508；如果原始加密报文来自于服务器，则处理单元702，还用于执行s512，发送单元701，还用于执行s513。
[0273]
在一些实施例中，接收单元703，还用于执行s5011；处理单元702，还用于执行s5012；发送单元701，还用于执行s5013。
[0274]
在一些实施例中，接收单元703，还用于执行s5016；处理单元702，还用于执行s5017；发送单元701，还用于执行s5018。
[0275]
在一些实施例中，处理单元702，还用于将原始服务器密钥交换报文中的服务器签名替换为中间人签名。
[0276]
在一些实施例中，处理单元702，用于使用中间人dh参数以及客户端dh参数，生成第一预主秘钥；使用第一预主秘钥、客户端随机数以及服务器随机数，生成第一会话秘钥；使用中间人dh参数以及服务器dh参数，生成第二预主秘钥；使用第二预主秘钥、客户端随机数以及服务器随机数，生成第二会话秘钥。
[0277]
在一些实施例中，接收单元703，还用于执行s522；处理单元702，还用于执行s523；发送单元701，还用于执行s524。
[0278]
在一些实施例中，处理单元702，用于执行s507’和s512’。发送单元701，用于执行s508’和s513’。
[0279]
在一些实施例中，接收单元703，还用于执行s532；处理单元702，还用于执行s533；发送单元701，还用于执行s534。
[0280]
附图11所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可选地有另外的划分方式，例如多个单元或组件可选地结合或者可选地集成到另一个系统，或一些特征可选地忽略，或不执行。在本技术各个实施例中的各功能单元可选地集成在一个处理单元中，或可选地是各个单元单独物理存在，或可选地两个或两个以上单元集成在一个单元中。附图11中上述各个单元可选地采用硬件的形式实现，或可选地采用软件功能单元的形式实现。例如，采用软件实现时，上述接收单元703、处理单元702和发送单元701可选地是由附图5中的cpu读取存储器403中存储的程序代码410后，生成的软件功能模块来实现。图11中上述各个单元可选地由防护设备中的不同硬件分别实现，例如接收单元703和发送单元701由附图5中的网络接口404实现，处理单元由附图5中的处理器401实现，或者采用现场可编程门阵列(field－programmable gate array，fpga)、或协处理器等可编程器件来完成。显然上述功能模块也可选地采用软件硬件相结合的方式来实现，例如接收单元703和发送单元701由硬件可编程器件实现，而处理单元702是由cpu读取存储器403中存储的程序代码410后，生成的软件功能模块。
[0281]
本领域普通技术人员可以意识到，结合本文中所公开的实施例中描述的各方法步骤和单元，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各实施例的步骤及组成。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。本领域普通技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本技术的范围。
[0282]
所属领域的技术人员可以清楚地了解到，为了描述的方便和简洁，上述描述的系统、装置和单元的具体工作过程，可以参见前述方法实施例中的对应过程，在此不再赘述。
[0283]
本技术中术语“第一”、“第二”等字样用于对作用和功能基本相同的相同项或相似项进行区分，应理解，“第一”、“第二”之间不具有逻辑或时序上的依赖关系，也不对数量和执行顺序进行限定。例如，在不脱离各种示例的范围的情况下，第一会话秘钥可以被称为第二会话秘钥，并且类似地，第二会话秘钥可以被称为第一会话秘钥。第一会话秘钥和第二会
话秘钥都可以是会话秘钥，并且在某些情况下，可以是单独且不同的会话秘钥。
[0284]
本技术中术语“至少一个”的含义是指一个或多个。
[0285]
在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。该计算机程序产品包括一个或多个计算机程序指令。在计算机上加载和执行该计算机程序指令时，全部或部分地产生按照本技术实施例中的流程或功能。该计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。
[0286]
该计算机指令可以存储在计算机可读存储介质中，或者从一个计算机可读存储介质向另一个计算机可读存储介质传输，例如，该计算机程序指令可以从一个网站站点、计算机、服务器或数据中心通过有线或无线方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质(例如软盘、硬盘、磁带)、光介质(例如，数字视频光盘(digital video disc，dvd)、或者半导体介质(例如固态硬盘)等。前述的存储介质包括：u盘、移动硬盘、只读存储器(read-only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
[0287]
以上实施例仅用以说明本技术的技术方案，而非对其限制；尽管参照前述实施例对本技术进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本技术各实施例技术方案的范围。