HTTP 明文传输时，链路上的恶意节点可能读取或篡改内容。HTTPS 通过 TLS 为 HTTP 提供机密性、完整性和身份认证。

理解 HTTPS 不能只背“非对称加密交换对称密钥”一句话。现代 TLS 1.3 会进行版本与算法协商、临时密钥交换、证书链验证、握手签名、密钥派生和完成消息校验。

一、HTTPS 是什么

可以把 HTTPS 理解为：

1
2
3
4
5

HTTP 语义
   ↓
TLS 安全通道
   ↓
TCP（HTTP/1.1、HTTP/2 的常见承载）

HTTP/3 则运行在 QUIC 上，QUIC 集成 TLS 1.3 握手能力并通常使用 UDP 承载。

TLS 在应用与传输之间提供安全能力。不要过度纠结它“绝对属于 OSI 哪一层”，实际工程更关心它的接口和安全边界。

二、HTTP 明文有什么风险

数据从客户端到服务器可能经过：

• Wi-Fi 接入点；
• 局域网交换和路由设备；
• 运营商网络；
• 企业代理；
• 云网络与负载均衡；
• 其他中间系统。

明文 HTTP 面临：

1. 窃听：读取账号、Cookie、查询内容和页面；
2. 篡改：替换下载链接、插入广告或恶意脚本；
3. 冒充：客户端无法可靠判断对端是否是真服务器；
4. 会话劫持：窃取认证 Cookie 后冒用身份。

HTTPS 要解决的主要目标：

三、HTTPS 不能解决什么

HTTPS 不是万能安全方案。它不能自动防止：

• 服务器自身被入侵；
• 客户端恶意软件读取解密后的数据；
• SQL 注入、XSS、越权等应用漏洞；
• 用户主动忽略证书警告；
• 受信任根证书被恶意安装；
• 流量分析看到连接时间、大小、方向等元数据；
• 普通 TLS 中目的 IP，以及通常可见的传统 SNI；
• DDoS 和网络阻断。

TLS 保护的是通信通道，不替代应用安全、主机安全和访问控制。

四、密码学基本术语

4.1 明文、密文与密钥

• 明文：原始可理解数据；
• 密文：加密后的数据；
• 密钥：控制加解密算法的重要秘密或公开参数。

安全性应依赖密钥，而不是依赖攻击者不知道算法。成熟密码算法通常公开接受分析。

4.2 随机数

握手随机数、临时私钥、会话标识等必须来自密码学安全随机源。普通 rand() 不适合生成密钥。

五、对称密码

对称密码使用相同秘密或紧密相关的秘密进行加密与解密。

优点：

• 速度快；
• 适合大量应用数据；
• 硬件和软件实现成熟。

难点：

• 通信双方怎样安全获得共享秘密；
• 密钥如何轮换和隔离；
• 不能只加密而不认证数据。

现代 TLS 使用 AEAD（Authenticated Encryption with Associated Data）算法，同时提供加密与完整性认证。常见套件涉及 AES-GCM 或 ChaCha20-Poly1305。

课件中用异或演示“同一密钥加解密”只适合说明概念，简单重复异或不是安全的网络加密方案。

六、非对称密码

非对称体系包含公钥和私钥：

• 公钥可以公开；
• 私钥必须保密；
• 两者在特定算法关系下配对。

它常用于：

• 数字签名；
• 密钥协商或密钥封装；
• 身份认证。

非对称运算比对称加密昂贵，因此不会用来逐字节加密整条 HTTPS 响应。

6.1 不要把所有操作都描述为“公钥加密、私钥解密”

现代 TLS 1.3 的常见 ECDHE 是密钥协商，签名是对握手上下文签名。它们不是把任意明文当作 RSA 教科书公式来回加解密。

不同算法有不同安全定义和用途，公钥“可验证签名”不等于公钥“解密一段私钥加密的普通消息”。

七、哈希与消息认证

7.1 哈希函数

哈希函数把任意长度输入映射为固定长度摘要。安全哈希需要关注：

• 原像抗性；
• 第二原像抗性；
• 碰撞抗性。

现代协议常使用 SHA-256、SHA-384 等。MD5 已不适合数字证书签名等抗碰撞安全场景。

7.2 MAC

普通哈希不能证明消息来自持密钥者。MAC 使用共享秘密验证完整性和来源。

TLS 1.3 使用 AEAD 保护记录，并使用 HKDF 基于握手秘密与 transcript hash 派生多组密钥。

7.3 摘要不是加密

哈希通常不可逆，不用于把密文还原为明文。它的主要作用是构造摘要、校验和密钥派生材料等。

