加密解密SSL/TLS,对称非对称、公钥私钥、签名验签 概念
名词简介
对称加密：使用相同密钥与算法进行加解密运算的算法就叫做对称加密算法！
非对称加密：就是不相同密钥加解密算法。详细参考非对称加密章节介绍
SSL：安全套接层(secure sockets layer)主要是在网络层（TCP）和应用层（http）之间做加密。
TLS:传输层安全(transport layer security)TLS 是 SSL 的继任者，两者可以看做一样的东西。
公钥：非对称加密中公开的密钥，谁都能拿到。
私钥：非对称加密中的私有的唯一持有的密钥。
签名：用私钥加密数据的过程叫签名。
验签：用公钥解密数据的过程叫验证签名。
openssl：目前最流行的 SSL 密码库工具，其提供了一个通用、健壮、功能完备的工具套件，用以支持SSL/TLS 协议的实现。
CA:证书颁发机构（CA, Certificate Authority）即颁发数字证书的机构。是负责发放和管理数字证书的权威机构，并作为电子商务交易中受信任的第三方，承担公钥体系中公钥的合法性检验的责任。
x509：X.509 是密码学里公钥证书的格式标准。上面的CA就是这个标准。
CRT: certificate的缩写，即证书。X.509的证书文件，一般以.crt结尾。
PEM – Privacy Enhanced Mail,打开看文本格式,以”—–BEGIN…”开头, “—–END…”结尾,内容是BASE64编码.
Apache和*NIX服务器偏向于使用这种编码格式.
DER – Distinguished Encoding Rules,打开看是二进制格式,不可读.
Java和Windows服务器偏向于使用这种编码格式
CSR: 是Certificate Signing Request的缩写，即证书签名请求，这不是证书，可以简单理解成公钥，生成证书时要把这个提交给权威的证书颁发机构。
KEY:私钥。
MD5与SHA-1:散列函数也叫做HASH函数，主流的散列算法有MD5与SHA-1。散列函数的主要任务是验证数据的完整性。通过散列函数计算得到的结果叫做散列值，这个散列值也常常被称为数据的指纹（Fingerprint）也叫数字签名。
TLS/SSL通信流程
具体说明：
- Client 能互联网下载CA的公钥，用于验证Server身份
- Server 通过加密算法生成一对密钥，将公钥发给CA认证机构，做数字证书
- CA 通过自己的私钥加密 Server 公钥并加上自己的数字签名后，将生成的数字证书发给Server
- Client 与 Server 通TCP的三次握手建立连接
- Client 发出HTTP的报文请求，并和Server协商使用哪种算法加密
- Server 响应报文并将公钥（CA证书）发送给客户端
- Client 能通过CA的公钥解密CA证书，得到Server的公钥和数字签名，Client 通过散列函数算出Server公钥的数字签名与得到的数字签名对比，来验证Server身份，验证成功并发送数据请求
- Server 处理请求，并根据Client请求的资源类型，来访问相关资源做出响应报文，并记录日志
- Client 与 Server 通过TCP的四次挥手断开连接，通信完成
SSL协议的握手过程
-
客户端通过发送Client Hello报文开始SSL通信。报文中包含客户端支持的SSL的指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
注意：客户端还会附加一个随机数，这里记为A。 -
服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
注意：这里服务器同样会附加一个随机数，发给客户端，这里记为B。 -
之后服务器发送Certificate报文。报文中包含公开密钥证书。（具体的数字签名请看证书一节）
-
最后服务器发送Server Hello Done报文通知客户端，最初阶段的SSL握手协商部分结束。
-
SSL第一次握手结束后，客户端会对服务器发过来的证书进行验证，如果验证成功，解密取出证书中的公钥。（具体查看证书一节）
接着，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文使用从证书中解密获得的公钥进行加密（其实就是服务器的公钥）。 -
客户端继续发送Change Cipher Spec报文。用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
-
客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值（也就是HASH值），用来供服务器校验。
-
服务器接收到客户端的请求之后，使用私钥解密报文，把Pre-master secret取出来。接着，服务器同样发送Change Cipher Spec报文。
-
服务器同样发送Finished报文，用来供客户端校验。
-
服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
-
应用层协议通信，即发送HTTP响应。
-
最后由客户端断开连接。断开连接时，发送close_notify报文。上图做了一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。
问题一
为什么最后客户端和服务端都要发送一个Finish报文？
上面已经提及，Finish报文是对至今全部报文的整体校验值（也就是HASH值）。当客户端把这个值通过得到的公钥进行加密的时候，服务器得到之后对其进行解密，然后再对全部报文进行一个HASH求值。如果这个值跟解密得到的值相等的话，那么说明客户端是可信赖的。
同样的，服务器发送这样的一个整体校验值，用来客户端验证服务器是否是真正要进行通信的那一个。
综上，这个Finish报文就是用来校验双方的身份的。
问题二
整个过程中产生的三个随机数有什么用呢？
还有，后面进行HTTP通信的时候，是用哪一个密钥进行加密，还有怎么保证报文的完整性。
对于客户端：
当其生成了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。
对于服务端：
当其解密获得了Pre-master secret之后，会结合原来的A、B随机数，用DH算法计算出一个master secret，紧接着根据这个master secret推导出hash secret和session secret。
在客户端和服务端的master secret是依据三个随机数推导出来的，它是不会在网络上传输的，只有双方知道，不会有第三者知道。同时，客户端推导出来的session secret和hash secret与服务端也是完全一样的。
那么现在双方如果开始使用对称算法加密来进行通讯，使用哪个作为共享的密钥呢？过程是这样子的：
双方使用对称加密算法进行加密，用hash secret对HTTP报文做一次运算生成一个MAC，附在HTTP报文的后面，然后用session-secret加密所有数据（HTTP+MAC），然后发送。
接收方则先用session-secret解密数据，然后得到HTTP+MAC，再用相同的算法计算出自己的MAC，如果两个MAC相等，证明数据没有被篡改。
MAC(Message Authentication Code)称为报文摘要，能够查知报文是否遭到篡改，从而保护报文的完整性。
问题三
如果黑客拦截了服务器把证书发送给客户端，并对证书进行恶意修改，会出现什么情况？
第一种情况，假如黑客只是单纯的修改数字证书中的内容，那么由于数字签名的存在，客户端会很容易的判断出报文是否被篡改。
第二种情况，黑客不仅修改了数字证书的内容，并且把数字签名替换掉了，由于黑客不可能知道CA的私钥，于是在客户端用CA的公钥进行解密的时候，解密之后得不到正确的信息，也很容易判断出报文是否被修改。
第三种情况，黑客恶意的从相同的第三方CA申请了一个数字证书。由于这个CA是真实存在的，所以客户端是可以用CA的公钥进行解密，得到了黑客提供的数字证书中的公钥。但是，由于数字证书在申请的时候，会绑定一个域名，当客户端比如说浏览器，检测到这个数字证书中的域名和我们现在网页访问的域名不一致，便会发出警告，此时我们也能得知数字证书被替换了。发出的警告如下：
所以：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。所以上面报文中就将服务端CA证书和公共密钥交换消息放在同一个tcp连接进行传输。
问题三
为什么要使用三个随机数呢？
一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机
黑客可能拦截了这样的一个加密的报文，他不对报文进行修改，而是不停的向报文的接受者发送重复的报文，以扰乱通信的建立。
于是，就可以加这么一个随机数。只要任何一个通信方，接收到的报文中的随机数出现重复的情况，就可以知道有中间者对通信的过程进行了扰乱，可以立即中断通信。
TLS 文档：在 IETF 中，协议被称为 RFC。TLS 1.0 是 RFC 2246，TLS 1.1 是 RFC 4346，TLS 1.2 是 RFC 5246。
现在，TLS 1.3 为 RFC 8446。从 TLS 1.2 到 TLS 1.3