文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

HTTPS 是如何运作的?它解决了什么问题?

2024-11-30 13:20

关注

简单了解 HTTP

从何而来

要了解 HTTPS,自然我们要先了解 HTTP 协议,最初 HTTP 协议的出现是为了让全球的研究者知识共享而发明出来的,它于 1990 年被发明出来,但这一版本的 HTTP 协议并没有作为标准。

HTTP/0.9

Tim Berners-Lee 和他的团队提出这个最早的 HTTP/0.9 版本存在一些不明确的地方,例如:

这就是最初的 HTTP,存在很多的缺陷,也难怪没有成为标准。

HTTP/1.0

到了1996年5月,HTTP 提出了新的版本 HTTP/1.0,而它也成了 HTTP 第一个正式的版本,也被正式的标准化。它解决了 HTTP/0.9 没有解决的问题,例如:

我们现在之后后续的主流版本其实是 HTTP/1.1,这说明当时提出的 HTTP/1.0 其实还是存在部分的问题。

HTTP/1.1

1997年1月,HTTP/1.1 发布,这也是在 HTTP/2.0 出来之前最为主流的版本,我们来看看它解决了什么问题就知道 HTTP/1.0 存在的缺陷了。

所谓持久化连接机制,即服用底层的 TCP 连接。HTTP 底层通信使用的是 TCP,在 HTTP/1.1 之前都是发起一个 HTTP 请求就会建立一个 TCP 连接,传输数据之后再断开。这波操作在 HTTP/1.0 那个时间是没问题的,HTTP 没普及,传输的内容也都是小容量的文本。但随着 HTTP 的普及,传输的内容变得也越来越来丰富,况且还新增了图片、音视频。像这样频繁的发起、断开 TCP 连接会大大的增加页面资源的加载速度,降低用户的体验。所谓持久化连接也就是,只要任意一方没有提出断开 TCP 连接,就继续复用这个连接,减少了创建连接带来的开销。

而管线化技术则是发送一个请求不用等待其响应,继续发送下一个请求。没有管线化技术时,必须等待上一个请求响应回来之后才能发送下一个请求,而这种机制在网络较慢的情况下会引发一个问题——队头阻塞。比如,请求一张较大的图片,偏偏网络还慢,那么后续的请求都会被阻塞。但管线化技术解决了这个问题吗?解决了一部分,没有完全解决。采用管线化技术,请求虽然发出去了,但它是有序的, 所以在等待响应时,这一批里有响应迟迟没有回来,后续的请求仍然要等待。所以这个问题并没有完全解决。

HTTP/2.0

既然有问题,那么后续就需要有新的版本来解决这些问题。2015年5月,HTTP/2.0 正式标准化,之后慢慢开始大面积的普及,那么它又解决了哪些问题呢?主要如下:

当然,相信你也知道,现在 HTTP/3.0 也出来了,其关键的改动在于将底层传输层的协议从 TCP 切换到了 QUIC,其底层采用的是 UDP,这个后面有机会单独写一篇文章来介绍。

Why HTTPS?

HTTP 即使推出了很多个版本,但是仍然存在问题,例如:

混合加密

所以这才有了 HTTPS,也就是 HTTP + TLS。

在 HTTP 协议中,由它本身直接和 HTTP 通信,而在 HTTPS 协议中,HTTP 是和 TLS 进行通信,相当于给套了一层娃,加了个中间层。

那要如何进行加密呢?

HTTPS 采用了混合加密的方式,大致的流程如下:

到这里,客户端和浏览器就将后续通信加解密要使用到的密钥安全的进行了传输,后续客户端服务器的所有通信都会使用这个随机密钥。所谓的混合加密就是即使用了对称加密,也使用了非对称加密。

中间人攻击

但是这个步骤有个比较明显的问题,即——中间人攻击。

还是基于上面的这个步骤,客户端以为自己在和服务器通信,实际上它在和中间人通信,然后中间人将服务器的真正公钥  S 保存了下来,然后把中间人自己的公钥 B 返回给了客户端。

客户端拿到了中间人的公钥 B,然后使用公钥 B 对其生成的随机密钥进行加密,然后传给中间人。中间人拿到了加密密文,使用自己的私钥 B’ 进行解密,到这里就拿到了客户端的随机密钥。然后再用保存好的服务器真正公钥 S 加密,将密文再传给服务器。其流程如下图所示:

中间人攻击示意图

这样就完成了一波套娃,并且客户端和服务器都没有感知。这样一来,一旦攻击成功,后续的通信中间人都能够通过前面步骤拿到的随机密钥进行解密,然后篡改,再加密传给服务器。

那该如何解决这个问题呢?

在上面的流程中,其关键的问题在于客户端无法证明服务器返回的公钥的正确性,它可能是中间人的公钥,而不是服务器的。如果有某种方式能够让我们确认,这个公钥的的确确就是服务器的真实公钥,上面的问题就迎刃而解了。

而这就是 CA。

CA 证书

全称为 Certificate Authority,它是一个机构,可以将其理解为客户端和服务器都可以信赖的一个第三方。开发人员会将服务器的真实公钥提供给 CA,然后 CA 判断服务器的身份之后,会对公钥签名,然后将其和 CA 证书绑定在一起。当然 CA 证书包含的不仅仅只有签名,还有序列号、用途、颁发者、有效时间之类的。

然后客户端来请求公钥时,服务器会直接把证书返回给客户端。那么问题又来了,你怎么能够保证返回的证书不是由中间人返回的?加了个 CA 就能够解决这个问题吗?

当然不是。

客户端还会对 CA 证书进行校验,以此来保证:

否则仍然会面临中间人攻击的风险。那客户端是如何验证这两点的呢?

首先,在将服务器公钥提供给 CA 时,CA 会使用自己的私钥对服务器公钥进行签名。注意,这里是私钥,不是公钥。然后客户端拿到这个证书之后,会使用 CA 的公钥(内置在浏览器中)对其进行解密,然后拿到 CA 侧登记证书时计算的 Hash 值,然后客户端会根据证书上的信息,使用同样的算法计算出另一个 Hash 值,然后将这两个 Hash 值对比,就能够知道证书是否可信赖。当然,这个只是其中的一个步骤,CA 的认证还涉及到信任链的问题,这里不展开。

当然,CA 也不能解决全部的问题。之前也出过 CA 机构被黑的事故,非法颁发了 Google 和 Twitter 的伪造证书。

HTTPS 握手过程

握手的过程,总结成了一张图,其实就是将上面将的 HTTPS 的加密原理细化了一下:


来源:SH的全栈笔记内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