八、数字签名

签名者使用私钥对规定的消息上下文生成签名，验证者使用公钥验证。

签名提供：

• 完整性；
• 私钥持有证明；
• 在特定信任模型下的身份认证。

签名通常先对结构化消息进行哈希，再执行签名算法，原因不仅是“缩短数据”，还包括算法安全结构和协议上下文绑定。

不要把数字签名简单描述成“用私钥加密哈希，再用公钥解密”。这个比喻勉强适用于理解某些旧式 RSA 数学直觉，但不准确描述 ECDSA、EdDSA、RSA-PSS 等现代签名。

九、数字证书

证书把公钥与身份信息绑定，并由证书颁发机构（CA）签名。

常见内容：

• Subject；
• Issuer；
• 序列号；
• 有效期；
• 公钥及算法；
• Subject Alternative Name（SAN）；
• Key Usage / Extended Key Usage；
• CA 基本约束；
• CA 的数字签名。

现代浏览器校验网站身份主要看 SAN，不能只依赖旧式 Common Name。

十、证书链

典型链：

1
2
3
4
5

受信任根 CA
    ↓ 签发
中间 CA
    ↓ 签发
网站叶子证书

10.1 根证书

根证书通常预装在操作系统或浏览器信任存储中，是信任锚。根证书通常自签名，但“自签名”本身不会自动使它可信；信任来自受控分发和本地策略。

10.2 中间证书

CA 通常用中间证书签发网站证书，减少根私钥直接在线使用。服务器应发送所需中间证书，但一般不必发送客户端已经信任的根证书。

10.3 网站证书

网站证书包含服务器公钥和域名等信息，由上级 CA 签名。

十一、客户端怎样验证证书

验证至少包括：

1. 构造到本地信任锚的有效证书链；
2. 验证各级签名；
3. 检查有效期；
4. 检查访问主机名是否匹配 SAN；
5. 检查基本约束、Key Usage 和 Extended Key Usage；
6. 检查算法和密钥强度是否符合策略；
7. 按客户端策略处理撤销信息；
8. 检查关键扩展和其他验证规则。

只验证“证书签名正确”而不验证主机名，会允许其他合法网站证书被错误用于当前连接。

十二、CSR 与服务器私钥

申请证书时，服务器一方通常：

1. 生成密钥对；
2. 妥善保存私钥；
3. 生成 CSR；
4. 向 CA 证明域名或组织控制权；
5. 获得叶子证书和中间链。

CSR 含公钥与申请信息，并由对应私钥签名。CA 不应替普通网站保存其服务器私钥。

私钥泄露后，攻击者可能冒充服务端，应立即轮换密钥和证书，并按流程撤销旧证书。

十三、为什么只使用对称加密不够

如果双方事先安全共享密钥，对称加密可以保护通信。但开放互联网中浏览器与陌生网站通常没有预共享密钥。

若把对称密钥直接明文发送，中间人也能得到它；若再用另一个对称密钥加密，又回到“如何安全获得第一个共享密钥”的问题。

十四、为什么不把全部数据都用非对称算法加密

原因包括：

• 运算成本高；
• 单次可处理数据受算法结构限制；
• 不适合高速连续记录保护；
• 密钥更新和双向流量隔离需要更完整协议。

TLS 使用混合密码体系：公钥技术完成认证和密钥协商，对称 AEAD 保护大量应用数据。

十五、没有证书会发生什么

假设客户端只收到一个未经认证的服务器公钥：

1. 中间人拦截连接；
2. 把服务器公钥替换成自己的公钥；
3. 客户端与中间人协商；
4. 中间人再与真实服务器建立另一条连接；
5. 中间人可以解密、修改并重新加密两侧数据。

问题不是公钥算法被破解，而是客户端不知道收到的公钥属于谁。

证书链把公钥与域名身份绑定，并由本地信任锚验证，从而抵抗这种替换。

十六、TLS 1.3 完整握手主线

下面描述常见的服务器单向认证、ECDHE 密钥交换流程。细节会因算法、会话恢复和客户端认证而变化。

16.1 ClientHello

客户端发送：

• 支持的 TLS 版本；
• 支持的密码套件；
• 随机数；
• ECDHE key_share；
• 支持的签名算法；
• SNI 主机名；
• ALPN，例如 h2、http/1.1；
• 其他扩展。

16.2 ServerHello

服务器选择版本、密码套件和密钥交换参数，并返回自己的临时 ECDHE key_share。

双方结合各自临时私钥与对方公开参数，独立计算相同共享秘密，再通过 HKDF 派生握手密钥。

16.3 加密的握手消息

