关于HTTPS通信和证书验证的流程

https的流程见文章：https://zhuanlan.zhihu.com/p/24854237

梳理一遍：

1.客户端发起请求；

2.服务器端返回确认并发起请求；

3.客户端发出ssl通信相关内容，包括ssl版本、可用算法列表、密匙长度等；

4.服务器端返回相同的ssl请求；

5.服务器端发送服务器的证书给客户端；

6.服务器端告诉客户端，关于服务器端的SSL相关信息和证书信息已经发送完毕了；

7.客户端接到证书后要去验证证书的真伪（题外话1：关于证书真伪的验证），确定为真后，使用该证书包含的客户端公钥，对一个随机产生的密钥进行加密（题外话2：另一个密钥的存在必要），发送给服务器端；

8.客户端告诉服务器端，关于加密协商的内容我已经全部发送完毕了，等你确认了之后我就要发送经过加密的正文内容了；

9.服务器端接收到用户端经过加密的新密钥，解密后得到这个新密钥，并发送给客户端消息说明，我已经接收到新密钥了，接下来的内容就是经过加密的正文内容了；

10.开始数据传递；

题外话1：关于证书真伪的验证

证书上面有一个数字签名，可用于验证证书的真伪，这个数字签名同样是利用公开密钥方法加密的，证书办法机构会用自己的私钥对其加密，客户端则用给定的公钥对齐进行解密，解密后得到的内容就拿去验证证书是不是真的；在这个过程中，对证书进行解密的公钥如何传递给客户端是一个问题，因为一旦在网络传输中，公钥被攻击者掉包的话，证书也就有了伪造的可能，所以目前的做法是，在浏览器生产的时候就会内置一些常用的认证机构的公钥。（注意，验证证书真伪用的这组公钥私钥是证书办法机构的，和服务器端用来机密的公钥私钥不是同一对，就是在SSL中，因为证书的使用，会有两对密钥）；

题外话2：另一个密钥存在的必要

在通信中明明已经有一对用来对通信加密用的密钥了，为什么还需要一个多的密钥？因为对通行加密的密钥是公共密钥，只能保证一个方向的信息传递安全，即一个公钥一个私钥，私钥加密的报文可以用公钥解密，公钥加密的报文可以用私钥解密，现在服务器端持有私钥，客户端持有公钥，客户端在给服务器端发送消息的时候用公钥加密，服务器端用私钥解密，即使被截住也没关系，因为攻击者没有私钥没办法对报文进行解密，那么现在反过来服务器端给客户端发送消息的时候，会使用私钥加密，客户端用公钥解密，问题出现了，公钥是公开的，所有人都知道，一旦报文被攻击者截住，则攻击者可以用公钥对信息解密。所以既然客户端给服务器端发送消息是安全的，那就干脆让客户端发送一个用于对称加密的密钥给服务器端，服务器端在用自己的私钥进行加密的同时再用对称加密密钥进行一次加密，即上了双保险，等报文传递回客户端的时候，客户端可以用服务器给的公钥和自己生成的对等加密密钥对报文解密，保证了双向通信都是安全的。