https://blog.csdn.net/luweicheng24/article/details/80579731
1、Http为何不安全
http协议属于明文传输协议，交互过程以及数据传输都没有进行加密，通信双方也没有进行任何认证，通信过程非常容易遭遇劫持、监听、篡改，严重情况下，会造成恶意的流量劫持等问题，甚至造成个人隐私泄露（比如银行卡卡号和密码泄露）等严重的安全问题。可以把http通信比喻成寄送信件一样，A给B寄信，信件在寄送过程中，会经过很多的邮递员之手，他们可以拆开信读取里面的内容（因为http是明文传输的）。A的信件里面的任何内容（包括各类账号和密码）都会被轻易窃取。除此之外，邮递员们还可以伪造或者修改信件的内容，导致B接收到的信件内容是假的。比如常见的，在http通信过程中，“中间人”将广告链接嵌入到服务器发给用户的http响应报文里，导致 用户界面出现很多不良链接； 或者是修改用户的请求头URL，导致用户的请求被劫持到另外一个网站，用户的请求永远到不了真正的服务器。这些都会导致用户得不到正确的服务，甚至是损失惨重。
2、Https如何保证数据的完整性
既然知道了Http的不安全，那我们先用自己的办法来慢慢引入Https，既然传输过程数据容易被修改，那客户端和服务端可以使用加密算法将数据加密，只有client与server知道，那就可以使用对称加密算法：
这样只要不公开秘钥S 就能保证数据不被修改，但是在WWW的Web环境下将会变成这样的结构：
如此一来，既然所有的客户端都是用这套加密算法，就像你们家的房门锁，不光你有钥匙，所有人都有钥匙，小偷也有，那这个锁还有存在的必要吗？同理，第三方劫持人同样也会得到你的加密算法的秘钥，然后劫持传递的消息。
那又如何解决这个问题呢？既能使用对称加密，又不公开秘钥？
这样，可以规定Web服务器和每个客户端使用不同的加密算法，不就解决了吗。
但是如果这样的话，服务端必须和客户端去协商我们该使用那个算法，之后再使用该算法来通信：
但是，你协商的过程是没有加密的，还是会被中间人拦截。 那我们再对这个协商过程进行对称加密就好了，那你对协商过程加密的加密还是没有加密，怎么办？再加密不就好了……好吧，进行鸡生蛋蛋生鸡的问题了。
2.1 如何对协商进行加密？
如何对协商过程进行加密？密码学领域中，有一种称为“非对称加密”的加密算法，特点是 私钥加密后的密文，只要是公钥，都可以解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。
虽然服务器端向A、B……的方向还是不安全的，但是至少A、B向服务器端方向是安全的。
好了，如何协商加密算法的问题，我们解决了：使用非对称加密算法进行对称加密算法协商过程。
这下，你明白为什么HTTPS同时需要 对称加密算法和非对称加密算法了吧。
那么Web与客户端是如何随机生成对称加密算法呢？ 使用随机数，就是使用 随机数来生成 对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一刻才确定加密算法。
这下，你明白为什么 HTTPS协议握手阶段会有这么多的随机数了吧。
既然这样采用 非对称加密算法 保证 对称加密算法 的安全，但是采用 对称加密 能保证 客户端得到公钥后加密数据给服务 的安全，但是 服务端 如何 将 公钥 安全的给客户端呢？
2.2 非对称加密算法的公钥传输
客户端向服务器获取公钥的方式：
- 向
服务器发送获取公钥 - 向一个
单独存放公钥的服务器发送获取公钥
我们采用第一种方式获取公钥，但是在我们获取这个公钥的请求过程中同样会被第三发替换
这样，那有如何来保证公钥的传输安全呢？ 我们再用非对称加密算法。。。。这有事一个鸡生蛋，蛋生鸡的问题了。
2.3 第三方机构解决公钥传输安全问题
公钥被调包的问题出现，是因为我们的客户端无法分辨返回公钥的人到底是中间人，还是真的服务器。这其实就是密码学中提的身份验证问题。所以，我们不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。客户端 再使用第三方机构的公钥 进行解密。下图就是我们设计的第一版“数字证书”，证书中 只有服务器交给第三方机构的公钥，而且这个公钥 被第三方机构的私钥 加密了：
如果能解密，就说明这个公钥没有被中间人调包。因为如果中间人使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方的公钥进行解密的。
原来，我漏掉了一个场景： 第三方机构不可能只给你一家公司制作证书，它也可能会给中间人这样有坏心思的公司发放证书。这样中间人就有机会对你的证书进行调包，客户端在这种情况下是无法分辨出是接收的是你的证书，还是中间人的。因为不论中间人，还是你的证书，都能使用第三方机构的公钥进行解密。像下面这样：
2.4 数字签名，解决同一机构颁发的不同证书被篡改问题
要解决这个问题，我们首先要想清楚一个问题，辨别同一机构下不同证书的这个职责，我们应该放在哪？
只能放到客户端了。意思是，客户端在拿到证书后，有能力分辨证书是否被篡改了。如何才能有这个能力呢？
我们从现实中找灵感。比如你是HR，你手上拿到候选人的学历证书，证书上写了持证人，颁发机构，颁发时间等等，同时证书上，还写有一个最重要的：证书编号！我们怎么鉴别这张证书是的真伪呢？只要拿着这个证书编号上相关机构去查，如果证书上的持证人与现实的这个候选人一致，同时证书编号也能对应上，那么就说明这个证书是真实的。
我们的客户端能不能采用这个机制呢？像这样：
可是，这个“第三方机构”到底是在哪呢？是一个远端服务？不可能吧？如果是个远端服务，整个交互都会慢了。所以，这个第三方机构的验证功能只能放在 客户端的本地了。
2.5 客户端本地怎么验证证书呢？
客户端本地怎么验证证书呢？答案是证书本身 就已经告诉客户端 怎么验证证书的真伪。
也就是证书上 写着如何根据证书的内容 生成证书编号。客户端拿到证书后根据证书上的方法 自己生成一个证书编号，如果生成的证书编号 与证书上的证书编号相同，那么说明这个证书是真实的。同时，为避免证书编号本身又被调包，所以使用第三方的私钥进行加密。
这地方有些抽象，我们来个图帮助理解：
证书的制作如图所示。证书中的“编号生成方法 MD5”就是告诉客户端：你使用MD5 对证书的内容求值 就可以得到一个证书编号。
当客户端拿到证书后，开始对证书中的内容进行验证，如果客户端计算出来的证书编号与证书中的证书编号相同，则验证通过：
但是第三方机构的公钥 怎么跑到了客户端的机器中呢？ 世界上这么多机器。
其实呢，现实中，浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端 接收到的证书中 会写有 颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。
题外话：如果浏览器和操作系统这道防线被破了，就没办法。想想当年自己装过的非常规XP系统，都害怕。
说到这里，想必大家已经知道上文所说的，证书 就是HTTPS中 数字证书，证书编号 就是 数字签名，而第三方机构 就是指数字证书签发机构（CA）。
3、一句话大体总结
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要 使用非对称加密算法 来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器 不直接使用 公钥，而是使用 数字证书签发机构 颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制 协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。