[秃破前端面试] —— HTTP && HTTPS

2,942 阅读11分钟

前言

年前年后跳槽季,准备从面试内容入手看看前端相关知识点,旨在探究一个系列知识点,能力范围之内的深入探究一下。重在实践,针对初级前端和准备面试的同学,争取附上实际的代码例子以及相关试题~系列名字就用【秃破前端】—— 因为圈内大家共识,技术与发量成正比。😄希望大家早日 破瓶颈~

关于面试题或者某个知识点的文章太多了,这里笔者只是想把个人的总结用代码仓库的形式记录下来并输出文章,毕竟理论不等于实践,知其然也要知其所以然,实践用过才能真正理解~

相关系列同类型文章:

目前大部分网站应该使用的都是 HTTPS 协议了,我们在面试时经常会被问到 HTTP 和 HTTPS 相关的问题,我们只知道 HTTPS 要比 HTTP 安全,不过到真正的灵魂拷问的时候,却有些不知所措:

灵魂三连问:
    1. 为什么 HTTP 不安全?
    
    2. HTTPS 的底层是如何实现?
    
    3. 网站用了 HTTPS 就一定安全吗?

知其然还要知其所以然,所以今天就来探究探究到底为啥 HTTPS 是安全的。

HTTP为啥不安全

探究HTTPS安全之前,我们应该先探究一下使用了这么多年的 HTTP 为啥子不安全。首先得了解一下网络相关的东西,面试的时候经常被问到,TCP/IP 三次握手之类的网络知识。从《计算机网络》中我们得知网络中的数据是以包的形式在网络模型各层之间进行传递的,HTTP 协议位于应用层,TCP/IP协议 的上层,而数据报文在这些层之间传递都是没有加密明文传递的。这也就导致了如下问题:

所有图片均摘自网络以及《图解 HTTP》一书,方便大家理解。

通信时采用明文(不加密),内容可能被窃听

从上面可以看出,我们作为客户端处于庞大互联网中的一个节点,而在与进行通信时,中间会经历很多个阶段,而每一个阶段报文内容都有可能被窃听~

无法验证接收报文的完整性,可能已被篡改

无法验证完整性,即意味着接收到的报文可能是缺失的,也意味着接收到的报文可能是错误的,也就是不是我们想要的,如下图:

作为客户端向服务器请求数据,服务器响应的是 A 内容,客户端接收到的是 B 内容,但是客户端并不能知道 A 是否与 B 相同,因为在传输过程中报文就可能被篡改了。这个过程通常被称为“中间人攻击”。

HTTP协议不验证通信方身份,因此可能被伪装

HTTP 协议设计的十分简单,并且不验证通信双方,也就意味着,不论是谁发送的请求,只要合法(后台没有限制访问 ip 和端口号),服务器都会接受。而不确认通信方身份可能会导致如下几个问题:

  • 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器。
  • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
  • 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息,只想发给特定用户通信的权限。
  • 无法判定请求是来自何方、出自谁手。
  • 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击(Denial of Service,拒绝服务攻击)。也就是容易遭受攻击。

总的来说就是:不靠谱~。但是人类社会不就这样嘛,再没有更好的解决方案出现之前,谁会在意这些东西呢~那么社会总是进步的,为了解决网络安全问题就出现了所谓的HTTPS。

HTTPS实现原理

由于HTTP是这么的不安全,所以为了解决上述这些问题,HTTPS 应运而生~而且现在大部分网站也已经过渡到了 HTTPS,所以我们才更应该了解一下。

上面是我偶然发现的,没记住掘金域名,想用掘金举例子,结果用.com搜出来的并不是掘金,而恰巧它还是http协议的,可以看到,现在的浏览器,如果是 HTTP 协议的,就很明目的提示我们此网站是不安全的,因此我们在输入一些表单私人信息的时候就需要注意了。而第二个图则是掘金的,很明显旁边有个小锁头,看起来就很稳妥有安全感~

出上面两种外,其实还有其他状态比如HTTPS域名下引用了部分 HTTP 内容,那么就会是另一种状态,如下图所示:(一来说,如果是公司项目,最好将网络的图片和 js 脚本放到自己的域名下)

HTTPS 本质也是基于 HTTP 协议的,不过通过一些安全手段来解决上面 HTTP 存在的问题。它的通用接口部分使用 SSL(Secure Socket Layer) 和 TLS(Transport Layer Security) 协议代替。以前来说,HTTP 协议是应用层协议,直接和下层 TCP 进行通信,而增加了 SSL 协议之后,就变成了 HTTP 先跟 SSL 通信再由 SSL 跟 TCP 通信,也就是说HTTPS是披着 SSL 协议外壳的 HTTP 协议。

SSL 是独立于 HTTP 的协议,所以不光是 HTTP 协议,其他运行在应 用层的 SMTP 和 Telnet 等协议均可配合 SSL 协议使用。可以说 SSL 是 当今世界上应用最为广泛的网络安全技术。

简单地讲HTTPS = HTTP + 加密 + 证书 + 完整性保护

加密

如果你看过相关的HTTPS资料,相信你一定知道 HTTPS 采用的是混合加密机制。也就是对称加密与非对称加密混用来实现加密机制。

数据传输阶段 —— 对称密钥加密

