HTTP面试-HTTPS的原理及流程

Posted 2021-04-26 同花技术笔记

前言

面试的时候经常会有人被问到HTTPS，那么有没有人被这么问过呢？

你知道HTTPS的工作原理吗？

你有了解过 「 非对称加密和对称加密 」 吗？

客户端是如何确认，返回证书对应的服务端就是你请求的服务端呢？

相信大家都了解HTTPS正常的流程，也可以说个大概，毕竟无非就是多了个SSL/TLS证书的加解密罢了，但被问到对称加密和非对称加密的时候如果没有提前了解过的话，可能就懵住了（了解过的忽略）。

一般作为面试官通过前两个问题就可以区分开一个人，是否真的有理解HTTPS的工作原理。

HTTP

回顾一下HTTP，HTTP HyperText Transfer Protocol，超文本传输协议，是因特网上应用最为广泛的一种网络传输协议，所有的 WWW 文件都必须遵守这个标准。

主要需要回顾的就是HTTP传输都是明文传输的，并且传输时并不需要验证传输双方的身份。

TLS和SSL

TLS 传输层安全性协议（Transport Layer Security），及其前身 SSL 安全套接层（Secure Sockets Layer）是一种安全协议，目的是为互联网通信提供安全及数据完整性保障。

简单说一下SSL和TLS其实就是服务端持有的，可以在官方、公正的机构(ca)认证的，服务端身份认证证书。

为什么要用HTTPS？

主要就是因为，大家都知道 HTTP 都是明文传输的，在传输的过程中，任何人都是可以从中拦截，串改，获取其中的信息，可以认为 HTTP 是不安全的。

主要表现在两点，也是 HTTPS 解决的两点：

• 身份的认证
• 传输报文的准确性

对称加密和非对称加密

上面说到HTTPS主要解决了 「 身份的认证 」 还有 「 传输报文的准确性 」 这两点。其实这两点就是基于 「 对称加密和非对称加密 」 还有 「 SSL\TLS证书认证 」 实现的，这里主要讲一下加密。

对称加密

对称加密就是客户端和服务端之间的通讯，都用 「 同一套密钥 」 来进行加密解密。

优点

• 算法公开
• 计算量小
• 效率高

缺点

• 双方同时使用同一套密钥，不够安全。
• 密钥管理困难，成本高。

基于对称加密的算法一般有DES、3DES（TripleDES）、AES、RC2、RC4、RC5和Blowfish等。

非对称加密

跟对称加密有些不同，非对称加密需要 「 两套密钥 」 。

客户端A持有自己的私钥A和服务端的公钥B，服务端持有自己的私钥B和客户端的公钥A。

优点

• 算法强度复杂
• 不公开私钥，安全性高

缺点

• 由于算法强度的复杂，效率低下。
• 对于机子资源的开销大。

基于非堆成加密的算法一般有RSA、Elgamal、背包算法、Rabin、D-H、ECC（椭圆曲线加密算法）等。

HTTPS用的是对称加密还是非对称加密？

如果仔细的去分析一下，你会发现如果单纯用哪一个加密的话，都是有缺陷的。

假如用的都是对称加密

这个简单说一下就好了，对称加密主要就是在于连接双方（客户端和服务端） 「 共同持有 」 对称加密用的密钥，才可以进行可靠的数据传输，但如果单纯用对称加密的话是没有办法让 「 只有 」 客户端和服务端共同持有对称加密用的一组密钥的，毕竟存在中间人劫持请求的情况。

假如用的都是非对称加密

上面有说到，非对称加密需要两套密钥，假设现在存在客户端和服务端用来非对称加密用的 公钥A 私钥A 公钥B 私钥B，正常数据传输具体流程应该如下:

1. 客户端将 公钥A 发送给服务端。
2. 服务端拿到 公钥A 将自己的 公钥B 通过非对称加密成密钥传输给客户端。
3. 客户端拿到密钥用 私钥A 解密拿到 公钥B。
4. 客户端将请求数据通过 公钥B 加密发送给服务端。
5. 服务端拿到数据，用 私钥B 解密成请求数据，通过 公钥A 加密，返回响应数据。

这个流程大概也可以看出非对称加密虽然是比对称加密安全了点，但还是存在很明显的缺陷:

1. 非对称加密算法强度复杂，效率低下。
2. 还是不够安全，存在中间人攻击。

中间人攻击的大概流程:

