解读HTTPS协议(一)

之前无聊看了一副漫画,主要是用来解读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的通信比较安全的粗略解释,之后再深入理解一下!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

丶懿

你的鼓励是我最大的创作动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值