安全通信的方法及设备与流程

1.本技术涉及信道加密通信技术领域，尤其涉及一种安全通信的方法及设备。


背景技术：

2.当前在基于超文本传输协议(hyper text transfer protocol，http)协议的通信场景下，要达到客户端和服务端之间的安全通信，通常采用将http升级为超文本传输安全协议(hyper texttransfer protocol over securesocketlayer，https)的方式。https依赖安全套接字(secure sockets layer，ssl)协议或传输层安全(transport layer security，tls)协议建立安全通道，完成传输内容加密，保障数据传输的安全性。现有的https加密方式会对数据报文的头部和实体都进行加密，而无法精准地仅对需要加密的特定数据加密。
3.然而，在很多情况下，报文头部的数据较多且无加密的必要，只有实体数据比较重要需要加密，因而现有的https加密方式对传输的数据报文进行无差别加密，会导致通信效率降低。


技术实现要素：

4.本技术提供了一种安全通信的方法及设备，通过在http报文头部的扩展字段携带生成协商密钥的相关参数，使客户端和服务端基于http协议实现安全通信，以解决在http通信时无法有针对性地对特定数据进行加密的问题。
5.第一方面，提供了一种安全通信的方法，应用于客户端，包括：向服务端发送第一超文本传输协议http请求报文，所述第一http请求报文头部的扩展字段包括第一密钥协商参数；接收所述服务端发送的第一http响应报文，所述第一http响应报文头部的扩展字段包括第二密钥协商参数；根据所述第一密钥协商参数和所述第二密钥协商参数生成协商密钥，所述协商密钥用于所述客户端和所述服务端进行加密通信；根据所述协商密钥生成http加密报文，并向所述服务端发送所述http加密报文，所述http加密报文头部的扩展字段包括第一加密策略信息，所述第一加密策略信息用于指示所述http加密报文中的加密数据的类型或者加密数据的位置。
6.其中，协商密钥例如可以是客户端和服务端基于http通信时加密所采用的主密钥，协商密钥主要用户客户端与服务端基于http协议安全通信过程中对数据进行加密。
7.根据本技术实现方式提供的安全通信的方法，通过将客户端和服务端计算生成协商密钥的相关参数携带在http请求报文和/或http响应报文的头部的扩展字段中，能够使得客户端和服务端在基于http协议通信的过程中协商生成密钥，从而实现在http通信架构的基础上实现安全通信，满足用户对数据加密准确、高效的需求。此外，通过在报文头部的扩展字段携带指示加密数据类型或加密数据位置的加密策略信息，能使对端基于该指示信息高效准确地对加密数据进行解密，顺利读取报文，从而提高了通信的效率。
8.结合第一方面，在第一方面的某些实现方式中，所述根据所述协商密钥生成http
加密报文，具体包括：根据所述协商密钥，对所述http加密报文中的目标类型的数据进行加密；或者，根据所述协商密钥，对所述http加密报文中的目标位置的数据进行加密。
9.其中，需要加密的加密数据的类型例如可以包括与协商生成密钥相关的参数等重要数据。
10.示例性的，使用协商密钥加密的数据可以包括http加密报文的实体数据(全部或部分实体数据)，或者，也可以包括http加密报文头部的数据。换言之，当获取协商密钥后，客户端(或服务端)可以根据通信需要或数据类型等，有针对性的对特定数据进行加密。
11.根据本技术实现方式提供的安全通信的方法，通过有针对性地对特定数据进行加密，能够有针对性的对特定数据进行加密，加密更加灵活，能够满足不同的加密需求，并且可以在保证重要数据安全性的基础上，节约加密计算资源，提高安全通信的效率。
12.结合第一方面，在第一方面的某些实现方式中，所述目标类型的数据包括以下至少一项：密钥协商的参数、加密算法集、所述客户端或所述服务端的证书、加密策略信息。
13.结合第一方面，在第一方面的某些实现方式中，所述目标位置的数据包括以下至少一项：位于所述第二http请求报文头部的部分数据；或者，位于所述第二http请求报文实体部分的部分数据；或者，位于所述第二http请求报文实体部分的全部数据。
14.结合第一方面，在第一方面的某些实现方式中，所述http加密报文头部的扩展字段还包括第二加密策略信息，所述第二加密策略信息用于指示所述服务端对所述目标类型的数据进行加密和/或对所述目标位置的数据进行加密。
15.根据本技术实现方式提供的安全通信的方法，通过向通信对端通知加密策略，能够使通信两端采用相同的通信策略对特定的数据进行加密，从而提高通信两端在通信过程中加解密的效率。
16.结合第一方面，在第一方面的某些实现方式中，所述http加密报文头部的扩展字段还包括第三加密策略信息，所述第三加密策略信息用于指示以下至少一项信息：当生成所述协商密钥后，对所述服务端和所述客户端之间每次传输的报文进行加密；或者，当生成所述协商密钥后，每个n次传输间隔，重新生成新的所述协商密钥，n为大于1的整数。
17.根据本技术实现方式提供的安全通信的方法，通过通知对端加密策略，可以使得通信两端按照相同的策略进行通信或更新协商密钥，从而保证安全通信的顺利进行。
18.结合第一方面，在第一方面的某些实现方式中，所述第一http响应报文头部的扩展字段还包括所述服务端的证书，所述服务端的证书包括所述服务端的公钥，所述方法还包括：对所述服务端的证书进行认证，并获取所述服务端的公钥；根据所述服务端的公钥生成所述客户端的预主密钥；向所述服务端发送第二http请求报文，所述第二http请求报文头部的扩展字段包括所述预主密钥。
19.应理解，本技术实现方式中，http请求报文和/或http响应报文头部的扩展字段可以根据通信需求自定义，如可以携带与生成密钥相关的参数等。从而实现客户端与服务端在基于http协议通信时，也能实现加密通信，克服现有的http明文通信方式中存在的信息安全问题。
20.根据本技术实现方式提供的安全通信的方法，通过在http请求报文或http响应报文的报文头部中的扩展字段携带协商生成密钥的参数，可以使得客户端和服务端基于http协议实现安全通信，并且可以根据需要对每次传输的报文或报文中的特定数据进行灵活的
加密，从而在保证安全通信的基础上，进一步提高了通信的效率。
21.结合第一方面，在第一方面的某些实现方式中，所述第一密钥协商参数为所述客户端生成的第一随机数，所述第二密钥协商参数为所述服务端生成的第二随机数；所述根据所述第一密钥协商参数和所述第二密钥协商参数生成协商密钥，具体包括：根据所述第一随机数、所述第二随机数和所述预主密钥生成所述协商密钥。
22.其中，第一密钥协商参数、第二密钥协商参数以及预主密钥均属于生成协商密钥的相关参数，可以用于客户端和服务端生成协商密钥。该第一密钥协商参数例如可以是客户端随机生成的随机数，如random
‑
c；该第二密钥例如可以是服务端随机生成的随机数，如random
‑
s；预主密钥可以是客户端基于服务端的公钥对某一随机数加密后生成的加密数据。
23.根据本技术实现方式提供的安全通信的方法，通过在http请求报文或http响应报文的报文头部中的扩展字段携带协商生成密钥的参数，可以使得客户端和服务端基于http协议实现安全通信，并且可以根据需要对每次传输的报文或报文中的特定数据进行灵活的加密，从而在保证安全通信的基础上，进一步提高了通信的效率。
24.结合第一方面，在第一方面的某些实现方式中，所述第一http请求报文头部的扩展字段还包括所述客户端支持的加密算法集。
25.其中，加密算法集可以包括客户端支持的至少一个加密算法。该加密算法集用于服务端从中选取该服务端也同样支持的加密算法，如第一加密算法，以使客户端和服务端后续根据该第一加密算法计算协商密钥。
26.根据本技术实现方式提供的安全通信的方法，通过客户端向服务端发送加密算法集，可以便于服务端从中选择服务端和客户端均支持的加密算法，从而使客户端或服务端后续能基于该加密算法成功计算协商密钥，提高协商密钥计算的成功率和效率。
27.结合第一方面，在第一方面的某些实现方式中，所述第一http响应报文头部的扩展字段还包括第一加密算法，所述第一加密算法为所述加密算法集中所述服务端支持的任一加密算法。
28.其中，第一加密算法可以是服务端由加密算法集中选取的自身也支持的加密算法，也即第一加密算法为客户端和服务端均支持的加密算法。
29.根据本技术实现方式提供的安全通信的方法，通过服务端选择自身支持的第一加密算法，并将选取的第一加密算法通知给客户端，客户端和服务端后续可以使用相同的加密算法计算协商密钥，保证客户端和服务端计算获得的主密钥一致性，从而实现基于http协议的加密安全通信。
30.结合第一方面，在第一方面的某些实现方式中，当所述第一http响应报文头部的扩展字段还包括证书请求，所述证书请求用于请求所述客户端的证书时，所述第二http请求报文头部的扩展字段还包括所述客户端的证书。
31.第二方面，提供了一种安全通信的方法，应用于服务端，包括：接收客户端发送的第一超文本传输协议http请求报文，所述第一http请求报文头部的扩展字段包括所述客户端的第一密钥协商参数；响应于所述第一http请求报文，向所述客户端发送第一http响应报文，所述第一http响应报文头部的扩展字段包括所述服务端的第二密钥协商参数和所述服务端的证书，所述服务端的证书包括所述服务端的公钥；接收所述客户端发送的第二
http请求报文，所述第二http请求报文头部扩展字段包括所述客户端的预主密钥；根据所述第一密钥协商参数、所述第二密钥协商参数和所述预主密钥生成协商密钥，所述协商密钥用于所述客户端与所述服务端进行加密通信。
32.其中，协商密钥例如可以是客户端和服务端基于http通信时加密所采用的主密钥，协商密钥主要用户客户端与服务端基于http协议安全通信过程中对数据进行加密。
33.根据本技术实现方式提供的安全通信的方法，通过将客户端和服务端计算生成协商密钥的相关参数携带在http请求报文和/或http响应报文的头部的扩展字段中，能够使得客户端和服务端在基于http协议通信的过程中协商生成密钥，从而实现在http通信架构的基础上实现安全通信，满足用户对数据加密准确、高效的需求。
34.结合第二方面，在第二方面的某些实现方式中，所述方法还包括：接收所述客户端发送的http加密报文，所述http加密报文头部的扩展字段包括第一加密策略信息，所述第一加密策略信息用于指示所述加密数据的类型或者所述加密数据的位置；根据所述第一加密策略信息，解密所述加密数据。
35.其中，需要加密的加密数据的类型例如可以包括与协商生成密钥相关的参数等重要数据。
36.示例性的，使用协商密钥加密的数据可以包括http加密报文的实体数据(全部或部分实体数据)，或者，也可以包括http加密报文头部的数据。换言之，当获取协商密钥后，客户端(或服务端)可以根据通信需要或数据类型等，有针对性的对特定数据进行加密。
37.根据本技术实现方式提供的安全通信的方法，通过在报文头部的扩展字段携带指示加密数据的加密策略信息，能使对端基于该指示信息高效准确地对加密数据进行解密，顺利读取报文，从而提高了通信的效率。
38.结合第二方面，在第二方面的某些实现方式中，所述http加密报文头部的扩展字段还包括第二加密策略信息，所述第二加密策略信息用于指示所述服务端对所述目标类型的数据进行加密和/或对所述目标位置的数据进行加密，所述方法还包括：根据所述第二加密策略信息和所述协商密钥，对所述目标类型的数据和/或所述目标位置的数据进行加密。
39.结合第二方面，在第二方面的某些实现方式中，所述目标类型的数据包括以下至少一项：密钥协商的参数、加密算法集、所述客户端或所述服务端的证书、加密策略信息。
40.结合第二方面，在第二方面的某些实现方式中，所述目标位置的数据包括以下至少一项：位于所述http加密报文头部的部分数据；或者，位于所述http加密报文实体部分的部分数据；或者，位于所述http加密报文实体部分的全部数据。
41.结合第二方面，在第二方面的某些实现方式中，所述http加密报文头部的扩展字段还包括第三加密策略信息，所述第三加密策略信息用于指示以下至少一项信息：当生成所述协商密钥后，对所述服务端和所述客户端之间每次传输的报文进行加密；或者，当生成所述协商密钥后，每个n次传输间隔，重新生成新的所述协商密钥，n为大于1的整数。
42.结合第二方面，在第二方面的某些实现方式中，所述第一密钥协商参数为所述客户端生成的第一随机数，所述第二密钥协商参数为所述服务端生成的第二随机数。
43.根据本技术实现方式提供的安全通信的方法，通过服务端选择自身支持的第一加密算法，并将选取的第一加密算法通知给客户端，客户端和服务端后续可以使用相同的加密算法计算协商密钥，保证客户端和服务端计算获得的主密钥一致性，从而实现基于http
协议的加密安全通信。
44.结合第二方面，在第二方面的某些实现方式中，所述第一http请求报文头部的扩展字段还包括所述客户端支持的加密算法集，所述方法还包括：根据所述加密算法集选择所述服务端支持的第一加密算法。
45.其中，加密算法集可以包括客户端支持的至少一个加密算法。该加密算法集用于服务端从中选取该服务端也同样支持的加密算法，如第一加密算法，以使客户端和服务端后续根据该第一加密算法计算协商密钥。
46.根据本技术实现方式提供的安全通信的方法，通过客户端向服务端发送加密算法集，可以便于服务端从中选择服务端和客户端均支持的加密算法，从而使客户端或服务端后续能基于该加密算法成功计算协商密钥，提高协商密钥计算的成功率和效率。
47.结合第二方面，在第二方面的某些实现方式中，所述第一http响应报文头部的扩展字段还包括证书请求信息，所述证书请求信息用于请求所述客户端的证书。
48.结合第二方面，在第二方面的某些实现方式中，所述第二http请求报文还包括所述客户端的证书，所述方法还包括：根据所述客户端的证书验证所述客户端的身份。
49.根据本技术实现方式提供的安全通信的方法，通过证书验证通信端的身份，能够保证客户端(或服务端)是合法的身份，从而保证通信过程的安全性。结合第二方面，在第二方面的某些实现方式中，所述http加密报文头部扩展字段还包括所述协商密钥的加密策略，所述加密策略包括以下至少一项：当生成所述协商密钥后，对所述服务端和所述客户端之间每次传输的报文进行加密；或者，当生成所述协商密钥后，每个n次传输间隔，重新生成新的协商密钥；或者，当所述服务端和所述客户端之间传输的报文包括目标类型的数据时，使用所述协商密钥对所述目标类型的数据进行加密。
50.根据本技术实现方式提供的安全通信的方法，当获取协商密钥后，客户端(或服务端)可以根据通信需要或数据类型等，有针对性的对特定数据进行加密，加密更加灵活，能够满足不同的加密需求。
51.第三方面，提供了一种客户端设备，包括至少一个处理器、存储器和通信接口，所述通信接口用于和其他设备进行通信，所述存储器包括计算机程序指令，当所述计算机程序指令在所述处理器中执行时，使得所述客户端设备实现如上述第一方面中任一实现方式所述的安全通信的方法。
52.第四方面，提供了一种服务端设备，包括至少一个处理器、存储器和通信接口，所述通信接口用于和其他设备进行通信，所述存储器包括计算机程序指令，当所述计算机程序指令在所述处理器中执行时，使得所述客户端设备实现如上述第二方面中任一实现方式所述的安全通信的方法。
53.第五方面，提供了一种安全通信的系统，包括客户端设备和服务端设备，所述客户端设备用于执行如上述第一方面中任一项实现方式所述的安全通信的方法，所述服务端设备用于执行如上述第二方面中任一项实现方式所述的安全通信的方法。
54.第六方面，提供了一种计算机可读存储介质，所述计算机可读存储介质存储有计算机可执行程序，所述计算机可执行程序在被计算机调用时，使所述计算机执行如上述第一方面中任一实现方式所述的方法，或执行如上述第二方面中任一实现方式所述的方法。
55.第七方面，提供了一种芯片系统，包括：通信接口，用于输入和/或输出信息；存储
器，用于存储计算机可执行程序；处理器，用于执行所述极端及可执行程序，使得安装有所述芯片系统的设备执行如上述第一方面中任一实现方式所述的方法，或执行如上述第二方面中任一实现方式所述的方法。
56.第八方面，提供了一种计算机程序产品，所述计算机程序产品包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机实现如上述第一方面任一实现方式所述的方法，或实现如上述第二方面任一实现方式所述的方法。
附图说明
57.图1是本技术实施例提供的一种安全通信的系统架构的示意图。
58.图2是本技术实施例提供的一种基于http协议通信时的电子设备的结构示意图。
59.图3是本技术实施例提供的一种基于https协议通信时的电子设备的结构示意图。
60.图4是本技术实施例提供的一种报文结构示意图。
61.图5是本技术实施例提供的另一种报文结构示意图。
62.图6是本技术实施例提供的另一种安全通信的方法的示意性流程图。
63.图7是本技术实施例提供的又一种安全通信的方法的示意性流程图。
64.图8是本技术实施例提供的一种客户端设备的结构示意图。
65.图9是本技术实施例提供的一种服务端设备的结构示意图。
66.图10是本技术实施例提供的另一种客户端设备的结构示意图。
67.图11是本技术实施例提供的另一种服务端设备的结构示意图。
具体实施方式
68.需要说明的是，本技术实施例的实施方式部分使用的术语仅用于对本技术的具体实施例进行解释，而非旨在限定本技术。在本技术实施例的描述中，除非另有说明，“/”表示或的意思，例如，a/b可以表示a或b；本文中的“和/或”仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，在本技术实施例的描述中，除非另有说明，“多个”是指两个或多于两个，“至少一个”、“一个或多个”是指一个、两个或两个以上。
69.以下，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”特征可以明示或者隐含地包括一个或者更多个该特征。
70.在本说明书中描述的参考“一个实施例”或“一些实施例”等意味着在本技术的一个或多个实施例中包括结合该实施例描述的特定特征、结构或特点。由此，在本说明书中的不同之处出现的语句“在一个实施例中”、“在一些实施例中”、“在其他一些实施例中”、“在另外一些实施例中”等不是必然都参考相同的实施例，而是意味着“一个或多个但不是所有的实施例”，除非是以其他方式另外特别强调。术语“包括”、“包含”、“具有”及它们的变形都意味着“包括但不限于”，除非是以其他方式另外特别强调。
71.本技术实施例的技术方案可以应用于各种通信系统。例如：全球移动通讯(global system of mobile communication，gsm)系统、码分多址(code division multiple access，cdma)系统、宽带码分多址(wideband code division multiple access，wcdma)系
统、通用分组无线业务(general packet radio service，gprs)、长期演进(long term evolution，lte)系统、lte频分双工(frequency division duplex，fdd)系统、lte时分双工(time division duplex，tdd)、通用移动通信系统(universal mobile telecommunication system，umts)、全球互联微波接入(worldwide interoperability for microwave access，wimax)通信系统、未来的第五代(5th generation，5g)系统或新无线(new radio，nr)等。
72.如背景技术所介绍，目前基于https的安全通信过程，会对报文的头部数据和实体数据均进行加密，无法精准地仅针对需要加密的特定数据加密。此外，在基于https协议的通信过程中，通常客户端和服务端会对每次交互所发送的数据均进行加密处理，而不会根据数据的重要性确定是否对某一次传输的数据进行加密。因此，现有的基于https协议的安全通信过程无法根据重要性有针对性地对特定数据灵活加密，导致通信效率较低。
73.针对上述问题，本技术实施例提供了一种安全通信的方法，通过在http报文的头部扩展字段中携带加密协商信息，使客户端和服务端可以在基于http协议通信过程中协商加密信息，实现仅对存在加密必要性的特定数据进行加密，从而节省加密计算资源，提升安全通信效率。
74.为更加清楚地理解本技术实施例中的各种实现方式，以下首先对本技术实施例中涉及的技术术语进行定义或说明。
75.(1)ssl协议、tls协议：为目前使用十分广泛的应用层的安全加密传输协议。其中，tls协议是ssl协议的升级版本，二者都用于保护传输控制协议(transmission control protocol，tcp)连接的数据，因而ssl和tls有时可以并用。当前广泛使用的https安全通信方式，可以理解为在http协议基础上，按照ssl/tls协议进行的安全通信方式。
76.(2)报文(packet)：在本技术实施例中也可以描述为包，例如数据包也是一种报文。本技术实施例中客户端和服务端之间基于http协议的数据流中可以包括多个报文。
77.(3)握手报文(handshake packet)：客户端和服务端之间用于通过安全加密传输协议建立连接的报文。在现有的基于https协议通信的过程中，握手报文可以出现在tls、ssl等连接的握手阶段。在本技术实施例提供的安全通信的方法中，握手报文可以出现在客户端与服务端的握手阶段。在本技术以下实施例中，握手报文又可以被具体描述为握手请求消息、握手响应消息，其中，握手请求消息可以是客户端发送给服务端，用于请求与服务端建立连接的消息，握手响应消息可以是服务端向客户端反馈的握手信息。
78.(4)扩展字段：http协议采用请求
‑
响应(request
‑
response)模式工作，即客户端向服务端发送http请求报文(或称http请求消息)以请求资源，服务端向客户端发送http响应报文(或称http响应消息)以响应客户端的请求。http请求/响应报文可以包括头部(header)和净荷(payload)(或称载荷、实体)。由于http协议具有较好的扩展性，http报文的头部可以有多个可扩展字段。客户端和服务端在基于http协议进行通信过程中，可以通过修改或填写http报文头部中的字段内容来实现传输多种类型数据的需求。本技术实施例将在http报文头部的可扩展的字段描述为扩展字段。
79.示例性的，如图1所示，为本技术实施例提供的一种安全通信的系统架构示意图。该系统架构包括作为客户端的电子设备100和作为服务端的服务器200。
80.在一些实施例中，电子设备100可以为具有网络访问能力的计算设备，如工作站、
台式个人计算机或膝上个人计算机、个人数字助手(personal digital assistant，pda)、个人电脑(personal computer，pc)、具有无线通信功能的手持设备(如手机、平板电脑)、车载设备、可穿戴设备、机顶盒、智能传感器、智能医疗设备、智能电视机等，或者第五代移动通信技术(5
th generation，5g)网络中的终端设备或者未来演进的公用陆地移动通信网络(public land mobile network，plmn)中的终端设备等，本技术实施例对此不作限定。
81.在一些实施例中，服务器200可以包括处理器和计算机可读存储介质，该计算机可读存储介质存储有计算机可读程序代码，当处理器执行该计算机可读程序代码时，使得本技术实施例中的方法得以实现。示例性的，计算机可读程序代码可以将服务器200实现为网络(web)服务器、文件服务器、视频服务器、数据库服务器、应用服务器、语音系统、会议服务器、媒体网关、媒体中心等多种可以使用http协议向客户端100提供网络或应用服务的服务器。
82.示例性的，如图2所示，为本技术实施例提供的一种电子设备的结构示意图。该电子设备可以为图1所示的作为客户端的电子设备100。
83.在一些实施例中，电子设备100可以包括应用层(application layer)、传输层(transport layer)、网络层(network layer)和数据链路层(data link layer)。其中，应用层用于向用户提供应用服务时的通信活动，http协议存在于该层。传输层，用于提供处理连接中的客户端和服务端之间的数据传输，可以包括tcp协议。网络层，用于处理在网络上传输的数据包，该层规定了通过怎样的路径将数据包传输至对端，该层可以包括互联网协议(internet protocol，ip)。链路层，用于处理连接网络的硬件部分，如控制操作系统、硬件的设备驱动、网卡、光纤等物理可见的部分。在本技术实施例提供的安全通信过程中，http层数据加上tcp头和ip头，就可以构成在互联网上传输的ip包。
84.应理解，相对于现有的https安全通信基础(如图3所示)来说，在本技术实施例提供的安全通信的方法中，应用层无需包括ssl安全加密传输协议或tls安全加密传输协议(如图3所示的tls握手协议、tls改变密码标准协议、tls警报协议以及tls记录协议等)，而是以现有的http网络分层作为通信基础即可，无需对现有的http网络分层架构进行改动。
85.为更好地理解本技术实施例提供的安全通信的方法，以下结合附图，对http报文格式进行介绍。示例性的，如图4所示，为本技术实施例提供的一种报文格式的示意图。
86.在一些实施例中，图4所示的报文格式包括网际互联协议(internet protocol，ip)头、传输控制协议(transmission control protocol，tcp)头以及http报文。其中，ip头和tcp头可以包括客户端和服务端的通信地址，如客户端的ip地址和端口号、服务端的ip地址和端口号，以及其他数据，如序号、标志位、窗口大小等。应理解，ip头和tcp头包括的信息可以参见现有的ip协议和tcp协议，本技术对此不再详述。
87.在一些实施例中，http报文格式可以参见图4右侧所示，包括起始行(start line)、头部(header)、空行(crlf)以及实体(entity/body)。
88.以http报文是http请求报文为例对http各部分包括的具体信息内容进行介绍。如图5所示，为本技术实施例提供的一种http请求报文格式的示意图。
89.在一些实施例中，http请求报文(request)可以具体包括：请求行(对应于图4中的起始行)、请求头(对应于图4中的http报文头部)、空行和请求体(对应于图4中的实体)。其中，请求行可以包括请求方式(method)、统一资源定位符(uniform resource location，
url)、版本信息(version)等信息，各项信息之间可以间隔有空格，请求行末尾由回车(\r)和换行(\n)结尾；请求头可以包括请求头参数；请求头与请求体之间由空行隔开；请求体可以包括传输的具体数据，本技术对请求体中的具体数据类型不作限定。
90.值得注意的是，在本技术实施例中，http报文的头部(如http请求报文的请求头，或http响应报文的响应头)还可以包括扩展字段，在基于http协议进行通信过程中，客户端和服务端可以通过修改或填写http报文头部中扩展字段的内容来实现传输多种类型数据的需求。示例性的，该扩展字段可以包括用于客户端与服务端协商生成密钥的参数以及指示加密策略的信息(如对哪些特定数据进行加密的指示信息)等。换言之，在本技术实施例提供的安全通信的方法中，客户端与服务端可以将协商密钥的参数等填写在http报文头部的扩展字段中，以实现基于http协议加密通信、保障传输数据安全的目的。
91.在一些实施例中，当扩展字段的格式满足http协议的规定，能够使客户端或服务端成功读取其携带的信息内容时，该扩展字段可以在请求头的任意位置，本技术实施例对扩展字段在请求头中的具体位置不作限定。
92.在一些实施例中，可以根据通信需求自定义http报文头部的扩展字段；或者，也可以参照现有的https通信过程所涉及的字段(如https报文的头部字段)定义http报文头部的扩展字段但本技术对此不作限定。例如，本技术实施例中http报文的扩展字段可以按照现有的https头部字段的以下特点进行定义：(1)不区分大小写；(2)字段名里和字段名后不出现空格，冒号(:)后可有多个空格，不使用_，可使用
‑
；(3)字段顺序无意义；(4)字段不能重复等。
93.示例性的，按照扩展字段描述内容的类型，本技术实施例中http报文的扩展字段例如可以具体定义为以下四类：(1)握手字段，可以用于表示客户端要与服务器端建立安全通信；(2)记录字段，可以用于在客户端和服务器握手成功后使用，可以表示协商生成密钥的相关内容；(3)变更密码规范字段，可以用来表示需要变更密钥，示例性的，如果变更密码规范字段和/或握手字段内容太多，可以将这些字段的内容拆分，用记录字段表示其中部分内容；(4)保留字段，可以是备用字段，用来表示其他含义的信息。应理解，这四类字段可以根据实际需要携带在请求消息或响应消息中，而不需要每次请求/响应时同时被携带。
94.应理解，http响应报文(response)与请求报文的格式类似，当服务端与客户端协商密钥时，可以将相关参数填写在响应报文头部的扩展字段中。为描述简洁，此处对http响应报文的格式不再进行具体介绍。
95.还应理解，图5所示的http请求报文的格式仅为示例，在实际应用中，http请求报文可以包括比图5所示更多类型的数据，也可以具有比图5所示更复杂的格式，本技术实施例对此不作限定。
96.示例性的，本技术实施例提供的一种安全通信的方法可以由客户端和服务端作为主体执行，包括以下步骤：
97.s101，向服务端发送第一超文本传输协议http请求报文，该第一http请求报文头部的扩展字段包括第一密钥协商参数。
98.其中，第一http请求报文的格式可以如图5所示。
99.在一些实施例中，第一http请求报文头部的扩展字段包括的第一密钥协商参数可以为客户端随机生成的第一随机数，该第一随机数例如为random
‑
c，并且该第一随机数可
以用于客户端和服务端生成协商密钥。
100.在一些实施例中，第一http请求报文头部的扩展字段还可以包括客户端支持的加密算法集，换言之，该加密算法集可以包括多个客户端支持的加密算法。服务端接收第一http请求报文后，可以由加密算法集中选择该服务端能够支持的第一加密算法，该第一加密算法即可用于之后计算协商密钥。
101.s102，接收服务端发送的第一http响应报文，该第一http响应报文头部的扩展字段包括第二密钥协商参数。
102.在一些实施例中，服务端接收第一http请求报文，并响应于该第一http请求报文，生成第一http响应报文。其中，第一http响应报文头部的扩展字段包括的第二密钥协商参数可以为服务端随机生成的第二随机数，该第二随机数例如为random
‑
s，并且该第二随机数可以用于客户端和服务端生成协商密钥。
103.在一些实施例中，第一http响应报文头部的扩展字段还可以包括服务端的证书(或称公钥证书)，该服务端的证书包括服务端的公钥。在一些实施例中，客户端接收第一http响应报文后，可以对服务端的证书进行认证，认证通过后，根据该服务端的证书获取该服务端的公钥，然后根据该服务端的公钥生成客户端的预主密钥。示例性的，客户端生成预主密钥的过程可以为：客户端可以利用服务端的公钥对随机生成的某一随机数(可以与第一随机数、第二随机数不相同)进行加密，生成该客户端的预主密钥。
104.在一些实施例中，客户端可以向服务端发送第二http请求报文，该第二http请求报文头部的扩展字段可以包括客户端的预主密钥。服务端接收该第二http请求报文，并可以根据存储于服务端本地的私钥对客户端的预主密钥进行解密，其中，若服务端成功解密预主密钥，则确定客户端获取的服务端的公钥为正确的。之后，服务端可以根据第一密钥协商参数、第二密钥协商参数和预主密钥生成协商密钥。
105.在一些实施例中，第一http响应报文头部的扩展字段还包括第一加密算法，该第一加密算法为加密算法集中服务端支持的任一加密算法。换言之，该第一加密算法为客户端和服务端均支持的加密算法，因而可以用于客户端和服务端后续计算协商密钥。
106.在一些实施例中，第一http响应报文头部的扩展字段还可以包括证书请求，该证书请求用于请求客户端的证书。响应于服务端的证书请求，客户端可以在发送至服务端的第二http请求报文头部的扩展字段携带客户端的证书，以使服务端根据该证书对客户端进行身份认证。
107.s103，根据第一密钥协商参数和第二密钥协商参数生成协商密钥，该协商密钥用于客户端和服务端进行加密通信。
108.在一些实施例中，客户端可以根据上述获取的第一随机数、第二随机数以及生成的预主密钥生成协商密钥，该协商密钥可以是客户端和服务端候选进行安全通信的主密钥(或公钥)，协商密钥在以下实施例中还可以被描述为主密钥。
109.在一些实施例中，服务端接收客户端的第二http请求报文后，解密获取预主密钥，之后，服务端可以根据获取的第一随机数、第二随机数以及预主密钥生成协商密钥。
110.s104，根据协商密钥生成http加密报文，并向服务端发送该http加密报文，该http加密报文头部的扩展字段包括第一加密策略信息，第一加密策略信息用于指示http加密报文中的加密数据的类型或者加密数据的位置。
111.在一些实施例中，当客户端生成协商密钥后，可以利用该协商密钥对http加密报文进行加密。示例性的，客户端可以根据预设的加密策略对该http加密报文加密，例如，根据协商密钥，对http加密报文中的目标类型的数据进行加密；或者，根据协商密钥，对http加密报文中的目标位置的数据进行加密。其中，目标类型的数据可以包括以下至少一项：密钥协商的参数、加密算法集、所述客户端或所述服务端的证书、加密策略信息(如第一加密策略信息以及下文提及的第二加密策略信息、第三加密策略信息等)；目标位置的数据可以包括以下至少一项：位于http加密报文头部的部分数据；或者，位于http加密报文实体部分的部分数据；或者，位于http加密报文实体部分的全部数据。
112.可选地，http加密报文头部的扩展字段可以包括第一加密策略信息，该第一加密策略信息可以用于指示加密数据的类型或者加密数据的位置；服务端接收http加密报文后，可以根据该第一加密策略信息，解密http加密报文中的加密数据。
113.应理解，服务端根据第一加密策略信息可以准确且有针对性地对http加密报文中的加密数据进行解密，能够提高服务端的解密效率。
114.在一些实施例中，客户端和服务端可以预先设定加密策略，如需要对哪些类型的数据进行加密、需要对哪些位置的数据进行加密、协商密钥的使用周期等。在通信过程中，客户端可以通过http加密报文将该客户端选择的加密策略通知给服务端。具体地，http加密报文头部的扩展字段还可以包括第二加密策略信息，该第二加密策略信息可以用于指示服务端对目标类型的数据进行加密和/或对目标位置的数据进行加密。http加密报文头部的扩展字段还可以包括第三加密策略信息，该第三加密策略信息可以用于指示以下至少一项信息：当生成协商密钥后，对服务端和客户端之间每次传输的报文进行加密(即一次一密)；或者，当生成协商密钥后，每n次传输间隔，重新生成新的协商密钥(即多次一密)，n为大于1的整数。服务端接收http加密报文后，可以根据第二加密策略目标类型的数据进行加密，或者，可以根据第二加密策略目标位置的数据进行加密；还可以根据第三加密策略，与客户端按照一次一密的方式通信，或者与客户端按照多次一密的方式通信。
115.根据本技术实施例提供的安全通信的方法，通过在http请求报文或http响应报文的报文头部中的扩展字段携带协商生成密钥的参数，可以使得客户端和服务端基于http协议实现安全通信，并且可以根据需要对每次传输的报文或报文中的特定数据进行灵活的加密，从而在保证安全通信的基础上，进一步提高了通信的效率。
116.为更加清楚地理解本技术实施例提供的安全通信的方法，以下结合附图6和附图7，对该安全通信方法的过程进行更加详细的说明。示例性的，如图6所示，为本技术实施例提供的一种安全通信的示意性流程图。该过程可以由客户端(client)和服务端(server)执行，其中，客户端例如可以是上述图1中的电子设备100，服务端可以是上述图1中的服务器200。
117.应理解，在客户端和服务端按照图6所示的过程进行http通信之前，需要先建立tcp通信连接，也即需要完成三次握手(tcp handshake)的交互过程。关于该三次握手的具体过程可以参见现有流程，此处不再详述。客户端和服务端完成tcp连接之后，可以按照图6所示的过程进行http握手、证书/密钥/密码协商与交换(certificate/key/ciper spec negotiation and exchange)以及握手完成(handshake complete)阶段。示例性的，本技术实施例提供的安全通信的方法包括以下步骤：
118.s601，客户端向服务端发送第一http请求报文。
119.其中，第一http请求报文可以为客户端向服务端发送的客户端问候报文(client
‑
hello)。该第一http请求报文的头部(请求头)可以包括扩展字段，该扩展字段携带的信息可以用于指示支持http协议与加密算法的相关参数以及其他辅助信息(如服务器名称指示(server name indication，sni)等)。
120.在一些实施例中，扩展字段在第一http请求报文中的位置例如为图5所示的请求头位置。应理解，若扩展字段的格式符合http协议中的规定，则服务端就可以成功读取握手字段的具体信息，因而本技术实施例对扩展字段在请求头中的更加具体的位置不作限定。
121.具体地，在本步骤中，第一http请求报文中的扩展字段也可以描述为握手字段，其用于客户端和服务端握手并协商生成密钥。该第一http请求报文头部的扩展字段可以包括客户端随机数(random
‑
c)，客户端支持的加密套件列表(cipher suites)等信息。其中，该客户端随机数(random
‑
c)用于后续协商生成密钥。
122.应理解，加密套件列表也可以被描述为加密算法集，该加密套件列表可以包括客户端支持的至少一个加密算法。在一些实施例中，加密套件列表可以具体包括认证算法au、密钥交换算法(key
‑
exchange)、对称加密算法enc以及摘要列表mac，其中，认证算法用于客户端身份验证；密钥交换算法用于客户端与服务端协商密钥；对称加密算法用于客户端与服务端采用对称加密方式对传输数据进行加密；摘要列表用于服务端对接收到的消息的完整性进行校验，摘要列表例如可以包括客户端已向服务端发送过的消息的标识。
123.在一些实施例中，第一http请求报文还可以包括客户端版本信息(version)、客户端时间戳、压缩算法(compression methods)候选列表等信息，其中，客户端版本信息例如用于指示客户端的http协议版本；压缩算法候选列表例如用于后续的信息压缩传输。在另一些实施例中，第一http请求报文还可以包括比上述介绍更多的其他信息，本技术对此不作限定。
124.应理解，该第一http请求报文可以用于客户端与服务端建立tcp连接后的首次握手，由于此时客户端与服务端可能尚未协商生成密钥，因而客户端可以以明文方式传输该第一http请求报文。基于类似的原因，下文中的第一http响应报文等在协商生成密钥之前传输的消息可以均为明文方式。
125.s602，服务端向客户端发送第一http响应报文。
126.在一些实施例中，服务端接收客户端发送的第一http请求报文，并响应于该第一http请求报文与客户端建立会话，存储客户端的随机数(random
‑
c)；并且根据服务端支持的加密算法由加密套件候选列表中选择服务器支持的加密算法。之后，向客户端发送第一http响应报文，返回协商的信息结果。
127.其中，第一http响应报文可以为服务端向客户端发送的服务端问候响应消息(server
‑
hello)。该第一http响应报文的头部(响应头)可以包括扩展字段，该扩展字段携带的信息可以用于指示支持http协议与加密算法的相关参数以及其他辅助信息。
128.在一些实施例中，第一http响应报文头部的扩展字段可以包括服务端向客户端发送的随机数(random
‑
s)和服务器支持的加密算法。
129.在一些实施例中，第一http响应报文头部的扩展字段还可以包括服务端选择的加密套件(cipher suit)，如服务端的证书(certificate)。
130.在一些实施例中，服务端可以支持多种密钥交换算法，如迪菲－赫尔曼密钥交换(diffie
–
hellman key exchange，dh)算法和rsa算法，其中，当服务端支持的密钥交换算法为dh算法时，该第一http响应报文还可以包括服务端密钥交换(server
‑
key
‑
exchange)信息，如密钥交换(server
‑
key
‑
exchange)信息承载于加密套件(cipher suit)中，密钥交换(server
‑
key
‑
exchange)信息可以包括服务端的dh算法参数；当服务端支持的密钥交换算法为rsa算法时，该第一http响应报文无需包括服务端密钥交换(server
‑
key
‑
exchange)信息。
131.在一些实施例中，如果服务端要求客户端使用证书验证身份，则该第一http响应报文的扩展字段还可以包括服务端发送的证书请求(certificate request)信息。可选地，第一http响应报文还可以包括服务端问候完成(server
‑
hello
‑
done)信息。其中，第一http响应报文的扩展字段包括的各个信息的具体描述如下：
132.(1)随机数(random
‑
s)和服务端支持的加密算法：用于后续生成密钥。
133.(2)服务端的证书(certificate)：可以用于向客户端表明该服务端身份的合法性和真实性，例如服务端的身份不是被假冒的服务端，该证书报文可以具体包括服务端配置的数字证书到证书签发机构(certification authority，ca)的证书链。
134.(3)服务端密钥交换(server key exchange)信息：基于服务端支持的密钥交换算法确定是否向客户端发送该服务端密钥交换信息，示例性的，当服务端支持dh算法时，服务端可以向客户端发送该密钥交换信息，该密钥交换信息可以包括服务端dh参数；而当服务端支持rsa算法时，服务端可以无需向客户端发送该密钥交换信息。
135.(4)证书请求(certificate reuqest)信息：用于向客户端请求证书，以使服务端认证客户端身份。
136.(5)服务端问候完成(server
‑
hello
‑
done)信息：可以用于告知客户端，服务端的第一http相应消息中的这一组报文均已发送，客户端可以发送接下来的报文。
137.在一些实施例中，第一http响应报文的扩展字段可以位于第一http响应报文的头部，该扩展字段的格式在满足http协议规范的基础上，其可以位于头部的任意位置，本技术对扩展字段的具体位置不作限定。
138.应理解，第一http响应报文还可以包括比上述介绍更多的其他信息，本技术对此不作限定。
139.s603，客户端向服务端发送第二http请求报文。
140.其中，第二http请求报文可以是客户端向服务端发送的握手请求消息(handshake massage)。
141.在一些实施例中，客户端接收到服务端的第一http响应报文后，可以验证服务端证书的合法性，如果验证通过则进行后续通信，否则根据错误情况不同做出相应的提示和操作。示例性的，证书合法性验证的内容可以包括：(1)证书链的可信性(trusted certificate path)；(2)证书是否吊销(revocation)；(3)有效期(expiry date)，即证书是否在有效时间范围；(4)域名(domain)，即核查证书域名是否与当前的访问域名匹配等。当客户端验证服务端证书合法后，可以向服务端发送第二http请求报文。
142.在一些实施例中，服务端发送给客户端的服务端证书可以包括服务端的公钥。客户端对服务端的证书认证通过后，可以获取该服务端的公钥(或称证书公钥)。
143.在一些实施例中，第二http请求报文头部(请求头)的扩展字段可以包括密钥交换(client
‑
key
‑
exchange)信息。示例性的，当服务端和客户端采用rsa密钥交换算法时，客户端可以利用服务端的公钥对随机生成的随机数进行加密，生成客户端预备主密钥(pre
‑
master)。此时，密钥交换(client
‑
key
‑
exchange)信息可以包括客户端预备主密钥(pre
‑
master)；当客户端和服务端采用dh密钥交换算法时，该客户端密钥交换(client
‑
key
‑
exchange)信息可以包括客户端dh参数。
144.在一些实施例中，客户端接收到服务端的证书请求报文后，可以使用本地私钥签名，生成客户端证书(client
‑
certificate)报文以及包括私钥签名的证书验证(certificate verify)报文。其中，关于各报文的具体描述如下：
145.(1)客户端证书(client
‑
certificate)报文：为客户端响应于服务端的证书请求信息生成的，用于服务端验证客户端身份的合法性。
146.(2)证书验证(certificate verify)报文：用于对预备主密钥和随机数进行签名。
147.s604，服务端计算主密钥。
148.在一些实施例中，主密钥还可以描述为协商密钥。当服务端接收第二http请求报文后，可以根据客户端的预备主密钥(pre
‑
master)和之前交换的两个随机数random
‑
c和random
‑
s计算得到主密钥。
149.在一种实现方式中，当服务端和客户端采用的密钥交换算法为ras算法时，服务端可以首先利用服务端自身存储的私钥解密客户端预备主密钥(pre
‑
master)，之后再根据客户端的预备主密钥(pre
‑
master)和之前交换的两个随机数random
‑
c和random
‑
s，计算得到主密钥，协商生成的主密钥可以为：enc
‑
key＝fnc(random
‑
c,random
‑
s,pre
‑
master)。
150.在另一种实现方式中，当服务端和客户端采用的密钥交换算法为dh算法时，服务端可以根据dh参数计算客户端的预备主密钥(pre
‑
master)，之后再根据客户端的预备主密钥(pre
‑
master)和之前交换的两个随机数random
‑
c和random
‑
s，计算得到主密钥，协商生成的主密钥可以为：enc
‑
key＝fnc(random
‑
c,random
‑
s,pre
‑
master)。
151.可选地，服务端可以针对步骤s603中的第二http请求报文执行步骤s605：服务端向客户端发送第二http响应报文。
152.s606，客户端计算主密钥。
153.在一些实施例中，客户端根据该客户端的预备主密钥(pre
‑
master)以及之前交换的两个随机数random
‑
c和random
‑
s计算客户端与服务端加密安全通信所使用的主密钥(main master)，其中，该主密钥例如为enc
‑
key＝fnc(random
‑
c,random
‑
s,pre
‑
master)。
154.应理解，客户端根据客户端预备主密钥和随机数计算主密钥的步骤(即步骤s606)也可以与步骤s604同时进行或者在步骤s604之前进行，换言之，当客户端获取客户端预备主密钥、随机数(random
‑
c和random
‑
s)等用于计算生成主密钥的参数之后，就可以计算主密钥，而不仅限于按照图6实施例所示的顺序执行该步骤。
155.s607，客户端向服务端发送http加密报文。
156.其中，该http加密报文可以携带变更密码规范字段css，如变更密码规范信息。该http加密报文还可以携带新的加密算法(下称新算法)以协商计算后续数据传输所用的主密钥；该http加密报文还可以包括密钥生成的finish消息，用于告知服务端本次协商生成主密钥已经完毕。其中，finish消息可以是客户端利用协商生成的主密钥对某一字段进行
加密生成的消息，用于服务端验证客户端生成正确的主密钥，具体的加密字段可以根据当前执行的业务类型灵活设定，本技术对此不作限定。
157.在一些实施例中，http加密报文还可以包括摘要列表，该摘要列表例如可以包括在本步骤之前客户端向服务端发送的请求报文的标识。示例性的，该摘要列表例如可以包括客户端在步骤s601发送的第一http请求报文的名称(如client
‑
hello)、客户端在步骤s603发送的第二http请求报文的名称(如handshake massage)等。该摘要列表用于服务端验证接收的消息是否与客户端发送的消息一致，以防止第三方篡改传输的信息，保证信息传输的安全性。
158.在一些实施例中，由于客户端和服务端已经协商生成主密钥(main master)，因而客户端可以利用该主密钥对http加密报文中重要或敏感的特定数据进行加密，如对新算法的相关信息进行加密。
159.在一些实施例中，当客户端利用主密钥对http加密报文中的部分信息进行加密时，该客户端可以在http加密报文头部的扩展字段中携带加密策略信息，该加密策略信息可以用于指示客户端对http加密报文中的何种类型的信息进行了加密，或者对http加密报文中何处位置的信息进行了加密等。
160.应理解，根据本技术实施例提供的方法，客户端不仅可以对请求消息实体部分中的特定数据进行加密，还可以对头部中的特定数据进行加密，如当头部扩展字段携带协商生成后续数据传输将使用的主密钥的相关参数时，可以利用已协商生成的主密钥对该相关参数进行加密。
161.s608，服务端进行信息验证。
162.在一些实施例中，服务端可以利用协商生成的主密钥对finish消息进行解密，如果能成功解密，则表示客户端生成正确的主密钥，后续通信服务端可以使用该主密钥对传输的数据进行加密。
163.在一些实施例中，服务端还可以验证摘要列表，以验证接收的信息是否与客户端发送的信息一致，防止第三方篡改传输的信息，保证信息传输的安全性。
164.应理解，客户端和服务端可以协商或预先设置加密策略，如设置密码更新周期(如传输一次一密；或者，每连续传输n次后，更换密钥，n为大于1的整数)、默认使用密钥对哪部分数据进行加密(如默认使用协商生成的密钥对实体部分的数据进行加密，而不对头部数据进行加密)、默认使用密钥对哪种类型数据进行加密等。因而，如果客户端和服务端需要在后续通信过程中，使用新的密钥时，在本步骤中，服务端还可以根据http加密报文携带的新的加密算法等参数协商计算后续数据传输所用的新的主密钥，该新的主密钥的协商过程与步骤s601至步骤s607类似，此处不再赘述。
165.根据本技术实施例提供的安全通信的方法，通过在http请求报文或http响应报文的报文头部中的扩展字段携带协商生成密钥的参数，可以使得客户端和服务端基于http协议实现安全通信，并且可以根据需要对每次传输的报文或报文中的特定数据进行灵活的加密，从而在保证安全通信的基础上，进一步提高了通信的效率。
166.示例性的，如图7所示，为本技术实施例提供的另一种安全通信的示意性流程图。该过程可以由客户端(client)和服务端(server)执行，其中，客户端例如可以是上述图1中的电子设备100，服务端可以是上述图1中的服务器200。
167.s701，客户端向服务端发送第一http请求报文。
168.s702，服务端向客户端发送第一http响应报文。
169.s703，客户端向服务端发送第二http请求报文。
170.s704，服务端计算服务端主密钥。
171.可选地，服务端可以针对步骤s703中的第二http请求报文执行步骤s705：服务端向客户端发送第二http响应报文。
172.s706，客户端计算主密钥。
173.s707，客户端向服务端发送http加密报文。
174.s708，服务端进行信息验证。
175.应理解，步骤s701至步骤s708可以客户端和服务端握手后首次协商生成密钥的过程，与图6实施例所示的流程类似，具体介绍可以参见上述步骤s601至步骤s608的相关内容，此处不再赘述。区别于图6实施例，图7实施例还包括：当客户端和服务端首次协商生成主密钥后，利用该主密钥对特定数据进行加密，以及协商后续将使用的新的主密钥的过程。该过程可以包括以下步骤：
176.s709，服务端向客户端发送第三http响应报文。
177.应理解，为了保证在http传输过程中的数据安全性，客户端和服务端可以间隔一段时间更改加密规范，如使用新的参数生成新的主密钥。因而，在该步骤中，服务端发送的第三http响应报文可以携带变更密码规范字段css，该变更规范字段css用于指示客户端更改协商生成新的密钥所使用的加解密参数。
178.在一些实施例中，该http加密报文头部的扩展字段还可以包括新算法，该新算法用于服务端和可客户端协商生成后续安全通信使用的新的主密钥。
179.在一些实施例中，该http加密报文还可以包括密钥生成的finish消息，用于告知客户端本次协商生成主密钥已经完毕。其中，finish消息可以是服务端利用协商生成的主密钥对某一字段进行加密生成的消息，用于客户端验证服务端生成正确的主密钥，具体的加密字段可以根据当前执行的业务类型灵活设定，本技术对此不作限定。
180.s710，客户端向服务端发送第四http请求报文。
181.在一些实施例中，当第四http请求报文包括需要加密的数据时，客户端可以使用协商生成的新的主密钥对第四http请求报文中的特定数据进行加密。示例性的，该特定数据可以是第四http请求报文的全部实体数据，或部分实体数据(如任何敏感或重要的实体数据)；或者，该特定数据还可以第四http请求报文的全部头部数据，或部分头部数据(如头部扩展字段中与协商生成后续将使用的新的主密钥相关的参数)。
182.在一些实施例中，第四http请求报文头部的扩展字段可以携带指示信息，该指示信息用于指示第四http请求报文哪些(如哪些位置、哪些类型)的数据被加密。
183.在一些实施例中，当第四http请求报文不包括需要加密的数据时，客户端也可以不对该第四http请求报文进行加密。
184.综上分析，客户端可以根据请求消息包括的数据重要性或敏感性灵活确定是否需要加密或对哪些数据进行加密，从而节省客户端的加密处理资源并且提高数据传输的效率。
185.s711，服务端向客户端发送第四http响应报文。
186.在一些实施例中，当第四http响应报文包括需要加密的数据时，服务端可以使用协商生成的新的主密钥对第四http响应报文中的特定数据进行加密。示例性的，该特定数据可以是第四http响应报文中全部实体数据，或部分实体数据(如任何敏感或重要的实体数据)；或者，该特定数据还可以第四http响应报文中全部头部数据，或部分头部数据(如头部扩展字段中与协商生成后续将使用的新的主密钥相关的参数)。
187.在一些实施例中，第四http响应报文头部的扩展字段可以携带指示信息，该指示信息用于指示第四http响应报文哪些(如哪些位置、哪些类型)的数据被加密。
188.在一些实施例中，当第四http响应报文不包括需要加密的数据时，服务端端也可以不对该第四http响应报文进行加密。
189.综上分析，服务端可以根据响应消息中数据的重要性或敏感性灵活确定是否对该消息中的数据进行加密或对哪些数据进行加密，从而节省客户端的加密处理资源并且提高数据传输的效率。
190.根据本技术实施例提供的安全通信的方法，通过在http请求报文或http响应报文的报文头部中的扩展字段携带协商生成密钥的参数，可以使得客户端和服务端基于http协议实现安全通信，并且可以根据需要对每次传输的报文或报文中的特定数据进行灵活的加密，从而在保证安全通信的基础上，进一步提高了通信的效率。
191.示例性的，如图8所示，为本技术实施例提供的一种服务端设备的结构示意图。该设备800包括发送模块801、接收模块802和密钥生成模块803。
192.在一些实施例中，发送模块801，可以用于向服务端发送第一超文本传输协议http请求报文，所述第一http请求报文头部的扩展字段包括第一密钥协商参数。
193.接收模块802，可以用于接收所述服务端发送的第一http响应报文，所述第一http响应报文头部的扩展字段包括第二密钥协商参数。
194.密钥生成模块803，可以用于根据所述第一密钥协商参数和所述第二密钥协商参数生成协商密钥，所述协商密钥用于所述客户端和所述服务端进行加密通信。
195.发送模块801，还可以用于向所述服务端发送客户端生成的http加密报文，http加密报文头部的扩展字段包括第一加密策略信息，所述第一加密策略信息用于指示所述http加密报文中的加密数据的类型或者加密数据的位置。
196.在一些实施例中，所述根据所述协商密钥生成http加密报文，具体包括：根据所述协商密钥，对所述http加密报文中的目标类型的数据进行加密；或者，根据所述协商密钥，对所述http加密报文中的目标位置的数据进行加密。
197.在一些实施例中，所述目标类型的数据包括以下至少一项：密钥协商的参数、加密算法集、所述客户端或所述服务端的证书、加密策略信息。
198.在一些实施例中，所述目标位置的数据包括以下至少一项：位于所述http加密报文头部的部分数据；或者，位于所述http加密报文实体部分的部分数据；或者，位于所述http加密报文实体部分的全部数据。
199.在一些实施例中，所述http加密报文头部的扩展字段还包括第二加密策略信息，所述第二加密策略信息用于指示所述服务端对所述目标类型的数据进行加密和/或对所述目标位置的数据进行加密。
200.在一些实施例中，所述http加密报文头部的扩展字段还包括第三加密策略信息，
所述第三加密策略信息用于指示以下至少一项信息：当生成所述协商密钥后，对所述服务端和所述客户端之间每次传输的报文进行加密；或者，当生成所述协商密钥后，每n次传输间隔，重新生成新的所述协商密钥，n为大于1的整数。
201.在一些实施例中，客户端设备800还可以包括认证模块，所述第一http响应报文头部的扩展字段还包括所述服务端的证书，所述服务端的证书包括所述服务端的公钥，该认证模块可以用于对所述服务端的证书进行认证，并获取所述服务端的公钥。
202.在一些实施例中，密钥生成模块803，可以用于根据所述服务端的公钥生成所述客户端的预主密钥。
203.在一些实施例中，发送模块801，还可以用于向服务端发送第二http请求报文，第二http请求报文头部的扩展字段包括预主密钥。
204.在一些实施例中，第一密钥协商参数为客户端生成的第一随机数，第二密钥协商参数为服务端生成的第二随机数；密钥生成模块803，具体可以用于根据所述第一随机数、所述第二随机数和所述预主密钥生成所述协商密钥。
205.在一些实施例中，第一http请求报文头部的扩展字段还包括客户端支持的加密算法集。
206.在一些实施例中，第一http响应报文头部的扩展字段还包括第一加密算法，第一加密算法为加密算法集中服务端支持的任一加密算法。
207.在一些实施例中，当第一http响应报文头部的扩展字段还包括证书请求，证书请求用于请求客户端的证书时，该第二http请求报文头部的扩展字段还包括所述客户端的证书。
208.在一些实施例中，扩展字段包括以下至少一种：握手字段、记录字段、变更密码规范字段、保留字段。
209.示例性的，如图9所示，为本技术实施例提供的一种服务端设备的结构示意图。该客户端设备900包括接收模块901、发送模块902以及密钥生成模块903。
210.在一些实施例中，接收模块901，可以用于接收客户端发送的第一超文本传输协议http请求报文，所述第一http请求报文头部的扩展字段包括所述客户端的第一密钥协商参数。
211.发送模块902，可以用于响应于所述第一http请求报文，向所述客户端发送第一http响应报文，所述第一http响应报文头部的扩展字段包括所述服务端的第二密钥协商参数和所述服务端的证书，所述服务端的证书包括所述服务端的公钥。
212.接收模块901，还可以用于接收所述客户端发送的第二http请求报文，所述第二http请求报文头部扩展字段包括所述客户端的预主密钥。
213.密钥生成模块903，可以用于根据所述第一密钥协商参数、所述第二密钥协商参数和所述预主密钥生成协商密钥，所述协商密钥用于所述客户端与所述服务端进行加密通信。
214.在一些实施例中，接收模块901，还可以用于接收所述客户端发送的http加密报文，所述http加密报文头部的扩展字段包括第一加密策略信息，所述第一加密策略信息用于指示所述加密数据的类型或者所述加密数据的位置。
215.服务端设备900还可以包括解密模块，用于根据第一加密策略信息，解密加密数
据。
216.在一些实施例中，服务端设备900还可以包括加密模块，用于当http加密报文头部的扩展字段还包括第二加密策略信息，第二加密策略信息用于指示服务端对所述目标类型的数据进行加密和/或对目标位置的数据进行加密时，根据第二加密策略信息和协商密钥，对目标类型的数据和/或目标位置的数据进行加密。
217.在一些实施例中，目标类型的数据包括以下至少一项：密钥协商的参数、加密算法集、所述客户端或所述服务端的证书、加密策略信息。
218.在一些实施例中，目标位置的数据包括以下至少一项：位于http加密报文头部的部分数据；或者，位于http加密报文实体部分的部分数据；或者，位于http加密报文实体部分的全部数据。
219.在一些实施例中，http加密报文头部的扩展字段还包括第三加密策略信息，第三加密策略信息用于指示以下至少一项信息：当生成协商密钥后，对服务端和客户端之间每次传输的报文进行加密；或者，当生成协商密钥后，每个n次传输间隔，重新生成新的协商密钥，n为大于1的整数。
220.在一些实施例中，第一密钥协商参数为所述客户端生成的第一随机数，所述第二密钥协商参数为所述服务端生成的第二随机数。
221.在一些实施例中，所述第一http请求报文头部的扩展字段还包括所述客户端支持的加密算法集；密钥生成模块903，还可以用于根据所述加密算法集选择所述服务端支持的第一加密算法。
222.在一些实施例中，第一http响应报文头部的扩展字段还包括证书请求信息，所述证书请求信息用于请求所述客户端的证书。
223.在一些实施例中，服务端设备900还可以包括认证模块，当第二http请求报文还包括所述客户端的证书时，认证模块可以用于根据所述客户端的证书验证所述客户端的身份。
224.在一些实施例中，接收模块901，还可以用于接收所述客户端发送的http加密报文，所述http加密报文包括使用所述协商密钥加密的加密数据。
225.示例性的，如图10所示，为本技术实施例提供的一种客户端设备的硬件结构示意图。该客户端设备1000可以包括至少一个处理器1001、存储器1002和通信接口1003，其中，处理器1001、存储器1002和通信接口1003可以通过通用串行总线(universal serial bus,usb)1004连接，通信接口1003用于和其他设备进行通信，存储器1002包括计算机程序指令，当计算机程序指令在处理器1001中执行时，使得该客户端设备实现如本技术实施例提供的安全通信的方法。
226.示例性的，如图11所示，为本技术实施例提供的一种服务端设备的硬件结构示意图。该服务端设备1100可以包括至少一个处理器1101、存储器1102和通信接口1103，其中，处理器1101、存储器1102和通信接口1103可以通过通用串行总线(universal serial bus,usb)1104连接，通信接口1103用于和其他设备进行通信，存储器1102包括计算机程序指令，当计算机程序指令在处理器1101中执行时，使得该客户端设备实现如本技术实施例提供的安全通信的方法。
227.本技术实施例还提供了一种安全通信的系统，该通信系统包括客户端设备和服务
端设备，所述客户端设备用于执行本技术实施例提供安全通信的方法在客户端上的功能，服务端设备用于执行本技术实施例提供安全通信的方法在服务端上的功能。
228.本技术实施例还提供了一种计算机可读存储介质，计算机可读存储介质存储有计算机可执行程序，所述计算机可执行程序在被计算机调用时，使所述计算机实现本技术实施例提供的安全通信的方法。
229.本技术实施例还提供了一种芯片系统，该芯片系统包括：通信接口，用于输入和/或输出信息；存储器，用于存储计算机可执行程序；处理器，用于执行所述计算机可执行程序，使得安装有所述芯片系统的设备实现本技术实施例提供的安全通信的方法。
230.本技术实施例还提供了一种计算机程序产品，所述计算机程序产品包括计算机程序指令，当所述计算机程序指令在计算机上运行时，使得计算机或处理器执行上述任一方法中的一个或多个步骤，使得本技术实施例提供的安全通信的方法得以实现。
231.在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本技术实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线)或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，dvd)、或者半导体介质(例如，固态硬盘(solid state disk，ssd))等。
232.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，该流程可以由计算机程序来指令相关的硬件完成，该程序可存储于计算机可读取存储介质中，该程序在执行时，可包括如上述各方法实施例的流程。而前述的存储介质包括：rom或随机存储记忆体ram、磁碟或者光盘等各种可存储程序代码的介质。
233.以上所述，仅为本技术实施例的具体实施方式，但本技术实施例的保护范围并不局限于此，任何在本技术实施例揭露的技术范围内的变化或替换，都应涵盖在本技术实施例的保护范围之内。因此，本技术实施例的保护范围应以所述权利要求的保护范围为准。