一张图讲清楚对称性/非对称性加密、安全证书内涵以及应用场景（续）

　　在《一张图讲清楚对称性/非对称性加密、安全证书内涵以及应用场景》这篇文章中，我们提出要记住一个很重要的问题。还记得那个问题吧？在SSL的交互流程中，客户端是如何获得服务器的公钥信息的呢？不考虑企业内部线下同步等这些方法，在互联网大环境下，我们很容易想到两种方法：

1）服务器建一个网站，让客户端来下载使用；

2）服务器和客户端在每次通信之前，由服务器将公钥信息送给客户端；

上述第一种方法，客户端无法确信这个网站的真实性；

上述第二种方法，无法阻止黑客攻击。考虑如下的业务流程：

Round 5：

1）“客户端”->“黑客”：Hello,我是客户端

2）“黑客”->“客户端”：Hello，我是服务器，这是我的公钥

3）“客户端”->“黑客”：真的吗？证明给我看

4）“黑客”->“客户端”：我就是服务器{我就是服务器}[黑客私钥|RSA]

5）“客户端”->“黑客”：{我证实了你的身份，这是后面我们传递消息使用的对称性加密密钥和加密算法}[公钥|RSA]

6）“黑客”->“客户端”：{哥们，我收到你的加密密钥和算法了 }[对称性加密密钥|加密算法]

7）“客户端”->“黑客”：{我是张三，我的银行密码是123，告诉我余额}[对称性加密密钥|加密算法]

8）“黑客”->“客户端”：{嘿嘿，你上当了}[对称性加密密钥|加密算法]

上述悲剧性流程的根源是客户端无法正确的判断，声称自己是服务器的那个家伙，其公钥的合法性究竟如何？

天将降大任于斯人，“数字证书”千呼万唤终于要出场了。一个证书包含下面的具体内容：

·  证书的发布机构

·  证书的有效期

·  公钥

·  证书所有者（Subject）

·  签名所使用的算法

·  指纹以及指纹算法

    数字证书的详细细节这里不做讨论，这里先只需要搞清楚一点，数字证书可以保证数字证书里的公钥确实是这个证书的所有者(Subject)的，或者证书可以用来确认对方的身份。也就是说，我们拿到一个数字证书，我们可以判断出这个数字证书到底是谁的。

使用数字证书之后的通信流程描述如下：

Round 6：

1）“客户端”->“服务器”：Hello,我是客户端

2）“服务器”->“客户端”：Hello，我是服务器，这是我的数字证书//此处使用证书代替了之前使用的公钥信息。

    注释：“客户端”对“服务器”的证书进行验证，确认证书的合法身份；（使用数字签名验证证书的不可抵赖性和证书完整性）

3）“客户端”->“服务器”：你的证书是可靠的，现在证明给我看你是这个证书的合法拥有者，这是一串用你的公钥加密之后的随机数，你用私钥解密之后传送回来。

4）“服务器”->“客户端”：一串随机数{一串随机数}[私钥|RSA]

   注释：“客户端”对使用公钥解密{一串随机数}[私钥|RSA]，然后跟一串随机数对比，如果一致，证明“服务器”的合法身份；

5）“客户端”->“服务器”：{通过你的身份验证，这是后面我们传递消息使用的对称性加密密钥和加密算法}[公钥|RSA]

6）“服务器”->“客户端”：{哥们，我收到你的加密密钥和算法了 }[对称性加密密钥|加密算法]

7）“客户端”->“服务器”：{把用户张三的银行账户余额告诉我}[对称性加密密钥|加密算法]

8）“服务器”->“客户端”：{张三的银行账户余额是一亿元}[对称性加密密钥|加密算法]

上述步骤基本就是HTTPS的真实通信过程了。结合本文章最开始的那张图片，我们可以复习一下教科书中的SSL协议交互流程，描述如下：

 

(1)     SSL客户端通过Client Hello消息将它支持的SSL版本、加密算法、密钥交换算法、MAC算法等信息发送给SSL服务器。

“客户端”->“服务器”：Hello,我是客户端

(2)     SSL服务器确定本次通信采用的SSL版本和加密套件，并通过Server Hello消息通知给SSL客户端。如果SSL服务器允许SSL客户端在以后的通信中重用本次会话，则SSL服务器会为本次会话分配会话ID，并通过Server Hello消息发送给SSL客户端。

“服务器”->“客户端”：Hello，我是服务器

(3)     SSL服务器将携带自己公钥信息的数字证书通过Certificate消息发送给SSL客户端。

“服务器”->“客户端”：这是我的数字证书

(4)     SSL服务器发送Server Hello Done消息，通知SSL客户端版本和加密套件协商结束，开始进行密钥交换。

(5)     SSL客户端验证SSL服务器的证书合法后，利用证书中的公钥加密SSL客户端随机生成的premaster secret，并通过Client Key Exchange消息发送给SSL服务器。

“客户端”->“服务器”：你的证书是可靠的，现在证明给我看你是这个证书的合法拥有者，这是一串用你的公钥加密之后的随机数，你用私钥解密之后传送回来。

(6)     SSL客户端发送Change Cipher Spec消息，通知SSL服务器后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。

“客户端”->“服务器”：{这是后面我们传递消息使用的对称性加密密钥和加密算法}[公钥|RSA]

(7)     SSL客户端计算已交互的握手消息（除Change Cipher Spec消息外所有已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL服务器。SSL服务器利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。

(8)     同样地，SSL服务器发送Change Cipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。

“服务器”->“客户端”：{哥们，我收到你的加密密钥和算法了 }[对称性加密密钥|加密算法]

(9)     SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL客户端对SSL服务器的身份验证。

现在，我们用最后的总结结束这篇文章：

1）在通信过程中，信息的安全传输是通过对称性加密来实现的；

2）非对称性加密的目的是让客户端使用公钥来验证拥有私钥的服务器的真实身份

3）数字证书能够让客户端验证服务器是否是所声称的证书的合法拥有者，非对称性加密的公钥都存放在证书拥有者发布的数字证书中。

4）数字签名可以保证数字证书在传输过程中不被篡改，所以数字证书中都有数字证书签发机构的数字签名