1. 首先中间人会劫持客户端的请求（DNS劫持等），客户端的所有请求都会发送到中间人的服务器。
2. 客户端带 公钥A 发起请求，中间人劫持。
3. 中间人通过劫持到的 公钥A 直接把自己的 公钥X 加密返回给客户端。
4. 客户端通过 私钥A 解密。
5. 同上，客户端跟中间人进行数据传输。
6. 中间人在解密到客户端的请求数据后，正常向服务端进行请求。
7. 中间人将服务端响应的数据返回给客户端。

对称加密和非对称加密的组合

其实HTTPS使用的是对称加密和非对称加密的组合。

试想，非对称加密比较安全，对称加密效率高，我们可以结合一下，用 「 非对称加密 」  来达到 「 连接双方持有一套对称加密用的密钥 」 ，即可解决，步骤如下:

1. 客户端向服务端发起连接请求，请求头中带有客户端支持的非对称加密算法。
2. 服务端向客户端传输 公钥B。
3. 客户端生成 随机数 ，跟服务端的 公钥B 非对称加密成 密钥串 传输给服务端。
4. 服务端收到 密钥 ，通过 私钥B 解密成对称加密用的 随机数。

接下来客户端和服务端的数据传输都通过对称加密来完成就好了，这样效率不是快了吗？

---

但是你以为这样我中间人大哥就没有办法了吗？我还可以这样:

1. 首先中间人会劫持客户端的请求（DNS劫持等），客户端的所有请求都会发送到中间人的服务器。
2. 中间人服务器返回中间人自己的 公钥Z。
3. 客户端创建 随机数，通过中间人的 公钥Z 对随机数加密后发给中间人。之后就用这个 随机数 跟中间人进行通讯。
4. 完了中间人以客户端的请求内容向服务端发送请求。

此时中间人因为持有客户端的对称加密用的随机数和所有的请求，中间人就可以伪装成客户端向正规的网站发送请求。

5. 因为中间人跟服务端的请求是合法的，所以中间人可以光明正大的拿着客户端的请求数据来请求服务端，服务端通过建立的安全通道返回加密后的数据。
6. 中间人凭借跟服务端建立的对称加密算法对内容进行解密。
7. 中间人通过与客户端建立的对称加密算法对服务端返回的数据进行加密传输。
8. 客户端解密收到的数据。

这就是中间人劫持的过程，所以我们这里还少了一步 「 身份的认证 」，也就是ssl/tls证书的认证。

SSL/TLS证书认证

上边通过了 「 非对称加密和对称加密 」 的组合解决了效率低下的问题，现在就看看 「 ssl/tls证书认证 」 是如何防止中间人劫持客户端请求的:

CA

CA认证，即 「 电子认证服务 」，是指为电子签名相关各方提供真实性、可靠性验证的活动。

CA机构（Certificate Authority）即颁发数字证书的机构。是电子交易、网络数据交流中权威的受信任的第三方机构，承担公钥体系中公钥的合法性检验的责任。

其实客户端跟服务端之间的传输，不是通过非对称加密用的公钥或者对称加密用的密钥来传输的。它是通过SSL/TLS证书来进行传输的。

这里说下加入SSL/TLS认证的 HTTPS 流程:

1. 客户端向服务端发起请求。
2. 服务端返回自己事先在 「 权威ca机构申请的证书 」，证书里面包含了各种信息，如服务器非对称加密用的 公钥B ，服务器的基本信息（Host等）。
3. 客户端拿到证书后，首先检查该数字证书的合法性：这里简单来理解可以认为是，向权威第三方CA机构校验证书，证书里的 host 对应的是不是你请求的服务器等等（这里有校验的方法，下次再说），如果是的话，则取证书里面的服务器 公钥B 继续。
4. 生成对称加密用的 随机数，拿到 公钥B 进行非对称加密，传输给服务端。
5. 下面流程是一样的。

为什么不用HTTPS

前面都有说到HTTPS多好啊，又安全又放心，数据完美无缺呀，但是就算这样，数据显示，目前起码有65%的用户仍然在用HTTP协议，HTTPS的普及率很底，这是为什么呢?

1. 目前国内web网站的安全意识比较薄弱。
2. HTTPS需要一定的技术门槛，还有费用成本。

不过目前也有很多大厂推动使用HTTPS的，就比方说微信小程序，有做过的都知道必须要HTTPS的接口他们才支持啊，当然还有其它的我就不举例了，大概就那么多把。

PS

都结合网上资料加上自己的一些理解，如果有影响到人的地方，可以联系我：[e-mail]