1. 前言

上一章节中我们主要就 HTTPS 协议的前置知识进行介绍，下面会继续介绍 HTTPS 的通信过程以及抛出一些常见问题的探讨。因为候选人准备面试的时间和精力是比较有限的，我们在学习的过程要抓住重点，如果感觉对于细节缺乏了解，可以通过维基百科和查阅 StackOverflow 等方式进行自行补充。

2. HTTPS 协议

2.1 HTTPS 请求流程

面试官提问： HTTPS 的请求流程和 HTTP 协议的请求流程有什么区别？

题目解析：

参考 HTTPS 的官方文档，我们将整个请求的流程简单抽象为以下几个步骤，抓住其中的核心步骤：

步骤（1）：客户端发送一个 HTTPS 请求，例如请求 https://imooc.com，连接到服务器端的 443 端口（和 HTTP 协议不同，HTTP 默认 80 端口）。

步骤（2）：服务器端收到握手信息，使用预先配置好的数字证书，即图中的公钥和私钥。如果是自己颁发的证书，那么需要客户端通过浏览器的弹窗验证，如果是组织申请获得，默认直接通过。

步骤（3）：传输证书给客户端，证书组装了多种信息，包含证书的颁发机构、证书有效时间、服务器端的公钥，证书签名等。

步骤（4）：客户端解析证书，也就是通过 TLS/SSL 协议，判定公钥是否有效，如果发现异常，会弹出警告框。如果校验没有问题，那么客户端会生成一个随机数，然后用上一步传输过来的公钥对随机数进行加密。

步骤（5）：客户端将上个步骤随机数加密后的内容传输给服务器端，这个随机数就是两端通信的核心。

步骤（6）：服务器端用自己的私钥进行解密，获取解密前的随机数。然后组装会话秘钥，这里私钥和客户端会话秘钥是相同的。

步骤（7）：将服务器端用私钥加密后的内容传输给客户端，在客户端用之前生成的随机数组装私钥还原。

步骤（8）：客户端用之前的私钥解密获取的信息，也就获取了通信内容。

上述过程中，SSL 和 TLS 协议是核心模块，具体的证书交互流程相对复杂，面试场景基本不会涉及。我们需要关注的是为什么 HTTPS 同时使用非对称加密和对称加密，有两个原因：

（1）对称加密流程两边需要使用相同的密钥，单纯使用对称加密，无法实现密钥交换。

（2）非对称加密：满足安全要求，但是非对称加密的计算耗时高于对称加密的 2-3 个数量级（相同安全加密级别），对于实际的应用场景，例如电商网站，对网络交互高耗时容忍度是非常低的。所以 HTTPS 才先使用非对称交换密钥，之后再使用对称加密通信。

2.2 数字证书

面试官提问： HTTPS 通信过程涉及到的数字证书、签名是什么概念？

题目解析：

数字证书是 CA（Certificate Authority）机构发布的，作用是标记通信双方的身份。

CA 机构总共颁布了 DV、OV、EV 三种证书，他们的区别在于可信任程度。

（1）DV 级别证书：域名级别可信，证书中不显示企业信息，安全性较差；

（2）OV 级别证书：企业验证型证书，目前使用最广泛的证书；

（3）EV 级别证书：增强验证型证书，验证最严格的证书，使用者例如 Github 官网。

DV、OV、EV 三种，区别在于可信程度。DV 是最低的，只是域名级别的可信，EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）。不同的信任等级的机构一起形成了层级关系。

再简单说下数字签名，数字签名指将通信内容和摘要信息（下面例子中的哈希结果）通过接收方的公钥加密，和原文加密结果一起传输给接收方。接收方拿着自己的私钥解密，判断摘要结果和原文结果是否匹配，数字签名的核心目的是为了防止信息丢失、中间人篡改信息。

举例说明，客户端需要向服务器端发送一段字符串：“Hello,World”，我们首先将 "Hello,World" 通过服务器端的公钥进行加密得到结果 A，假设 "Hello,World" 通过哈希加密算法加密后的结果是 "abc123"，将 "abc123" 使用服务器端的公钥进行加密得到结果 B，两者都发送给服务器端。

服务器端收到信息后，先通过自己的私钥对 A 解密，然后再对 B 解密，通过相同的哈希算法计算得到 "Hello,World" 的哈希值，如果相同，说明数据没有被中间人篡改。

3. 小结

本章节主要介绍了 HTTPS 协议的核心流程以及数字证书的定义，HTTPS 协议相对于 HTTP 协议复杂很多，所以候选人需要抓住核心矛盾，针对非对称加密和对称加密的特点，阐述流程中每个步骤的关键作用，然后再根据个人理解补充细节。