概述

本章，您将学习到关于 https 的相关知识。

由于涉及到的内容较多，本章节的内容被划分为三部分的文档：

• 第一部分 - https 的基础知识
• 第二部分 - 手动模拟出 SSL 证书
• 第三部分 - 在 Apache httpd 中进行配置

https 协议的诞生背景

在互联网发展的早期阶段，http 协议被人们广泛使用。但是发明 http 协议的人并没有考虑到数据传输的安全性问题，即所有使用 http 协议的数据都是明文传输，这意味着：

• 数据可以在传输过程中被篡改
• 数据可以在传输过程中被窃听（监听）
• 数据可以在传输过程中被冒充

为了解决 http 协议的明文传输问题，于是网景（NetScape）公司在 1994 年首次提出并引入了 https 协议（Hypertext Transfer Protocol Secure，安全的超文本传输协议），其目的是为了让客户端到服务器端之间的信息通过加密通道进行传输，具体实现办法是在 Web 服务器端部署 TLS/SSL 证书（常统称为 SSL 证书）。需要说明的是，https 协议并不是一个独立的新协议（很多人误以为 https 是一个全新的协议），而是在 http 协议之上叠加了一层 ‌TLS/SSL 加密层‌，从而实现安全通信。

部署 SSL/TLS 证书是现代网站的必要安全措施，主要好处有：

• 构建加密通道加密传输过程中的数据
• 身份验证，验证 Web 服务器的合法性
• 在某些国家/地区可满足网络安全与数据保护法规的要求
• SEO

证书相关内容

证书类型

在全世界的范围内，证书按照验证等级可划分为：

• DV（域名验证型）
• OV（组织验证型）
• EV（扩展验证型）

对比如下表所示：

证书品牌

SSL 证书的品牌非常多，市场上大致分为‌国际品牌‌和‌国产品牌‌两大阵营。

国际品牌常见的有：

• DigiCert
• ‌Sectigo‌
• Entrust
• ‌GlobalSign
• ‌GeoTrust
• ‌Thawte
• TrustAsia

‌国产品牌‌常见的有：

• CFCA
• iTrusChina
• SHECA
• bjca
• GDCA
• CTCA
• WoTrus
• AnTrust

证书查看

以 Google Chrome 为例，您可以在浏览器中点击网址左侧的「网站信息」---> 锁图标，即可查看到相关的证书信息：

可以看到这里的证书品牌为 ‌GlobalSign

https 的原理

https 的底层大量使用了非对称加密 + 对称加密 + 哈希算法。

关于对称加密与非对称加密的内容，请参阅前面的 《GNU/Linux 基础服务 — OpenSSH 软件套件》 文章。

1. 非对称加密

   证书的签名就是利用非对称加密实现的，另外在握手阶段，会用非对称加密完成预主密钥的 "协商" 或其他密钥材料的 "协商"，并 "派生" 出会话密钥。

2. 对称加密

   握手完成后，后续所有通信数据‌都用对称加密传输，常见算法有 AES-128、AES-256、ChaCha20 等。

3. 哈希算法

   主要用来验证数据的完整性，防止数据被篡改。另外，证书的签名验证也依赖哈希算法。

┌─────────────┐
│   握手阶段    │  非对称加密（交换密钥）+ 哈希（验证身份）
├─────────────┤
│   通信阶段    │  对称加密（加密数据）+ 哈希/HMAC（防篡改）
└─────────────┘

当使用者在浏览器中访问使用 https 协议的站点时，会发生如下交互：

1. TCP 三次握手阶段

   浏览器和服务器之间通过经典的 「三次握手」确认能够互相完成通信，之后则进入到安全协商阶段。

2. TLS/SSL 握手

   不同的 TLS 版本可能略有不同，但最核心的目标不变 —— 完成预主密钥的 "协商" 或其他密钥材料的 "协商"，并 "派生" 出会话密钥。

   以 TLS 1.2 为例：

   • Client Hello‌：浏览器先发起请求，告诉服务器自己支持的 TLS 版本、加密套件列表，并生成一个客户端随机数（这个随机数会明文发送给服务器）。
   • ‌Server Hello + 证书‌：服务器选定双方都支持的 TLS 版本和加密套件，生成服务器随机数（这个随机数会明文发送给浏览器），并把自己的数字证书发给浏览器。证书里包含了服务器的公钥和 CA 的签名。
   • 客户端验证证书‌：浏览器会严格检查证书是否由受信任的 CA 颁发、是否在有效期内、是否被吊销，还会用 CA 的公钥验证证书上的数字签名，确保证书没被篡改，从而确认服务器身份。
   • Client Key Exchange‌：验证通过后，浏览器生成一个预主密钥，用服务器公钥加密后发给服务器。只有拥有对应私钥的服务器才能解开。至此，双方完成了预主密钥的 "协商"。
   • 派生出会话密钥‌：双方此时都握有客户端随机数、服务器随机数和预主密钥，各自通过约定的算法算出同一个对称会话密钥（即所谓的派生出会话密钥）。后续的 HTTP 数据就用这个密钥加密。
   • ‌Change Cipher Spec + Finished‌：双方互发切换加密模式的信号，随后使用会话密钥加密发送 Finished 消息，以校验握手完整性。验证通过后，加密通道正式建立。

   对于预主密钥，可以使用 "交换" 或 "协商" 等词。但是对于会话密钥，通常都使用 "派生" 一词。

   在一些资料或文档中，会使用 密钥材料（keying material） 这个统称词指代最终算出会话密钥的那些原料。在上面的例子中，密钥材料就是指「两个随机数 + 预主密钥」。

3. 加密数据传输‌

   握手完成后，浏览器和服务器之间所有的 HTTP 请求和响应，均使用上述会话密钥进行对称加密传输。数据在传输过程中即使被截获，也无法被解密或篡改。

赞赏