解读HTTPS协议（一）

最新推荐文章于 2021-10-28 14:21:55 发布

丶懿

最新推荐文章于 2021-10-28 14:21:55 发布

阅读量228

点赞数 1

分类专栏：协议相关文章标签： Http协议

本文链接：https://blog.csdn.net/yinlidong77/article/details/87859386

版权

协议相关专栏收录该内容

7 篇文章 2 订阅

订阅专栏

之前无聊看了一副漫画，主要是用来解读HTTPS协议的，包括他的原理一系列的东西，有点感想，感觉写的不错，我自己也总结了一点。写出来记录一下。
首先我们先说什么事HTTPS协议？
全称：Hyper Text Transfer Protocol over Secure Socket Layer（超文本传输安全协议），是以安全为目标的HTTP通道，简单讲是HTTP的安全版，那么什么是HTTP协议呢？

HTTP协议全称Hyper Text Transfer Protocol
翻译过来就是超文本传输协议，位于TCP/IP四层模型当中的应用层
在这里插入图片描述
HTTP协议一般都是通过请求和相应的方式来进行交互的，这也就是说他在client和server中间是通过request和response来进行交互的

但是HTTP协议有个很大的缺点，那就是不够安全，容易被别人截获，HTTP协议的信息传输完全以明文方式，不做任何加密，就相当与啥都不穿一样的裸奔。
这是最容易在中间出现第三者的，这个第三者可以称之为中间人攻击，他很有可能吧request的内容拦截到之后，然后自己做了一堆的处理直接发送在客户端。这就是他的不安全性。

有没有方法来解决这个问题呢？
肯定是有的，
我们思考几种有意思的方式，方式一：
client和server约定好一种对称加密方式，并且约定一个随机生成的密钥，后边再进行交流的时候，发送方对使用密钥对信息加密，信息的接受发个通过同样的密钥解密。
比如说a和b约定好使用AES加密密钥是xxxxx，然后a给b传递的信息就是#@！￥%￥%……一堆东西，b拿到这个之后通过密钥，解析出来，然后b再给a说！@%￥%@@…这样a拿到之后再进行解密。
但是这种方式是也是不安全的，虽然我们在后续的通信中对明文做了加密了，但是第一次约定加密方式和密钥的通信的时候，还是明文的，如果从第一次就被拦截到了，那么密钥就会泄露出去，泄露给第三者，第三者仍然能够解密后续的所有的内容。这就是对称加密的弊端所在。

方式二：非对称加密，给密钥的传输层做一层额外的保护？
那我们可以这么想，非对称加密的一组秘钥对中，包含一个公钥一个私钥，明文既可以用公钥加密，用私钥解密，也可以用私钥加密，用公钥解密，

也就是说在A和B建立通信的时候，A首先吧自己的公钥发给了B
，B收到A的公钥之后，自己生成了一个用于对称加密的密钥Key2，并且用刚才接收到的公钥Key1对Key2进行了加密之后，发给A，然后A利用自己非对称加密的私钥，解开公钥Key1的加密，获取Key2的内容，之后的话就会出现AheB利用Key2进行对称加密的通信了！
图解的话就是这个样子
在这里插入图片描述

但是这种方式能保证绝对的安全么？好像不是的，仔细想想，如果说中间的第三者虽然不知道A的私钥是什么，但是如果说截取到了A的公钥Key1的话，却是可以修改的，自己生成一堆公钥私钥，吧自己的公钥给B。

在这里插入图片描述
而B是不知道公钥被第三者偷换了，以为传递过来的Key3是A给的公钥，于是就开始解密，使用Key3，生成了对称加密密钥Key2，发送给A，
然后再被拦截之后，第三者用自己的私钥结开了Key3的加密，获得了Key2，然后在用当初A发过来的Key1进行加密之后发给A，这样的话毫无安全性可言。

在这里插入图片描述
也就是说，A和B虽然用Key2做了加密，但是中间人是有Key2的所以能够很容易的进行解密。这就是bug所在。
有人会说，为啥不把公钥在进行加密，那这样的话不久乱了么，鸡大生蛋，蛋破生鸡，没完没了了，

所以，这个时候我们就有必要引入第三方来了，一个权威的证书颁发机构（CA），我们看看什么是证书。
在这里插入图片描述
CA 也拥有一个证书（内含公钥和私钥）。网上的公众用户通过验证 CA 的签字从而信任 CA ，任何人都可以得到 CA 的证书（含公钥），用以验证它所签发的证书。

如果用户想得到一份属于自己的证书，他应先向 CA 提出申请。在 CA 判明申请者的身份后，便为他分配一个公钥，并且 CA 将该公钥与申请者的身份信息绑在一起，并为之签字后，便形成证书发给申请者。

如果一个用户想鉴别另一个证书的真伪，他就用 CA 的公钥对那个证书上的签字进行验证，一旦验证通过，该证书就被认为是有效的。证书实际是由证书签证机关（CA）签发的对用户的公钥的认证。
大致流程如下：
server端A，Client端的B，
1.A首先吧自己的公钥发给证书的颁发机构，向证书颁发机构申请证书，
2.证书颁发机构自己有公钥和私钥，机构利用自己的私钥来加密Key1，并且通过服务端网址等信息生成一个证书签名，证书签名同样是经过机构的私钥加密，证书完成之后，机构把证书给A，这个流程就执行完毕了

3.当B向A说，我们通信吧，A这时候就不使用自己的Key1了，而是直接把证书给了B，

4.B拿到证书之后，首先要做的就是验证证书的真伪，因为浏览器和操作系统已经维护了所有权威证书机构的名称和公钥，也就是说B只要知道是那个机构颁发的证书，就能从本地找到机构公钥，解密出证书的签名，然后B按照同样的签名规则，自己也会生成一个证书签名，如果两个签名一致，说明证书是有效的。
验证成功之后，B就可以利用机构公钥，解密出A的Key1，

5.然后生成自己的加密密钥Key2，并且用服务端公钥Key1加密Key2，发送给A。

6.A最后用自己的私钥解密，得到对称加密密钥Key2，于是A和B会使用Key2来进行对称加密的通信，
这样就是HTTPS协议的思想，这个系列认证流程一般都是在SSL层完成
在这里插入图片描述
最新推出的TLS协议，是SSL 3.0协议的升级版，和SSL协议的大体原理是相同的，前提不要把SSL协议关掉，以上就是HTTPS的通信比较安全的粗略解释，之后再深入理解一下！