HTTPS建立连接过程
- 为什么需要HTTPS
为了安全，HTTP虽然效率更快，但是他是明文传输的，这就意味着可能会泄露信息，或者被中间人攻击。HTTPS能够保证安全传输的原因是数据经过对称密钥的加密，再传输。 - 私钥，公钥，密钥，对称密钥，非对称密钥
- 对称加密：使用私钥加密
其加密过程如下：明文 + 加密算法 + 私钥 => 密文
解密过程如下： 密文 + 解密算法 + 私钥 => 明文
优点：加密效率高
缺点：私钥容易泄露 - 非对称加密：使用私钥+公钥加密
被公钥加密过的密文只能被私钥解密，过程如下：
明文 + 加密算法 + 公钥 => 密文， 密文 + 解密算法 + 私钥 => 明文
被私钥加密过的密文只能被公钥解密，过程如下：
明文 + 加密算法 + 私钥 => 密文， 密文 + 解密算法 + 公钥 => 明文
缺点：非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
优点：使用一套密钥，可以存储在两端，这样就不易泄露。 - 私钥：对称加密中用到的密钥叫做私钥，私钥表示个人私有的密钥，即该密钥不能被泄露。
- 公钥：非对称加密也叫做公钥加密。
- 数字证书的作用
第三方认证的作用 -
加密过程
为了兼顾安全和效率，HTTPS使用了对称加密和非对称加密两种加密方式。使用客户端的密钥进行对称加密。服务端保存的一对非对称密钥可以对对称加密的密钥进行加密。
image.png
- 客户端发起HTTPS请求
- 服务端将数字证书和公钥发送给客户端
- 客户端验证数字证书是否合法，然后使用公钥将自己生产的随机密钥进行加密
- 客户端将加密后的密钥发送给服务端
- 服务端使用自己的私钥将加密后的密钥进行解密，得到对称加密算法的密钥。接下来的数据可以通过这个密钥进行加密后传输。
- 为什么需要对称加密和非对称加密
安全和效率的兼顾 -
安全传输公钥
要保证数据的安全，就必须得保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥。那怎么保证呢？
那就得引入数字证书了，数字证书是服务器主动去权威机构申请的，证书中包含了上一个图中的加密过的A公钥和权威机构的信息，所以服务器只需要给客户端下发数字证书即可。现在流程图如下：
image
那数字证书中的A公钥是如何加密的呢？
答案是非对称加密，只不过这里是使用只有权威机构自己才有的私钥加密。
等一下，既然A公钥被权威机构的私钥加密了，那客户端收到证书之后怎么解密证书中的A公钥呢?需要有权威机构的公钥才能解密啊！那这个权威机构的公钥又是怎么安全地传输给客户端的呢？感觉进入了鸡生蛋，蛋生鸡的悖论了~~
别慌，答案是权威机构的公钥不需要传输，因为权威机构会和主流的浏览器或操作系统合作，将他们的公钥内置在浏览器或操作系统环境中。客户端收到证书之后，只需要从证书中找到权威机构的信息，并从本地环境中找到权威机构的公钥，就能正确解密A公钥。
这样就绝对安全了吗？既然权威技能能给服务器签发数字证书，那为什么就不可能给中间人签发数字证书呢?毕竟赚钱的生意权威机构也不会拒绝的呀。
试想一下：
服务器给客户端下发数字证书时证书被中间人劫持了，中间人将服务器的证书替换成自己的证书下发给客户端，客户端收到之后能够通过权威机构的公钥解密证书内容（因为中间人的证书也是权威机构私钥加密的），从而获取公钥，但是，这里的公钥并不是服务器原本的A公钥，而是中间人自己证书中的B公钥。从第二层可知，如果不能保证客户端收到的公钥是服务器下发的，那整个通信数据的安全就没法保证。简单总结就是证书被调包~
所以，还得保证客户端收到的证书就是服务器下发的证书，没有被中间人篡改过。
- 安全传输证书
这一层，我们的任务是：保证客户端收到的证书是服务器下发的证书，没有被中间人篡改过。
所以，这里就有两个需求:
证明证书内容没有被第三方篡改过；
证明证书是服务器下发的；
其实这些问题，数字证书本身已经提供方案了，数字证书中除了包含加密之后的服务器公钥，权威机构的信息之外，还包含了证书内容的签名(先通过Hash函数计算得到证书数字摘要，然后用权威机构私钥加密数字摘要得到数字签名)，签名计算方法以及证书对应的域名。这样一来，客户端收到证书之后：
使用权威机构的公钥解密数字证书，得到证书内容（服务器的公钥）以及证书的数字签名，然后根据证书上描述的计算证书签名的方法计算一下当前证书的签名，与收到的签名作对比，如果一样，表示证书一定是服务器下发的，没有被中间人篡改过。因为中间人虽然有权威机构的公钥，能够解析证书内容并篡改，但是篡改完成之后中间人需要将证书重新加密，但是中间人没有权威机构的私钥，无法加密，强行加密只会导致客户端无法解密，如果中间人强行乱修改证书，就会导致证书内容和证书签名不匹配。所以证书签名就能判断证书是否被篡改
再考虑证书被掉包的情况：中间人同样可以向权威机构申请一份证书，然后在服务器给客户端下发证书的时候劫持原证书，将自己的假证书下发给客户端，客户端收到之后依然能够使用权威机构的公钥解密证书，并且证书签名也没问题。但是这个时候客户端还需要检查证书中的域名和当前访问的域名是否一致。如果不一致，会发出警告！
从上面的分析可以看到，数字证书中的信息确实能让客户端辨别证书的真伪。
