参考：SSL/TLS协议运行机制的概述 - 阮一峰的网络日志
参考：密码学基础--加解密、摘要算法 - chuicao4350的博客 - CSDN博客
参考：SSL协议握手过程报文解析 - tterminator的专栏 - CSDN博客
参考：SSL/TLS 双向认证(一) -- SSL/TLS工作原理 - 乐呵乐呵 - CSDN博客
参考：TLS/SSL 协议详解 (25) https双向认证及常见问题总结 - Protocol/Linux Kernel/ Optimization - CSDN博客
参考：数字证书
参考（推荐阅读）：SSL/TLS协议详解(上)：密码套件，哈希，加密，密钥交换算法 - 先知社区
参考（推荐阅读）：SSL/TLS协议详解(中)——证书颁发机构 - 先知社区
参考（推荐阅读）：SSL/TLS协议详解(下)——TLS握手协议 - 先知社区
前言
SSL/TLS解决的其实是明文传输的几个安全风险：
1）窃听风险
2）篡改风险
3）冒充风险
相应的，SSL/TLS是采用这么几个方式进行应对的：
1）加密：非对称加密+对称加密，主要解决的是窃听风险
2）校验：数字签名，主要解决的是篡改风险
3）证书：数字证书，主要解决的是冒充风险
非对称加密与对称加密
SSL/TLS的通信流程其实是一个非对称加密向对称加密过渡的过程，而之所以流向对称加密，原因就是对称加解密的速度要好很多。所以非对称加密的过程可以理解为交换证书和协商对称加密秘钥的一个过程。
非对称加密中有公钥和私钥的概念，公钥与私钥是一对，如果用公钥对数据进行加密，只有用对应的私钥才能解密（数据加密解密）；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密（数据签名和认证）。（这点很重要，此前一致理解为公钥就是用来加密、私钥就是用来解的，所以设计到数字签名的部分就混乱了）
私钥用来：解密 + 签名（加密）
公钥用来：加密 + 验证签名（解密）
数字证书与数字签名
数字证书是一个经证书授权中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。数字证书在SSL/TLS传输过程中扮演身份认证和密钥分发的功能。
而数字签名呢，如前所述主要是为了解决证书被篡改的风险。方式是对证书原文进行HASH计算得到一个报文摘要，然后使用私钥进行加密，被连同数字证书一块发送给对方。至于为什么多了一个生成报文摘要的环节，是因为对原文进行加密往往比较耗时，通过对于摘要的加密仍然可以达到相同的作用。刚刚又得知一个更重要的原因，比如RSA加密要求数据长度不能超过密钥长度，比如RSA2048（位）对应255字节，证书中可能包含很多信息，所以在加密之前需要进行一下HASH散列。
数字证书的格式主要有pfx和cer两种，
pfx是一种同时包含公钥和私钥的二进制证书格式
cer则只包含公钥，其中又细分为DER编码的二进制格式和BASE64编码的文本格式
数字证书与签名、公钥与私钥、对称密钥等这些元素都具备了，接下来就是如何通过SSL/TLS进行通信传输了。下面以几个实际例子来了解一下SSL/TLS通信流程。
一.单向认证（Diffie Hellman密钥交换算法）
以浏览器访问https://www.baidu.com为例，
由于百度优先采用TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256加密套件，其中的Diffie Hellman加密算法需要服务器和客户端双方分别生成一对DH公钥/私钥，双方交换过DH公钥后，Pre-Master Secert也就可以计算完成了。
其中的加密套件格式为：
不要对Server Key Exchange中的服务器DH公钥感到奇怪，因为当使用Elliptic Curve Diffie-Hellman（ECDHE）时，该公钥不在服务器的证书中。因此，服务器必须在单独的消息中向客户端发送其DH公钥，以便客户端可以计算预主密钥。Server Key Exchange也仅在服务器提供的证书不足以允许客户端交换预主密钥时，才会发送此消息。
二.单向认证（RSA密钥交换算法）
真正用于进行对称加密通信的密钥（Session Key）实际是由服务器端随机数（Server Random）+ 客户端随机数（Client Random）+ Pre-Master Secret共同计算得出的。
而其中的Pre-Master Secret，对于RSA密钥交换协议来说是由Client端生成，即：客户端通过连接协议版本（2个字节）和客户端随机生成的一些字节（46个字节）来生成48字节的预主密钥。
而对于DH密钥交换协议来说是由共享的服务器端DH公钥和客户端DH公钥共同生成。
三.双向认证
服务器端多了一个Certificate Request的过程，以及客户端多了一个发送证书的Certificate的过程。
