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

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

 前面我们和大家一起聊了一下加密套件，为什么这么详细的叙述加密套件呢，因为它的身份特殊啊，它可是连接通信双方的桥梁，也是月老手中的红绳。

 言归正传，接下来我们再继续看看国密vpn协议中列举的基于国密算法加密套件（见下图）。每个加密套件也包含一个秘钥交换算法，一个加密算法，和一个校验算法。(大家不要奇怪怎么和之前介绍的4部分不一样啊，因为秘钥交换时使用的签名算法是一样的，如果这么表示RSA_RSA _.. ，这样看起来是不是很奇怪)。而在我们的实际应用中现在在国密的SSL通信中主要使用的还是ECC_SM4_SM3（这里的ECC其实就是指SM2）。现在支持国密通信的浏览器主要也是支持这个加密套件，至于为什么不选择其他的加密套件，这是由于算法的一些特性和实际应用的场景决定的，这里先不展开，以后有机会再和大家分享。

 

 

 

 

 

好了，关于国密加密套件这部分，介绍的差不多了，接下我们继续看看客户端和服务端双方是怎样基于加密套件握手的。

 

五.关于握手   

我们讲到加密套件是整个通信的基石，而秘钥交换算法就是加密套件最核心的部分。秘钥交换算法在SSL/TLS通信中使用最广泛的主要有两种类型：一种是基于RSA算法的秘钥交换（如TLS_RSA_WITH_AES_256_CBC_SHA256），另一种是基于DH算法 （W.Diffie和M.Hellman）的秘钥交换（如前文中提到的TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384）。而实际应用中现在根据RSA算法进行的密钥交换慢慢的被DH算法逐渐取代了，至于为什么，我这里先卖个关子，后面会讲到。

我们先结合之前分析的SSL通信流程看看RSA算法的密钥协商的过程。

基于RSA算法的秘钥交换，其本质是依据--公钥加密的数据只有其私钥才能解密。 所以在服务端接收到了客户端的请求后选择自己支持的加密套件，并将自己的证书（证书中包括公钥，通常很多人认为证书就是公钥，其实证书和公钥的关系是-- 证书不仅仅包含公钥）发送给客户端。客户端就可以拿接收到的公钥发送加密信息给自己。这样，第三方即使中途截获了客户端给服务端发送的数据，但由于没有服务端的证书的私钥，所以无法进行破译。

我们前面说了秘钥交换的目的是为了协商出一个只有客户端和服务端知道的主秘钥（master secret）。为了双方能够顺利达成共识，客户端自己会通过随机数产生出一个预主秘钥（premaster secret）发送给服务端。这个预主秘钥就是用来计算主秘钥的（至于计算主秘钥的方法这里就不深入了，需要结合预主密钥、客户端/服务端给各自给对方发送的随机数、以及一些字符串常量等。掉头发的事，还是放心的交给程序员小哥哥吧）。上面说的这个流程就是之前上图表2中流程图的第7项 （ClientKeyExchange）。

整个过程看起来是不是没什么毛病，为什么说不安全呢？原因就是服务端证书的私钥参与了握手。如果有一天服务端私钥过期后遭到泄漏了（或者RSA算法被破译了），攻击者就可以使用保存的历史数据，进行破译。所以基于RSA算法的密钥协商不具有向前安全性（Forward Securety） ！这个有点像我们生活中所说的“君子报仇十年不晚”。只要你的数据有足够的价值，那些蓄谋已久的“君子”也会有足够的耐心。

接着再来看基于DH算法的秘钥交换算法，为了方便大家的理解我们模拟一个场景，就拿牛郎和织女来说吧。

目的很简单--牛郎和织女要协商一个只有他们两人知道的密码。 先取一个全世界都知道的数P，这里假设P= 10。牛郎随机产生一个数52（做为自己的私钥）， 然后计算：52  * 10 = 520 （DH参数），再将520发送给织女。

同样，织女也随机产生一个数25（做为自己的私钥），然后计算：25 * 10 = 250（DH参数），再将250发送给牛郎。

双方各自接收到了对方的数据后，赶紧和自己的私钥进行另一个计算

牛郎计算：250 * 52  = 13000 （共同秘钥）

织女计算：520 * 25 = 13000  （共同秘钥）

 

这样牛郎和织女就完成了的秘钥交换，此时对外知道的是数字只有  10， 250， 520，但是他们无法计算出13000。除非他们把自己的私钥泄漏给了第三者，否则别人呢是无法知道他们的共享秘钥的。

这个简单的场景模拟是为了方便大家的理解，真正的DH算计还要复杂得多。这里的私钥和P值都太简单了，如果P是在椭圆曲线上取一个点（px，py）呢，随机数也复杂化0XABCDEF012367890ABCDEFG，那要想破译就很难了。看着一长串和X,Y,Z是不是就头大，没关系！还是那句话，掉头发的事就放心的交给程序员吧。

有了这个模型的铺垫，我们再来介绍基于DH算法的原理产生的秘钥协商算法 。

实际应用主要有DHE算法和ECDHE算法，EC其实就是代表了椭圆曲线，其实还有一个ECDH算法，这个比ECDHE少了一个E，这个E就是（Ehermeral）的简写。这个算法与ECDHE流程逻辑是一样的，但其中使用的（Server DH 参数）时是服务端证书中的DH参数，所以使用ECDH这个密钥协商算法的服务端必须是ECC证书。由于这个算法也使用到了证书中的信息，现在也逐渐停止使用了。

绕了一大圈现在再看到那些什么ECDHE/ECC/DHE/是不是一点都不慌了。我都知道了你是干什么的，还怕不知道你叫什么吗？

我们回顾一下整个DH算法的流程来总结一下，这个算法相比RSA有什么好处：

最大的好处就是DHE和ECDHE这两种类型的密钥交换过程中 服务端证书的私钥不参与其中，秘钥协商的时候双方的私钥都是临时产生的。所以具有向前安全（forward secrity）的属性。

接下来，我们再来看看国密的SSL秘钥交换和TLS协议中的秘钥交换又有什么区别。这里我们主要基于ECC_SM4_SM3套件来说明。ECC_SM4_SM3加密套件的秘钥交换类似于RSA算法的秘钥换行过程，但多了过程4 （ServerKeyExchange），目的就是为了证明对自己签名证书的也是具有所有权的。而且客户端发送加密数据的时候，是将接收到服务端的加密证书对数据数据加密,此过程对于之前流程中的7（ClientKeyExchange），这些就是流程中最主要的差别，当然签名算法(国密使用SM2)，hash（国密使用SM3）也是不一样的，得到对称秘钥后，使用对称秘钥(国密使用SM4)的算法也是不一样的。

好了，到此为止。基本把ssl/tls通信和国密ssl通信的主要内容都讲解完了。当然这些协议还有很多其他的细节和玄机，有需要的朋友可以深入去了解。

 六、总结

我们前面从协议的流程，到加密套件，再到秘钥协商， 然后又分析了相关的算法应用过程，基本上主要的点都涉及到了，国密HTTPS基本上也就这些事。其实枯燥的协议中也充满了人文思想，怎么架构才能达到目的，如何设计能才最有效率？如果说蒙娜丽莎的微笑代表了画家对艺术造诣的追求，那么协议就是工程师们手中的艺术品，每个数据，每个结构，每个过程都充满了智慧和严谨，而这个艺术品需要一代又一代的人去迭代和更新，且永无止境！

国密的研究与推进更需要我们中国人自己不断的前赴后继。任重道远，与君共勉！