对称密钥加密又称为共享密钥加密(Common key crypto system),是在加密和解密阶段使用同一个密钥的方式。这也就意味着通信双方必须都存储一份相同的密钥,但是这也就意味着,只要攻击者获取到密钥,那么一样可以进行攻击。

因此,加密的重中之重就是如何能安全的发送密钥不被窃取?

证书交验证阶段 —— 非对称密钥加密

公开密钥加密(Public-key cryptography)解决了上述的发送密钥问题。它采用一对儿非对称的密钥,一把是私有密钥(private key),一把是公开密钥(public key)。加密过程就是,发送加密报文的一方使用对方的公开密钥进行加密,接收方使用自己本地的私有密钥进行解密,也就是说发送方并不需要附带着发送用来解密的密钥,这种方式就不需要考虑密钥在传输过程中被攻击者获取到。

私有密钥与公开密钥的关系是一对多的关系,公开密钥可以发送转交给任何人,而只要采用公开密钥加密的报文,都只能使用本地唯一的私有密钥进行解密。

混合加密机制

上面说了,HTTPS 采用的是混合加密,那么既然非对称的公开密钥方式更好,为啥不只采一种呢?

原因是,非对称的公开加密相比对称的共享密钥加密处理起来更为复杂,效率更低,在前端业务交互中,一般来说都是存在大量的 HTTP 请求的,所以非对称加密的效率是无法被接受的。此外非对称加密的场景只在服务端保存私钥,也就是说一对公私钥只能是单向传输数据,用来确认通信安全以及服务端返回证书。确认安全之后,传输数据采用的就是速度更快的共享密钥。

证书

上面的过程也存在一个问题,安全的本质是使用密钥来进行数据加密解密。那么如果最本质的密钥都是有问题的,那么安全性就无从谈起,因此,这个密钥必须是通信双方,也就是客户端和服务端都认证通过的才行。这个工作既不能客户端去做,也不能服务端去做,一般来说是交给第三方权威机构 —— 数字证书认证机构(CA,Certificate Authority)。

认证机关的公开密钥必须安全地转交给客户端。使用通信方式时,如何安全转交是一件很困难的事,因此,多数浏览器开发商发布版本时,会事先在内部植入常用认证机关的公开密钥,如下图所示(火狐浏览器内置证书):

数据完整性

确保数据完整性,也就意味着数据安全没有被第三方攻击者篡改。如何确保的呢?答案是通过数字签名

数字签名

数字签名是一段由发送者生成的特殊加密校验码,用于传输过程中确认报文的完整性。数字签名的整个过程涉及到两种技术:非对称加密和数字摘要。生成数字摘要的算法通是MD5和SHA这种不可逆算法,将不定长的报文内容提取出定长的数字摘要。

数字签名的整个签名和校验过程分为五步:

  1. 发送方用摘要算法对报文提取生成数字摘要
  2. 使用私钥对摘要进行加密加密后的摘要作为数字签名附加在报文上,一起发送给接收方
  3. 接收方收到报文后,使用相同的摘要算法提取出摘要
  4. 再使用公钥对报文的数字签名进行解密
  5. 如果解密后的数字签名与提取出得摘要相同,那么就可以证明报文没被篡改,数据是完整的

多说一句,对于本地存储,无论是服务端的私钥还是客户端的随机数,都不是 HTTPS 通信过程的安全考虑,HTTPS 只保证在网络传输过程的数据安全性,本地的内容安全不被窃取依靠的是防火墙,杀毒软件等等。

最后,附上一个HTTPS通信完整过程图。

  • 证书验证阶段

    浏览器发起 HTTPS 请求

    服务端返回 HTTPS 证书

    客户端验证证书是否合法,如果不合法则提示告警

  • 数据传输阶段

    当证书验证合法后,在本地生成随机密码串

    通过公钥加密随机密码串,并把加密后的随机密码串传输到服务端

    服务端通过私钥对随机密码串进行解密

    服务端通过客户端传入的随机密码串构造对称加密算法,对返回结果内容进行加密后传输

HTTPS并不全是优点

  • 速度会慢 2~100 倍

    HTTPS慢其实是慢在 SSL 协议通信商上,因为 SSL 协议要进行加密解密处理,会占用CPU和网络资源,总体上会慢一些。

  • CA证书一般来说不免费

    其次就是,申请 CA 证书是需要花钱的,当然,现在很多手段可以申请到免费的 HTTPS 证书,但是大部分权威的还是收费的。所以大部分小型个人开发者,使用的应该都是HTTP协议。

相关题目

1.HTTP为什么不安全?

  • 报文是明文的,未加密
  • 无法验证报文完整性,传输过程中可能会篡改
  • 不验证通信双方身份,可能被伪装

2.HTTPS为什么安全?

HTTPS = HTTP + 加密 + 证书 + 完整性保护。而相关安全操作是通过 SSL 协议来进行实现的。

3.HTTPS绝对安全吗?

不绝对安全,HTTPS 也会被抓包,只不过内容是被加密过的,不过,用户是可以主动对证书进行授信的,如果用户授信通过,那么代理软件是可以对传输内容进行解密的。

总结

这篇文章写的时候一边从头看了一遍《图解 HTTP》,一边查阅相关加密解密过程,确实不是擅长的领域,但是相信总结的东西应付面试足够了。另外,这个领域应该不存在代码书写,送一也就没有 code 了。

参考文献

附带彩色版pdf链接,供大家参考