1. 前言

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

2. HTTPS 协议

2.1 HTTPS 请求流程

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

题目解析:

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

图片描述

(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 协议复杂很多,所以候选人需要抓住核心矛盾,针对非对称加密和对称加密的特点,阐述流程中每个步骤的关键作用,然后再根据个人理解补充细节。