ServerHello 之后，TLS 1.3 的主要握手消息开始受到握手密钥保护。服务器发送：

• EncryptedExtensions；
• Certificate；
• CertificateVerify；
• Finished。

16.4 Certificate

服务器发送叶子证书和通常所需的中间证书。客户端验证证书链、域名、有效期、用途和算法策略。

16.5 CertificateVerify

服务器使用证书对应私钥对握手 transcript 的规定上下文签名，证明：

• 它持有证书公钥对应的私钥；
• 当前握手参数没有被替换。

16.6 Finished

Finished 基于派生密钥认证此前握手 transcript。双方验证后，能检测握手消息是否被篡改。

16.7 应用数据

双方从握手秘密继续派生方向独立的应用流量密钥，使用 AEAD 保护 HTTP 数据。

整个过程不是只产生“一把 AES 密钥”。TLS 1.3 密钥计划会派生多组、分方向、分阶段的 secret 和 key/IV。

十七、TLS 1.3 为什么具有前向保密

常见 TLS 1.3 握手使用临时 ECDHE 密钥。会话结束后临时私钥被销毁。

即使未来服务器证书私钥泄露，攻击者通常也不能仅凭历史抓包恢复过去会话的 ECDHE 共享秘密，这叫前向保密（Forward Secrecy）。

它不保护端点在会话期间被攻破、随机数生成器失效或会话密钥被直接窃取的情况。

十八、TLS 1.2 RSA 密钥交换与 TLS 1.3 的区别

旧教程常描述：

1. 客户端生成 premaster secret；
2. 用服务器 RSA 公钥加密；
3. 服务器用 RSA 私钥解密；
4. 双方派生对称密钥。

这是历史 TLS 1.2 RSA key exchange 的简化思路。它缺少前向保密，并且 TLS 1.3 已移除静态 RSA 密钥交换。

现代 TLS 1.3 中：

• ECDHE 常用于临时密钥协商；
• 证书私钥主要用于签名认证；
• 对称流量密钥由 HKDF 从握手秘密派生；
• RSA 证书仍可用于 RSA-PSS 等签名，但不是把会话密钥直接用 RSA 加密传输。

十九、密码套件

TLS 1.3 密码套件名称示例：

1
2
3

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256

TLS 1.3 套件主要指定：

• 对称 AEAD；
• HKDF 使用的哈希。

密钥交换组和签名算法通过独立扩展协商，不再全部塞进一个长套件名称中。

二十、SNI 与 ALPN

20.1 SNI

一台服务器 IP 可能托管多个域名。客户端在握手中发送 SNI，让服务器选择证书和虚拟主机。

传统 TLS 的 ClientHello 通常暴露 SNI。ECH（Encrypted ClientHello）旨在加密更多 ClientHello 信息，但部署可用性取决于客户端、DNS 和服务端支持。

20.2 ALPN

ALPN 在 TLS 握手中协商上层协议：

1
2

h2
http/1.1

这让双方在同一 443 端口选择 HTTP/2 或 HTTP/1.1。

二十一、会话恢复与 0-RTT

TLS 1.3 可以使用 PSK/会话票据恢复连接，减少握手成本。

0-RTT 允许客户端在完整握手确认前发送 early data，但存在重放风险。服务端只应对可安全重放或具备额外防重放机制的操作接受 0-RTT。

支付、创建订单、转账等非幂等操作不能因追求低延迟而直接忽略重放风险。

二十二、双向 TLS

普通 HTTPS 通常只认证服务器。mTLS 还要求客户端提供证书并证明持有对应私钥。

适合：

• 服务间调用；
• 零信任网络；
• 设备身份；
• 高安全内部系统。

mTLS 不替代业务授权。通过证书识别客户端后，仍要判断它能访问哪些资源。

二十三、证书撤销与短生命周期

私钥泄露或证书误签后，需要让客户端不再信任旧证书。常见机制：

• CRL；
• OCSP；
• OCSP Stapling；
• 浏览器和平台的专有撤销策略；
• 短生命周期证书与自动续期。

撤销检查的实际行为受浏览器、网络和策略影响，不能假设所有客户端都会同步、强制执行同一种在线检查。

二十四、HSTS

即使服务器支持 HTTPS，用户第一次输入 http:// 时仍可能遭遇降级或重定向劫持。

服务器可以发送：

1

Strict-Transport-Security: max-age=31536000; includeSubDomains

浏览器在有效期内只使用 HTTPS 访问该域名。配置 includeSubDomains 和 preload 前要确认所有子域都支持 HTTPS，否则可能造成业务不可访问。

二十五、混合内容

