https

本文参考：https://showme.codes/2017-02-20/understand-https/

我的理解是https就是在在对称加密不够保险的情况下，外层套了一堆非对称机密算法来保证对称加密算法的那些东西不会被劫持

首先我们来聊一聊为什么要用https？

http协议没有任何的加密以及身份验证的机制，非常容易遭遇窃听、劫持、篡改，因此会造成个人隐私泄露，恶意的流量劫持等严重的安全问题。如果一旦被拦截到了，后果可想而知，那么我们如何来解决这个问题呢？

我们首先想到了加密

如果这个密码只有服务器和客户端知道，那么就ok了，但是现实中真的是这么简单的吗
当然不是，如果真的是这样的话，那么可能会下图这个样子

这跟完全没有加密有什么区别吗，完全没有好嘛，那么接下来问题来了，如果是下图这样真的可以吗

如果只是这样的话当然不行了，你想问为什么不行？
那么问题来了，如果这样就ok的话，试想一下接下来的场景，客户端是怎么知道你这个服务器端加密的方式的呢，肯定有人会说，那就是服务器端传给客户端的呗，那你这个传输的过程中不会有问题吗，你协商的过程中加密了吗，没有加密的话，被拦截了不就全都知道了吗，有人肯定会说，那再对协商过程进行对称加密不就行了吗，但是你这个再一次协商的这个不还是没有加密的吗，一直死循环中。。。。

那么我们究竟应该如何来对协商过程进行加密呢？

非对称加密的特点是：
公钥加密的只有私钥破解，私钥加密的，公钥都能破解，这样的话私钥可以放在服务器，公钥可以放在客户端。

那么我们至少可以这么认为：最起码从A，B到服务器端是安全的（毕竟公钥只能私钥解，只有一个在server），但是从服务器端到A，B呢，不会出现问题吗？我们抱着这个疑问往下看

当我们看到上图的时候会发现，这个私钥是放在server了，但是公钥又该怎么获得呢，是server发给客户端的？但是真的没有问题吗，如果在发送的过程中，公钥被调包了又该如何是好呢

通过上图的这个流程中间人就可以破解，拿到想要的一切。
显然，让每个客户端的每个浏览器默认保存所有网站的公钥是不现实的。
现在的问题是不知道传给我们信息的究竟是server还是中间人，那么我们可以试着用身份认证来解决这个问题
但是如果自己来解决的话是要加密吗，对称还是非对称？对称对方能破解，非对称也能破解，这可怎么办啊？
所以，我们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端再使用第三方机构的公钥进行解密。

但是这样就真的ok了吗，想法还是太天真，现实中貌似还有个数字签名啊我记得，那都有了数字证书还要数字签名干嘛呢，岂不是多此一举吗？

试着想象下面这个场景，第三机构方不可能只给你一家公司发数字证书吧，万一中间人的公司也获得了同一个第三方机构发的数字证书了怎么办呢？这样的，中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。像下面这样：

这样的话客户端就可以解密统一第三方机构颁发的所有证书

导致被中间人调包

这块需要提醒一下，我在理解调包的过程中出现了偏差，我曾经以为中间人会拿到证书之后把证书破解（公钥可以打开第三方私钥加密的东西，然后更改了之后再用私钥加密，但是问题是，并不知道第三方的私钥是什么，所以加密之后的东西，客户端解不开也就很明显的看出被操作了），所以这种理解是不对的

正确的理解方式是：不对你的证书进行破解，直接把我的证书替换你的，然后你能解密（第三方机构公钥解第三方机构的私钥，反正是同一个第三方，肯定能解的开，这样的话您拿到的就不是server发给你的，而是中间人发给你的，他有私钥，他肯定能破解你用他给你的公钥加密的东西），所以还是被破解了，这可怎么办呢？

我们现在的问题是，如果判断同一第三方机构的不同证书，那么我该怎么进行判断呢，这个东西又应该放在哪里呢。

首先这个东西是什么呢？我们可以理解为一串号码，比如身份证上面的识别每个人的唯一的标示----身份证号（可能不是很形象），那么这个号码我存放在哪里呢，我要去哪里核实呢，又一个机构吗？可是这样的话不会太浪费时间了吗，我们可不可以把它在本地核实呢？

我们试着或下面的说法来解决这个问题：

证书本身就已经告诉客户端怎么验证证书的真伪。
也就是证书上写着如何根据证书的内容生成证书编号。客户端拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。

同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。

然后我们进行校验：

但是问题来了这个第三方的公钥我从哪里获取呢？？？？？

其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。

说到这里，想必大家已经知道上文所说的，证书就是HTTPS中数字证书，证书编号就是数字签名，而第三方机构就是指数字证书签发机构（CA）。

至于CA怎么颁发的，这块我就不是太了解了，这块大家可以自己看一下下面的这个图（copy来的）

然后其实还有点小疑问，为什么非对称加密这么厉害，我们在一开始的过程中还要使用对称加密呢，而且实际上也就是这么加密的（里面具体的加密情况很复杂），我们为什么不一上来就直接采用非对称加密呢？
下面让我们来看一下二者的区别：

对称加密算法的优、缺点：

优点：算法公开、计算量小、加密速度快、加密效率高。

缺点：
（1）交易双方都使用同样钥匙，安全性得不到保证；

（2）每对用户每次使用对称加密算法时，都需要使用其他人不知道的惟一钥匙，这会使得发收信双方所拥有的钥匙数量呈几何级数增长，密钥管理成为用户的负担。

（3）能提供机密性，但是不能提供验证和不可否认性。

1、CPU计算资源消耗非常大。一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的90%以上。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。

2、非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。（就这么点字节没有办法用非对称加密实现对全部加密）

所以非对称加密目前只能用来作密钥交换或者内容签名，不适合用来做应用层传输内容的加解密。

总结

HTTPS要解决http的安全问题，必须使用对称加密算法（非对称能加密的内容字节数太小），但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。