关于国密HTTPS 的那些事（二）

关于国密HTTPS 的那些事（二）

三. 需要解决的问题

前文我们了解了https，并梳理了国密https的流程。那么完成这些流程的目的是什么呢？又是怎么来保护数据的安全性呢？我们继续...

上文我们说到只有http通信的站点如同在“裸奔”，在客户端和服务端通信的时候有巨大的安全隐患。而安全隐患主要有三个方面：明文传输，数据篡改，站点劫持。

知道了问题，我们只需要对症下药：

明文传输 ->数据加密传输。

数据可篡改->数据完整性校验。

站点劫持->验证站点的身份。

还不够清楚，我们再深入一点，将上面的箭头继续往下衍生：

明文传输 ->数据加密传输- >需要一个只有客户端和服务端知道的对称秘钥（因为对称秘钥比非对称秘钥效率高）-->秘钥协商。

数据可篡改->数据完整性校验->对数据进行哈希计算并签名-->客户端和服务端采用同一种数据检验的算法。

站点劫持->验证站点的身份->客户端验证服务端提供的证书是否可信->证书由可信的CA机构颁发（如沃通CA等）。

差不多了，SSL/TLS协议的目的慢慢的就凸显出来了。知道了SSL/TLS的目的，我们再回过头看协议，理解起来就相对容易的多。

之前我们也说到了SSL/TLS协议都分为记录协议和握手协议，而他们目的就是服务客户端和服务端双方来来回回的进行数据通信。

先介绍他们的主要功能，如下：

记录层协议：将要发送的消息，把数据分块，压缩（可选），计算校验码HMAC，加密然后传输。接收到的数据经过解密、验证、解压缩重新封装然后传送给高层应用。

握手协议：主要用于客户端和服务端双方协商出供记录层使用的安全参数，进行身份验证以及向对方报告错误等。

接着我们来看SSL/TLS是如何达到自己的目的的，再此之前我们首先需要介绍另一个概念-- 加密套件 。

四.关于加密套件

如果将客户端和服务端比喻成“牛郎”和“织女”，那么加密套件就如同连接双方的“鹊桥”。

加密套件为什么如此重要呢？因为加密套件就定义了他们如何协商对称秘钥，采用哪种算法对数据进行校验以及签名，加密套件是双方建立连接的基础。

就是因为有了它，“牛郎”和“织女”才能顺顺利利的在七夕相遇。

我们看加密套件由那几部分组成，看下图。

除了协议部分，主要是由：秘钥交换和认证算法，加密算法 和摘要算法这四部分组成。

加密套件是协议里面约定的。每个加密套件都有一个ID号。比如0XC02C就是代表了上面的加密套件。

只有客户端和服务端有同样的加密套件（有交集），才能通过握手建立https通道。如客户端支持这个加密套件，服务端也支持这个加密套件，那么双方就可以选择双方都支持的这个加密套件进行握手。按加密套件中约定的算法进行数据加密，签名和交换。

我们在使用抓包工具的时候，就能看到在候客户端在Client_Hello里就携带了自己能支持的加密套件，为什么发送这么多呢？因为客户端也不知道服务端支持哪些加密套件，所以客户端先把自己支持的加密套件发送给服务端，让服务端根据自身的协议进行选择。在实际的应用中，如果客户端支持的加密套件很多，那么客户端会逐步的把所有支持的加密套件都发送给服务端，供服务端选择。此时客户端的独白是：“我已经尽力了，成不成就看缘分了”。服务端接收到客户端的加密套件后，如果正好有自己支持的加密套件--恭喜，配对成功（当然服务端也是有选择权的可以配置选择的优先级，当有遇到多个支持的加密套件时候优先选择一些安全性更高的加密套件）。如果客户端发送的加密套件服务端都不支持，那只能回复客户端，期待下一次的缘分了。所以，作为服务端，在保证安全的情况下，尽量支持多的套件和协议，这样才有更好的兼容性。

现在我们看到抓包工具中的一长串的加密套件，就不奇怪了。原来他们都是期待在茫茫人海中，被“选中”的一个，见下图。

好了，今天就聊这么多。下文我们接着揭露协议中握手双方的来来回回的背后，到底还隐藏了哪些不为人知的秘密！