HTTPS学习笔记

前言

HTTPS 不是新协议，而是 HTTP 下面加了一层 TLS（Transport Layer Security），用来在传输层提供加密、完整性校验和身份认证。理解 HTTPS 需要先了解对称加密、非对称加密的作用，以及 HTTP 在裸奔时的三大风险。

HTTP 的三大风险

明文传输的 HTTP 在网络中完全暴露：

1. 窃听风险：第三方可截获请求与响应内容（密码、Cookie 全部裸奔）
2. 篡改风险：第三方可修改传输内容，且接收方无从察觉
3. 冒充风险：第三方可冒充服务器或客户端发起通信

HTTPS 通过”加密 + 摘要 + 数字证书”三项技术同时解决这三个问题，对应密码学三要素：

加密基础

对称加密

加解密使用同一把密钥，常见算法有 AES、ChaCha20。

优点：算法公开、计算量小、加密速度快、适合加密大量数据。

缺点：

• 通信双方必须持有相同密钥，密钥在网络上传输时可能被截获
• N 个用户两两通信需要 N(N-1)/2 把密钥，分布式系统下密钥管理是灾难
• 没有身份认证能力

非对称加密

加解密使用一对密钥：公钥公开，私钥保密。公钥加密的数据只能由对应私钥解密，反之亦然。常见算法有 RSA、ECDSA、Ed25519。

优点：

• 公钥可公开分发，私钥无需在网络上传输
• 可结合数字签名实现身份认证

缺点：计算量比对称加密大 2~3 个数量级，不适合加密大量数据。

混合加密：HTTPS 的核心思路

对称加密快但密钥难传，非对称加密安全但慢。HTTPS 把两者结合：

1. 用非对称加密安全地传递一个临时对称密钥
2. 用这个对称密钥加密后续所有应用数据

这就是”握手 + 加密通信”两阶段的由来。

TLS 握手：HTTPS 的核心

TLS 握手的目的是：双方在不安全网络上协商出一组只有自己知道的密钥，并验证服务器身份（可选验证客户端）。握手完成后才进入加密通信阶段。

TLS 1.2 握手（2-RTT）

1
2
3
4
5
6
7
8
9
10
11
12
13

客户端                                          服务器
  |--- ClientHello --------------------------->|  支持的 TLS 版本、密码套件、客户端随机数
  |<-- ServerHello ---------------------------|  选定的版本和套件、服务器随机数
  |<-- Certificate ---------------------------|  服务器证书链
  |<-- ServerKeyExchange ---------------------|  ECDHE 临时公钥
  |<-- ServerHelloDone -----------------------|
  |--- ClientKeyExchange -------------------->|  客户端 ECDHE 临时公钥
  |--- ChangeCipherSpec --------------------->|  切换为加密通道
  |--- Finished ---------------------------->|  握手摘要（加密）
  |<-- ChangeCipherSpec ----------------------|
  |<-- Finished -----------------------------|
  |                                            |
  |<=========== 应用数据 (对称加密) ==========>|

TLS 1.3 握手（1-RTT）

TLS 1.3（RFC 8446，2018 年发布）大幅简化了握手：

1
2
3
4
5
6
7
8

客户端                                          服务器
  |--- ClientHello + KeyShare --------------->|  已包含客户端 ECDHE 临时公钥
  |<-- ServerHello + KeyShare ----------------|  包含服务器 ECDHE 临时公钥
  |<-- Certificate + CertificateVerify -------|  服务器证书及所有权证明
  |<-- Finished -----------------------------|  握手摘要（加密）
  |--- Finished + HTTP 请求 ---------------->|  立即发送应用数据
  |                                            |
  |<=========== 应用数据 (对称加密) ==========>|

主要改进：

• 强制 ECDHE：废弃 RSA 密钥交换，所有连接天然支持前向保密
• 密码套件精简：从 37 个砍到 5 个，去掉所有已知有漏洞的算法（如 CBC 模式、RC4、SHA-1）
• 握手提速：从 2-RTT 降到 1-RTT，重连可降至 0-RTT

ECDHE 与前向保密

为什么不再用 RSA 密钥交换

TLS 1.2 早期允许用 RSA 加密 pre-master secret 来协商密钥：客户端用服务器公钥加密一段随机数发给服务器，服务器用私钥解密。问题是——服务器私钥一旦未来泄露，攻击者可解密所有历史流量（”记录未来解密”）。

ECDHE 工作原理

ECDHE（Elliptic Curve Diffie-Hellman Ephemeral）每次握手都生成临时密钥对：

