对称性加密和非对称性加密，其应用场景如何？
为什么在非对称性加密中，要使用数字证书来承载密钥信息？
数字签名和数字证书的关系是什么？
本人不是安全专业出身，对上述问题，虽然皆能回答，但是一直未能全面细致了解，近期因为某些缘故，找时间仔细分析了SSL协议传输过程，才得以窥其全貌于一斑。
下面以SSL协议的握手过程这张图，试图讲解在SSL协议中使用数字证书的缘由，数字签名的应用，以及对称性和非对称性加密的使用场景问题。
握手过程（只验证服务器）
上图是标准的SSL握手过程，在详细了解其流程含义之前，让我们先学习解牛的庖丁先生，分析一些关于安全的故事。
来看一个例子，假设“服务器”和“客户端”是网络的两个通信端点，并且他们打算使用RSA这种公钥密码体制，“服务器”需要对外发布公钥，而自己留着私钥。我们稍后再讨论客户如何获得公钥（记住这个问题哦），下面看一下双方如何进行保密的通信：
Round 1：
1）“客户端”->“服务器”：Hello,我是客户端
2）“服务器”->“客户端”：Hello，我是服务器
3）“客户端”->“服务器”：真的吗？
很明显在上述的消息交互过程中，“客户端”无法肯定这个消息就是由“服务器”发出的，因为“黑客”也可以冒充“服务器”发出这个消息。
有聪明人想出来好办法，采用非对称性加密方法，给“服务端”分配一个私钥，给“客户端”分配一个公钥，只要“服务端”用私钥加密传输信息，“客户端”就可以用公钥解密传输信息，流程如下：
Round 2：
1）“客户端”->“服务器”：Hello,我是客户端
2）“服务器”->“客户端”：Hello，我是服务器
3）“客户端”->“服务器”：真的吗？证明给我看
4）“服务器”->“客户端”：我就是服务器{我就是服务器}[私钥|RSA]
上述流程第四步，{我就是服务器}[私钥|RSA]的意思是服务端使用自己的私钥，对“我就是服务器”这部分内容进行RSA加密之后的内容；
由于黑客无法得知“服务器”的私钥信息，所以“客户端”收到服务端发送的“我就是服务器{我就是服务器}[私钥|RSA]”信息后，使用自己持有的公钥对“{我就是服务器}[私钥|RSA]”部分的内容进行解密，然后跟明文信息“我就是服务器”进行对比，如果解密出来的内容是能够对得上的，那说明信息一定是从“服务器”发过来的。
看上去万事大吉哦，元芳，你怎么看？
考虑下面的业务流程：
Round 3：
1）“客户端”->“服务器”：Hello,我是客户端
2）“服务器”->“客户端”：Hello，我是服务器
3）“客户端”->“服务器”：真的吗？证明给我看
4）“服务器”->“客户端”：我就是服务器{我就是服务器}[私钥|RSA]
5）“客户端”->“服务器”：{这是张三的用户名和密码，请把他的银行账户余额告诉我}[公钥|RSA]
6）“服务器”->“客户端”：{张三的银行账户余额是一亿元}[私钥|RSA]
看出问题了吗？当服务端使用自己的私钥将张三的银行余额返回到客户端的时候，客户端可以使用公钥对加密的信息进行解密查阅，然后很悲剧的是：公钥是向所有人公开的，这意味着李四可以悄悄截取并查看张三的银行账户余额。
所以我们可以得出结论：非对称性加密不能解决信息的安全传输问题。事实上正是如此，SSL协议中信息的安全传输，是通过对称性加密来实现的，流程如下：
Round 4：
1）“客户端”->“服务器”：Hello,我是客户端
2）“服务器”->“客户端”：Hello，我是服务器
3）“客户端”->“服务器”：真的吗？证明给我看
4）“服务器”->“客户端”：我就是服务器{我就是服务器}[私钥|RSA]
5）“客户端”->“服务器”：{我证实了你的身份，这是后面我们传递消息使用的对称性加密密钥和加密算法}[公钥|RSA]
6）“服务器”->“客户端”：{哥们，我收到你的加密密钥和算法了}[对称性加密密钥|加密算法]
7）“客户端”->“服务器”：{这是张三的用户名和密码，请把他的银行账户余额告诉我}[对称性加密密钥|加密算法]
8）“服务器”->“客户端”：{张三的银行账户余额是一亿元}[对称性加密密钥|加密算法]
上述解决问题的思路是：当客户端认证了服务器的身份之后，它来选择一个对称性加密密钥和加密算法，然后将这些信息使用服务器的公钥加密并送回服务器，服务器使用自己的私钥解密之后即可获得客户端选择的对称性加密密钥和加密算法。并在后续的通信过程中，双方采用这个密钥和算法进行消息的加密与解密。
听说每一页泡泡糖都应该有一个鲜明的观点，现在我们也应该来总结一下目前为止我们的一些观点：
1）在通信过程中，信息的安全传输是通过对称性加密来实现的；
2）非对称性加密的目的是让客户端使用公钥来验证拥有私钥的服务器的真实身份
在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版本和加密套件，并通过ServerHello消息通知给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，并通过ClientKey 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服务器发送ChangeCipher Spec消息，通知SSL客户端后续报文将采用协商好的密钥和加密套件进行加密和MAC计算。
“服务器”->“客户端”：{哥们，我收到你的加密密钥和算法了 }[对称性加密密钥|加密算法]
(9) SSL服务器计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并添加MAC值、加密等），并通过Finished消息发送给SSL客户端。SSL客户端利用同样的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比较，如果二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。SSL客户端接收到SSL服务器发送的Finished消息后，如果解密成功，则可以判断SSL服务器是数字证书的拥有者，即SSL服务器身份验证成功，因为只有拥有私钥的SSL服务器才能从Client Key Exchange消息中解密得到premastersecret，从而间接地实现了SSL客户端对SSL服务器的身份验证。
现在，我们用最后的总结结束这篇文章：
1）在通信过程中，信息的安全传输是通过对称性加密来实现的；
2）非对称性加密的目的是让客户端使用公钥来验证拥有私钥的服务器的真实身份
3）数字证书能够让客户端验证服务器是否是所声称的证书的合法拥有者，非对称性加密的公钥都存放在证书拥有者发布的数字证书中。
4）数字签名可以保证数字证书在传输过程中不被篡改，所以数字证书中都有数字证书签发机构的数字签名
