https中SSL加密过程详解，看这一篇就够了！

我们所说的https实际上就是安全版本的http，是http+ssl加密实现的。

SSL握手协议
1.客户端:发起一个 HTTPS 请求，请给我公钥
2.服务器:这是我的证书，里面有加密后的公钥
3.客户端:解密成功以后给服务器用公钥非对称加密后的随机数
4.服务器:服务器返回确认收到随机数，以后就用它对称加密数据

知识点1
https使用的是对称加密和非对称加密的结合方式
我们的证书验证部分采用的是非对称加密，信息传输部分采用的是对称加密

建立之后是内容的双向传递

需要安全，我们就需要加密
1对称加密，用一把钥匙加密，同一把钥匙开锁
缺点：非常的不安全，如果被窃取到了钥匙和密文的话，就可以获取数据（不安全）
那怎么办？使用非对称加密方式
2非对称加密的方式:有公钥和私钥两把钥匙，把公钥给对方，并且对方使用公钥进行加密，并把加密的密文传输过来。（公钥加密，只有私钥能解密（自己不行），反之一样）。所以解决了对称加密不安全的问题。(即使你得到了密文和加密使用的公钥，你也无法解开密文)
缺点1：怕别人冒充，如果有人把公钥拦截，发送自己的公钥给对方，然后对方使用自己的公钥加密，并拦截加密后的密文就可以获取数据了。（冒充）
缺点2:我当然也可以进行破坏，篡改加密之后的密文，我的不到的你也别想得到，我就是想搞一搞破坏。(篡改，破坏）。
缺点3：非对称加密效率太低，太慢了
那么，我们怎么解决效率低和保证发送公钥的人的身份就是正确的人,保证传输数据的完整性，未被破坏呢？
（CA认证机构颁发证书，数字签名，数组证书）
3 CA数字证书（CA认证机构颁发证书）
所以我们引入了公正的第三方权威机构
这个CA机构会给服务端发一个数字证书，这个证书包括服务端的一些信息和服务端的公钥
那我们首先服务端会发送自己数组证书给客户端（这也是一个发送公钥的过程），
我通过数字证书的类别（是哪一家机构颁布的），找到机构的中心的公钥。解码数字证书，解码正确，表示是证书是真的，再确认证书上的信息，正确的话就获取服务端的公钥（公钥的传递，公钥是在数字证书里面的）
后面，我们使用公钥对数字签名进行解密，确认完整性
4数字签名
为了解决，确认密文没有被修改过。我们使用了数字签名。
数字签名：是我们对需要传输的内容进行编码操作，变成hash值。并且对hash值进行私钥的加密。（这一个经过hash和加密的操作是我们所说的数字签名）
最后我们把没有操作的原文和经过一系列操作的数字签名一起发给服务端。那么我们对原文进行进行hash操作和公钥解析数字签名的进行对比，确认是对的人发送的，并且内容没有经过篡改和破坏。
缺点：我没有办法保证公钥传递的安全，不能保证发送公钥的人是对的，而不是别人伪造的

因为我们经过了一系列的证书验证，确定了发送数字证书的人的身份是正确的，那我们最后的数据传输使用一个随机数，对随机数的公钥加密，私钥解密，制定最后传递数据所采用的对称加密方式序列，传递最后的数据

问题1：那么我们的随机数被截取了怎么办？

我觉得下面的答案不对，如果我随机数被篡改，不是就可以轻而易举的获得后面对称加密的数据嘛？？？

其实 HTTPS 并不包含对随机数的安全保证，HTTPS 保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

问题2：如果我冒充证书怎么办？（每个人都可以制作证书）
虽然我拿到了证书，但是证书是通过CA机构私钥进行加密的，就算拿到了也没办法拿到CA的私钥，对其信息进行加密冒充正规的服务端。

问题3：我对证书进行解密，拿到了公钥，拿着公钥对随机数进行加密。获得最后堆成加密交换的数据怎么办？

问题4：证书机构的公钥在哪里获得？
计算机的操作系统里或者浏览器里会内置一些常用的公钥。操作系统只会存储权威机构的公钥

问题5：SSL过程这么复杂，会很慢吗？
SSL 握手的时间并不是只能用来传递加密信息，还可以承担起客户端和服务器沟通 HTTP2 兼容情况的任务。因此从 HTTPS 切换到 HTTP2.0 不会有任何性能上的开销，反倒是得益于 HTTP2.0 的多路复用等技术，后续可以节约大量时间。
如果把 HTTPS2.0 当做目标，那么 HTTPS 的性能损耗就更小了，远远比不上它带来的安全性提升。

参考链接：

Check SSL Certificate Chain Order with Openssl - SSLHOW