深入理解 HTTPS 工作原理
Category（分类）: NET Protocol Status: 优
近年来，HTTPS 已经成为公网 Web 服务的主流。浏览器、搜索引擎、CA 机构、CDN 和云服务共同推动了 HTTPS 的普及，但理解 HTTPS 不能只停留在“有证书、数据被加密”这一层面。
读完本文，希望你能明白：
- HTTP 通信存在什么问题；
- HTTPS 如何改进 HTTP 的机密性、完整性和身份认证问题；
- 对称加密、非对称密码学、数字签名和证书分别解决什么问题；
- TLS 1.3 的 HTTPS 握手大致如何工作；
- HTTPS 的能力边界和部署成本是什么。
想阅读更多文章，可以参考GitHub 博客。
一、什么是 HTTPS？
HTTPS 更准确的表达是：
HTTPS = HTTP over TLS
HTTPS 不是一种完全替代 HTTP 语义的新应用协议，而是将 HTTP 消息交给 TLS 保护，再通过传输层发送。SSL 是 TLS 的前身，SSL 2.0 和 SSL 3.0 已经废弃，现代 HTTPS 主要使用 TLS 1.2 或 TLS 1.3。
对于 HTTP/1.1 和 HTTP/2，TLS 通常运行在 TCP 之上；HTTP/3 则运行在 QUIC 之上，QUIC 使用 UDP 作为底层传输。
HTTPS 主要提供：
- 机密性：防止传输中的第三方直接读取应用数据；
- 完整性：发现传输内容是否被篡改；
- 身份认证：通过证书和信任链验证服务器身份；
- 可选的客户端认证：在双向 TLS 等场景中验证客户端证书。
使用 HTTPS 时，URL 通常使用 https://，默认端口通常为 443。端口只是约定，HTTPS 也可以运行在其他端口上。
浏览器界面会根据 HTTPS 证书和连接状态显示不同的安全提示，但地址栏中的锁形图标只表示连接满足浏览器的 TLS 验证条件，不代表网站业务一定可信，也不代表客户端和服务器本身没有被入侵。
二、为什么需要 HTTPS？
HTTP 本身不提供加密、完整性保护和通信方身份认证，因此在不可信网络中可能出现以下问题。
1. 通信使用明文，内容可能被窃听
HTTP 报文通常以明文传输，网络中的攻击者、恶意 Wi-Fi、被入侵的路由设备或代理可能读取请求和响应内容，例如：
- 登录信息；
- Cookie；
- 个人资料；
- 订单和支付相关数据；
- 页面返回的业务内容。
HTTPS 通过 TLS 记录层加密保护应用数据，但 IP 地址、连接时间、流量大小等部分元数据仍可能被观察到。
2. 缺少完整性保护，报文可能被篡改
HTTP 没有为报文提供密码学完整性校验。攻击者可能在请求或响应经过网络节点时修改内容，例如替换脚本、插入广告、修改下载文件或改变请求参数。
HTTPS 使用 TLS 的 AEAD 算法和记录校验机制检测传输内容是否被篡改。这里的完整性保护不是简单地对整段 HTTP 报文做一个普通 MD5，而是由 TLS 密钥和认证加密算法共同完成。
3. 不验证通信方身份，可能遭遇伪装
HTTP 本身不会验证客户端连接的服务器是否就是用户想访问的服务器。攻击者可能伪造网站、劫持 DNS 或控制中间网络，让用户连接到恶意服务器。
HTTPS 通过 X.509 证书、CA 信任链、域名匹配和 TLS 握手签名验证服务器身份，从而降低中间人伪装风险。
HTTPS 的安全性建立在以下前提上：
- 客户端信任库没有被恶意修改；
- 证书校验没有被关闭；
- 域名、有效期和证书用途验证通过；
- 服务端私钥没有泄露；
- 客户端和服务器端点本身没有被入侵。
三、HTTPS 如何解决 HTTP 的问题？
HTTPS 的安全能力主要由 TLS 提供。可以把协议关系理解为：
HTTP 应用数据
↓
TLS 加密、完整性和握手认证
↓
TCP（HTTP/1.1、HTTP/2）或 QUIC（HTTP/3）
TLS 握手负责协商版本、密码套件和会话密钥，并认证服务器；TLS 记录层负责保护后续的应用数据。
现代 TLS 通常涉及以下密码学机制：
- 对称加密和 AEAD：高效保护大量应用数据；
- 非对称密码学：用于密钥协商、身份认证或数字签名；
- 哈希函数和 HKDF：用于摘要、握手校验和密钥派生；
- X.509 证书和 CA 签名：把服务器身份与公钥绑定。
1. 对称加密
对称加密使用同一个秘密密钥进行加密和解密。它的计算效率通常较高，适合保护大量应用数据。
问题在于：通信双方必须安全地获得同一个密钥。如果通过明文网络直接传输密钥，监听者就可能同时获得密钥和密文；如果使用另一个没有安全传输渠道的密钥加密，又会遇到新的密钥分发问题。
TLS 记录层常使用 AES-GCM 或 ChaCha20-Poly1305 等 AEAD 算法。AEAD 不仅提供机密性，还能检测密文、序列号和关联数据是否被篡改。
2. 非对称密码学
非对称密码学使用一对公钥和私钥：
- 公钥可以公开；
- 私钥必须由持有者妥善保管；
- 公钥加密、私钥解密可以用于机密性；
- 私钥签名、公钥验证用于身份认证和完整性。
非对称密码学解决了密钥分发的一部分问题，但它本身不能证明某个公钥属于目标服务器。如果攻击者把服务器公钥替换成自己的公钥，客户端仍可能使用错误的公钥加密数据。因此，公钥必须通过证书和可信任的身份验证机制进行绑定。
非对称运算通常比对称加密开销更大，所以 TLS 通常只在握手阶段使用非对称密码学，后续应用数据使用对称 AEAD 加密。
3. 混合加密和密钥协商
历史上的部分 TLS 1.2 连接可以使用 RSA 密钥交换：客户端生成 premaster secret，用服务器证书中的 RSA 公钥加密后发送，服务器用私钥解密，再由双方派生会话密钥。
但这种方式不是现代 TLS 1.3 的标准流程，而且不具备理想的前向保密性。现代 TLS 1.3 通常使用临时 ECDHE：
- 客户端和服务器交换临时公钥参数；
- 双方分别计算相同的共享秘密；
- 使用 HKDF 从共享秘密和握手上下文派生会话密钥；
- 使用会话密钥保护后续 TLS 记录。
最终的应用数据密钥通常不会直接通过服务器证书公钥传输。临时 ECDHE 还可以提供前向保密：即使服务器长期私钥日后泄露，也不能直接解密过去捕获的 TLS 1.3 1-RTT 会话数据。
四、数字签名如何保证完整性？
数字签名主要用于证明消息或证书内容确实由某个私钥持有者签署，并且签署后没有被修改。它不负责隐藏消息内容。
1. 生成数字签名
一般流程是：
- 对待签名内容计算密码学哈希摘要；
- 使用签名者的私钥生成数字签名；
- 将原文和签名一起发送。
“使用私钥加密摘要”只是早期教材中的类比。更准确的说法是“使用私钥生成签名”，因为不同签名算法的数学过程并不等同于普通加密。
2. 验证数字签名
接收者通常会：
- 使用签名算法和签名者公钥验证签名；
- 对收到的原文重新计算摘要；
- 确认签名对应的内容和公钥身份都符合预期。
数字签名能证明内容没有被修改，也能证明签名由对应私钥生成，但前提是接收者已经可信地获得了正确的公钥。如果攻击者替换公钥，签名验证就失去了身份意义，这正是数字证书和 CA 要解决的问题。
五、数字证书和 CA
数字证书认证机构（Certificate Authority，CA）是客户端和服务器都信任的第三方。CA 的作用是通过验证域名控制权或组织身份，把服务器身份、公钥和签名绑定在一起。
CA 签发证书的一般过程如下：
- 服务器运营者生成密钥对，并向 CA 提交证书申请；
- CA 验证申请者对域名的控制权，或根据证书类型验证组织身份；
- CA 生成 X.509 证书内容，包含服务器公钥、SAN、有效期、签发者、序列号和用途等字段；
- CA 对待签名证书内容计算摘要并生成数字签名；
- 客户端收到终端证书和可能的中间证书；
- 客户端根据本地信任库验证证书链和 CA 签名。
客户端通常会检查：
- 证书链是否连接到受信任的根 CA；
- 当前访问的域名是否匹配 SAN；
- 证书是否在有效期内；
- 证书用途是否包括服务器认证；
- 证书是否违反本地安全策略；
- 是否能够通过 CRL、OCSP 或其他机制获得撤销信息。
服务器证书中的签名是 CA 使用 CA 私钥生成的；服务器自己的私钥并不是 CA 的私钥。TLS 1.3 握手中，服务器还会使用自己的私钥对握手 transcript 进行 CertificateVerify 签名，以证明自己确实持有证书对应的私钥。
客户端信任的是自己的信任库，不一定包含世界上所有 CA。服务器一般发送终端证书和中间证书，根证书通常已经由操作系统、浏览器或应用预置。
六、HTTPS 工作流程
下面先介绍现代 TLS 1.3 的简化流程。真实握手还会受到会话恢复、客户端证书、代理、密码套件和协议扩展影响。
1. 连接和客户端问候
客户端先解析域名并建立 TCP 连接；如果使用 HTTP/3，则建立 QUIC 连接。随后客户端发送 ClientHello，其中通常包含：
- 支持的 TLS 版本；
- 密码套件；
- 客户端随机数；
- ECDHE 密钥交换参数；
- ALPN 等协议协商信息。
HTTPS 默认使用 443 端口，但端口本身不是安全性的来源。
2. 服务端响应和证书
服务端返回 ServerHello，选择 TLS 版本、密码套件和密钥交换参数，然后发送：
- 服务器证书链；
CertificateVerify握手签名；Finished等握手验证信息。
客户端验证证书链、SAN、有效期、证书用途，并验证服务端的握手签名。
3. 双方派生会话密钥
客户端和服务端使用各自的临时密钥参数计算相同的 ECDHE 共享秘密，再通过 HKDF 派生握手密钥和应用数据密钥。最终双方都拥有相同的 TLS 记录层密钥，但网络监听者无法仅凭捕获的握手报文计算出该密钥。
4. 加密传输 HTTP 数据
握手完成后：
- 客户端把 HTTP 请求交给 TLS 记录层加密并发送；
- 服务端解密并交给 HTTP 应用层处理；
- 服务端把 HTTP 响应交给 TLS 加密后返回；
- 客户端验证完整性并解密得到 HTTP 响应。
客户端 服务端
| -------- ClientHello -----------------> |
| <------- ServerHello + Certificate ---- |
| <------- CertificateVerify + Finished - |
| -------- Finished -------------------> |
| <====== 加密的 HTTP Application Data ======> |
5. 历史上的 TLS 1.2 RSA 密钥交换
为了理解旧资料中的“客户端生成对称密钥并用服务器公钥加密”，可以把它看成 TLS 1.2 RSA 密钥交换的简化描述：
- 客户端生成 premaster secret；
- 使用服务器证书中的 RSA 公钥加密；
- 服务器使用对应私钥解密；
- 双方从 premaster secret 派生会话密钥。
这种方式不能代表 TLS 1.3，也不应在现代文章中作为默认 HTTPS 流程。现代 TLS 1.3 使用 ECDHE 密钥协商，不直接传输最终对称密钥。
七、HTTP 与 HTTPS 的区别
- HTTP 不提供传输层加密、完整性保护和服务器身份认证；
- HTTPS 使用 TLS 保护 HTTP 通信；
- HTTP/1.1 和 HTTP/2 通常使用 TCP + TLS；
- HTTP/3 使用 QUIC + TLS；
- HTTP 默认端口通常是 80，HTTPS 默认端口通常是 443；
- HTTPS 通常需要有效证书，HTTP 不需要；
- HTTPS 可以防止传输过程中的窃听和篡改，但不能代替应用层认证和授权；
- HTTPS 不会自动解决 XSS、CSRF、SQL 注入或服务器漏洞。
HTTPS 和 HTTP 都属于应用层协议语境，不能说“HTTPS 基于传输层而 HTTP 基于应用层”。TLS 位于 HTTP 和传输层之间。
八、为什么仍然需要考虑 HTTPS 的部署成本？
现在公网网站普遍建议使用 HTTPS，且 Let's Encrypt 等机构提供免费证书，因此“证书必须购买”已经过时。仍然需要考虑的成本主要包括：
- 证书申请、续期和自动化部署；
- 多域名、通配符和证书链管理；
- 负载均衡器、CDN 和源站之间的 TLS 配置；
- 旧客户端的协议和密码套件兼容；
- 证书轮换、私钥保护和监控；
- 混合内容、重定向和 Cookie 的
Secure配置。
HTTPS 会增加一定的握手和加密计算开销，但现代系统可以通过以下方式降低影响：
- TLS 1.3；
- 会话恢复；
- TCP/TLS 连接复用；
- HTTP/2 或 HTTP/3；
- CDN 或负载均衡器进行 TLS 终止；
- CPU 硬件加速和高效的 AEAD 算法。
实际性能取决于网络延迟、连接复用、缓存、服务器实现和页面资源数量，不能简单说 HTTPS 一定比 HTTP 慢。
九、HTTPS 的安全边界
HTTPS 主要保护客户端与 TLS 终止点之间的传输过程。如果 CDN、负载均衡器或反向代理负责 TLS 终止，那么从该设备到后端是否继续使用 TLS，需要根据部署方式单独配置。
HTTPS 不能阻止：
- 服务器端已经被入侵；
- 客户端已经被恶意软件控制；
- 用户安装了攻击者控制的根证书；
- 应用自身存在 XSS、CSRF 或权限校验漏洞；
- 用户把密码主动提交给钓鱼网站。
因此，HTTPS 是 Web 安全的重要基础，但不是完整的应用安全方案。
小结
本文介绍了 HTTPS 的核心原理：
- HTTP 本身没有机密性、完整性和身份认证；
- 对称加密适合保护大量应用数据，但需要解决密钥协商；
- 非对称密码学可以用于密钥协商和数字签名，但计算成本较高；
- 数字证书把服务器身份与公钥绑定，CA 通过数字签名建立信任链；
- TLS 1.3 通常使用 ECDHE 协商共享秘密，再使用 HKDF 派生会话密钥；
- 后续 HTTP 数据使用 AES-GCM 或 ChaCha20-Poly1305 等 AEAD 算法保护；
- HTTPS 保护传输过程，但不能替代应用层认证、授权和安全编码。