1. 客户端生成临时 ECDH 密钥对 (c_priv, c_pub)，把 c_pub 发给服务器
2. 服务器生成临时 ECDH 密钥对 (s_priv, s_pub)，把 s_pub 发给客户端
3. 双方各自用”自己的私钥 + 对方的公钥”算出相同的共享密钥：
   client: shared = ECDH(c_priv, s_pub)
server: shared = ECDH(s_priv, c_pub)
4. 共享密钥作为种子派生出对称加密密钥
5. 临时私钥在握手后立即销毁

前向保密（Forward Secrecy）：即使服务器长期私钥泄露，攻击者也无法解密历史流量——因为临时私钥早已消失，无法重建过去的共享密钥。

证书与 CA

证书里有什么

服务器证书（X.509）包含：

• 服务器公钥
• 域名（Subject Alternative Name）
• 颁发机构（Issuer）
• 有效期
• CA 用私钥对证书内容做的数字签名

证书链验证

浏览器不只验证服务器证书本身，而是验证整条信任链：

1
2
3
4
5
6
7
8
9

根 CA 证书（内置于操作系统/浏览器受信任列表）
    │
    │ 签名
    ▼
中间 CA 证书（可灵活撤销和替换）
    │
    │ 签名
    ▼
服务器证书

验证流程：

1. 服务器证书的签名是否由中间 CA 的私钥签发
2. 中间 CA 证书的签名是否由根 CA 的私钥签发
3. 根 CA 证书是否在受信任根证书列表中
4. 证书是否在有效期内
5. 域名是否匹配请求的域名
6. 是否被吊销（CRL 或 OCSP）

数字签名的原理

数字签名 = 用私钥对”证书内容的哈希”加密。

验证时：

1. 用 CA 公钥解密签名，得到哈希 H1
2. 自己计算证书内容的哈希 H2
3. H1 == H2 则证书未被篡改

任何对证书内容的修改都会导致哈希值变化，签名验证失败。

中间人攻击（MITM）

攻击原理

攻击者位于客户端与服务器之间，拦截并转发所有流量：

1

客户端  <----->  攻击者  <----->  真实服务器

没有 HTTPS 时，攻击者可读取、修改、转发一切内容。

HTTPS 如何防御

CA 体系保证客户端能验证”和我通信的就是证书里那个服务器”。攻击者无法获取合法服务器的私钥，也就无法伪造带有效签名的证书——浏览器直接弹警告并中断连接。

HTTPS 仍可能失效的场景

虽然 CA 体系是 HTTPS 安全的基石，但以下情况会让中间人攻击得逞：

1. 用户忽略证书警告：自签证书、域名不匹配时仍点”继续访问”
2. CA 被入侵：历史上 DigiNotar（2011）、Symantec（2015-2017）都发生过 CA 违规事件
3. 客户端被植入根证书：公司内网代理、部分国产浏览器会预装自己的根证书，形成”合法 MITM”
4. 服务器私钥泄露：配置不当、心脏滴血漏洞（Heartbleed, 2014）都曾导致大规模私钥泄露
5. SSL Stripping：攻击者把 HTTPS 降级为 HTTP（HSTS 头可缓解）
6. 协议降级：强制使用弱套件（TLS 1.3 通过强制最低版本号缓解）

所以 HTTPS 解决了绝大部分风险，但不是绝对安全——它的安全建立在”客户端信任的根 CA 列表”这一信任锚之上。

HTTP 与 HTTPS 对比

HTTPS 的缺点

1. 握手开销：TLS 1.2 比 HTTP 多 2-RTT；TLS 1.3 已降到 1-RTT，重连可 0-RTT。会话复用（Session Ticket / PSK）可进一步减少开销。
2. CPU 成本：加解密消耗 CPU，高并发服务需要硬件加速（AES-NI）或专用网卡。
3. 证书成本与运维：虽然 Let’s Encrypt 已免费提供 DV 证书，但申请、续期、部署、私钥管理仍是运维负担。
4. 信任锚并非绝对安全：如上节所述，CA 体系本身有被攻破的风险。
5. HTTPS 不等于安全：HTTPS 只保护传输层，应用层漏洞（SQL 注入、XSS、CSRF）依然存在。

总结

HTTPS 通过非对称加密协商密钥 + 对称加密传输数据 + CA 证书验证身份的三层组合，提供了密码学意义上的机密性、完整性和身份认证。TLS 1.3 的普及让 HTTPS 在性能上已接近 HTTP（1-RTT 握手 + 会话复用），是当前 Web 通信的事实标准。

需要注意的是，HTTPS 的安全性建立在”客户端信任的根 CA 列表”这个信任锚之上——技术上是相对安全，信任模型上则是社会工程问题。理解了这一点，才算真正理解了 HTTPS。