HTTPS 页面加载 HTTP 脚本、图片或接口称为混合内容。主动内容尤其危险，因为攻击者可篡改 HTTP 资源并控制页面逻辑。

网站应确保全部子资源、API、WebSocket 和跳转均使用安全方案。

二十六、查看证书与握手

26.1 curl

1
2

curl -v https://example.com/
curl --http2 -I https://example.com/

不要用 -k/--insecure 解决生产证书错误，它会关闭关键验证。

26.2 OpenSSL

1
2
3
4

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -showcerts

指定 TLS 1.3：

1
2
3
4

openssl s_client \
  -connect example.com:443 \
  -servername example.com \
  -tls1_3

查看证书文件：

1

openssl x509 -in certificate.pem -text -noout

检查 SAN：

1

openssl x509 -in certificate.pem -noout -ext subjectAltName

二十七、HTTPS 常见故障

27.1 证书过期

建立自动续期和到期监控，续期后确认服务已重新加载证书。

27.2 域名不匹配

访问主机名必须匹配 SAN。只有 IP 地址的访问不会自动匹配某个域名证书。

27.3 缺少中间证书

部分客户端可能因无法构建证书链而失败。服务器要配置完整的中间链。

27.4 系统时间错误

证书有效期判断依赖系统时间。客户端或服务器时钟严重错误会造成验证失败。

27.5 TLS 版本或算法不兼容

旧客户端可能不支持现代配置，旧服务器也可能只支持已淘汰协议。应在安全要求与兼容范围之间明确取舍，避免启用 SSLv3、TLS 1.0 等过时协议只为迁就极旧客户端。

27.6 反向代理配置错误

TLS 可能终止在 Nginx、负载均衡器或 CDN。还要明确：

• 代理到后端是否继续使用 TLS；
• 原始 scheme 怎样传递；
• X-Forwarded-Proto 或标准 Forwarded 字段是否只信任受控代理；
• 证书与私钥权限；
• SNI 和多域名证书配置。

二十八、HTTPS 性能

TLS 会增加握手和密码运算，但现代系统通过以下机制降低开销：

• TLS 1.3 更短握手；
• 会话恢复；
• HTTP 持久连接；
• HTTP/2 多路复用；
• CPU AES/密码指令；
• ChaCha20-Poly1305 在部分设备上的性能优势；
• 合理的证书链长度；
• 边缘节点和连接复用。

不要为了“省性能”关闭证书验证或使用过时算法。应通过测量、连接复用和正确部署优化。

二十九、常见误区

1. HTTPS 等于“HTTP 内容用 RSA 全部加密”：错误，应用数据使用对称 AEAD；
2. TLS 1.3 仍把客户端生成的 AES 密钥直接用 RSA 公钥加密：典型现代握手使用 ECDHE 和 HKDF；
3. 数字签名就是私钥加密、公钥解密：这是不准确的通用描述；
4. 有证书就安全：还必须验证证书链、域名、时间、用途与算法；
5. 自签名证书天然不安全：关键在客户端是否以受控方式信任它，但公网浏览器不会默认信任；
6. HTTPS 隐藏所有元数据：IP、流量大小、时序以及传统 SNI 等仍可能可见；
7. HTTPS 能防 XSS/SQL 注入：TLS 不修复应用漏洞；
8. MD5 仍适合证书签名：不适合现代抗碰撞安全要求；
9. 根证书自签名，所以任何自签名证书都应信任：错误，根的信任来自本地信任策略；
10. 使用 curl -k 是证书问题的长期解决方案：它会放弃身份验证。

三十、参考规范

• TLS 1.3：https://www.rfc-editor.org/rfc/rfc8446
• HTTP Semantics：https://www.rfc-editor.org/rfc/rfc9110
• X.509 PKI 证书与 CRL：https://www.rfc-editor.org/rfc/rfc5280

三十一、总结

1. HTTPS 通过 TLS 为 HTTP 提供机密性、完整性和身份认证。
2. 对称 AEAD 负责高效保护应用数据，公钥技术负责认证与密钥协商。
3. 证书把公钥和域名身份绑定，客户端必须验证完整证书链与主机名。
4. TLS 1.3 常用临时 ECDHE，证书私钥用于签名证明身份，并具有前向保密优势。
5. TLS 1.3 会从握手秘密派生多阶段、分方向的流量密钥，不只是“一把对称密钥”。
6. HTTPS 不替代应用安全、主机安全和权限控制，也不会隐藏全部连接元数据。
7. 排查 HTTPS 要同时检查 DNS、时间、证书链、SAN、SNI、ALPN、TLS 版本和代理配置。