分分钟让你理解 HTTPS

Category（分类）: NET Protocol
Status: 未知

本文尽量保留原文的“信鸽”比喻，并补充 HTTPS、TLS 握手、证书验证、对称加密和非对称密码学之间的关系。

版本说明： SSL 2.0、SSL 3.0 已经废弃，TLS 1.0 和 TLS 1.1 也不再推荐使用。现代 HTTPS 通常使用 TLS 1.2 或 TLS 1.3，其中 TLS 1.3 是更优先的选择。

一、HTTP 存在的问题

1.1 可能被窃听

1. HTTP 本身不提供加密功能，HTTP 报文通常以明文形式传输；
2. 互联网由许多网络设备和链路组成，数据经过的网络设备、无线网络或被入侵的中间节点，都可能成为窃听位置；
3. 即使通信双方使用了账号密码，只要传输过程没有加密，攻击者仍可能直接看到请求内容。

例如，使用 Wireshark 等抓包工具，在没有加密的网络中可能看到 HTTP 请求的 URL、请求头、Cookie 和请求正文。

1.2 身份认证问题

单纯使用 HTTP 时，客户端无法仅凭 HTTP 协议确认：

1. 当前连接的服务器是否真的是目标网站，而不是被劫持或伪装的服务器；
2. 收到的响应是否确实来自目标服务器；
3. 对方是否拥有访问某项业务的权限。

这里需要区分两个概念：

• 服务器身份认证：通常由 TLS 证书完成，证明当前连接的服务器拥有某个域名对应的私钥；
• 业务权限认证：由应用层的登录、Token、Cookie、RBAC 等机制完成，HTTPS 不会自动决定用户是否有权限。

HTTPS 也不能单独阻止 DoS（Denial of Service，拒绝服务）攻击。限流、WAF、验证码、负载均衡和流量清洗等措施，仍然需要在 TLS 之外配置。

1.3 可能被篡改

请求或响应在传输途中被攻击者拦截并修改，属于中间人攻击（Man-in-the-Middle attack，MITM）的一种表现。

如果没有完整性保护，客户端可能收到被篡改的页面，或者客户端提交给服务器的数据在途中被替换。仅仅“加密”还不够，还需要能够检测数据是否被修改。

二、HTTPS 介绍

2.1 什么是 HTTPS

HTTPS（Hypertext Transfer Protocol Secure）通常可以理解为 HTTP over TLS：HTTP 负责应用层的请求和响应格式，TLS 负责在通信双方之间建立安全通道。

HTTPS 的主要目标是：

• 对传输内容保密，降低窃听风险；
• 对传输内容提供完整性保护，发现中途篡改；
• 通过证书验证服务器身份，降低中间人攻击风险。

HTTPS 不是一种新的 HTTP 消息格式，也不是一种独立的传输层协议。常见情况下，HTTP/1.1 和 HTTP/2 运行在 TCP 连接之上的 TLS 通道中；HTTP/3 则运行在 QUIC 之上，QUIC 内部使用 TLS 1.3 完成加密握手。

2.2 HTTPS 如何解决上述问题

HTTPS 在 HTTP 和底层传输之间加入 TLS（Transport Layer Security，传输层安全协议）。TLS 在两个应用程序之间建立安全连接，对应用数据进行加密，并验证通信对端的身份。

一次 HTTPS 请求通常可以抽象为：

客户端与服务器建立底层连接
        ↓
TLS 握手：协商版本、算法，验证证书，生成会话密钥
        ↓
客户端发送加密的 HTTP 请求
        ↓
服务器返回加密的 HTTP 响应

TLS 建立的安全性主要包括：

1. 机密性：旁观者不能直接读取 HTTP 内容；
2. 完整性：接收方可以发现密文是否被修改；
3. 服务器认证：客户端可以验证服务器证书中的域名和公钥关系；
4. 前向保密：使用临时密钥交换时，即使服务器长期私钥以后泄露，通常也无法解密过去已经抓取的会话。

注意，HTTPS 保护的是客户端与 TLS 终止点之间的链路。如果 TLS 在反向代理或负载均衡器处终止，那么从代理到后端服务器是否继续使用加密，需要由系统架构另外决定。

2.3 SSL 和 TLS 的关系

SSL（Secure Sockets Layer，安全套接层）是 TLS 的前身，二者都是为网络通信提供加密和完整性保护的协议。

历史关系可以简单概括为：

1. Netscape 设计了 SSL；SSL 1.0 没有公开发布，SSL 2.0 和 SSL 3.0 曾经被实际使用；
2. IETF 以 SSL 3.0 为基础制定了 TLS 1.0，TLS 1.0 于 1999 年发布；
3. TLS 1.2 于 2008 年发布，定义在 RFC 5246 中；
4. TLS 1.3 于 2018 年发布，定义在 RFC 8446 中，简化了握手流程并移除了许多不安全的旧算法。

SSL 2.0、SSL 3.0 已经废弃，TLS 1.0 和 TLS 1.1 也已经被正式弃用。代码、配置和文章中仍然出现“SSL 证书”这种说法时，通常只是历史称呼，实际应当使用 TLS。

三、TLS/SSL 使用了哪些密码学技术

HTTPS 的安全性主要依赖 TLS。TLS 并不是只使用一种“加密算法”，而是组合使用了多种密码学技术：

3.1 对称加密

对称加密使用同一个密钥进行加密和解密，速度快，适合加密大量 HTTP 数据。

现代 TLS 通常使用带认证的对称加密（AEAD），例如：

• AES-GCM；
• ChaCha20-Poly1305。

AEAD 不仅提供机密性，还通过认证标签检测密文是否被篡改。因此，不能简单地说“先用对称加密，再单独用普通哈希校验”就是现代 TLS 的完整工作方式。

3.2 非对称密码和数字签名

非对称密码使用公钥和私钥：

• 公钥可以公开分发；
• 私钥必须由所有者严格保管；
• 数字签名使用私钥生成，其他人可以使用公钥验证。

在现代 TLS 中，服务器证书中的公钥主要用于验证服务器的数字签名，而不是直接加密所有 HTTP 数据。直接使用非对称加密处理大量数据速度较慢，因此实际数据仍然使用对称加密。

3.3 密钥交换

TLS 1.3 通常使用 ECDHE（椭圆曲线 Diffie-Hellman 临时密钥交换）协商共享秘密。双方交换临时公钥，各自使用自己的临时私钥计算出相同的共享秘密，旁观者无法仅凭双方的公钥计算出该秘密。

ECDHE 的另一个重要作用是提供前向保密：每次连接使用临时密钥，即使服务器长期身份私钥以后泄露，也不应直接导致历史会话被解密。

3.4 哈希和密钥派生

哈希函数用于计算握手消息摘要、构造签名输入和派生密钥。TLS 1.3 使用 HKDF 从共享秘密中派生出不同用途的会话密钥。

因此，更准确的概括是：

证书和数字签名：验证身份
密钥交换：协商共享秘密
哈希和 HKDF：计算摘要、派生密钥
AEAD 对称加密：保护实际应用数据

四、HTTPS 的 TLS 握手过程

4.1 TLS 1.3 的简化流程

以常见的 TLS 1.3 为例，握手可以抽象为：

1. 客户端发送 ClientHello，包含支持的 TLS 版本、密码套件、随机数、密钥共享参数，并通常携带 SNI 和 ALPN；
2. 服务端发送 ServerHello，选择协议版本、密码套件和密钥共享参数；
3. 服务端发送证书链、CertificateVerify 和 Finished；
4. 客户端验证证书、验证服务端签名，并计算共享秘密；
5. 客户端发送自己的 Finished；
6. 双方根据握手结果派生会话密钥，之后的 HTTP 数据使用 AEAD 对称加密传输。

TLS 1.3 中，ServerHello 之后的许多握手消息已经受到加密保护。TLS 1.2 的握手消息和字段不同，不能把 TLS 1.3 的完整流程原样套到 TLS 1.2 上。

4.2 证书验证过程

客户端收到服务器证书后，通常会检查：

1. 证书的域名是否匹配当前访问的主机名；
2. 证书是否在有效期内；
3. 证书签发者是否能通过本地信任库中的根证书建立可信链；
4. 证书签名是否有效；
5. 证书用途是否允许用于服务器身份认证；
6. 证书是否被浏览器或系统标记为不可信。

证书的核心作用是把“域名”与“公钥”绑定起来。认证机构（CA）并不是替网站加密数据，而是对这层绑定关系进行签名。

如果证书校验失败，浏览器通常会显示安全警告。直接忽略证书警告，会使用户重新暴露在中间人攻击风险中。

4.3 SNI、ALPN 和证书

在一台服务器托管多个 HTTPS 域名时，客户端通常会通过 SNI（Server Name Indication）告诉服务端希望访问的域名，服务端据此选择正确的证书。

ALPN（Application-Layer Protocol Negotiation）用于协商上层协议，例如：

h2    -> HTTP/2
http/1.1 -> HTTP/1.1

这些字段属于 TLS 握手或其扩展，并不是 HTTP 请求正文的一部分。

五、用信鸽来解释 HTTPS

密码学比较抽象，可以把网络通信想象成爱丽丝、鲍勃和马洛里之间通过信鸽传递消息：

• 爱丽丝：客户端；
• 鲍勃：服务器；
• 马洛里：中间人攻击者；
• 泰德：认证机构 CA。

这些角色只是为了帮助理解协议流程，实际可能对应浏览器、服务器、代理程序或其他自动化程序。

5.1 初步交流：明文 HTTP

如果爱丽丝想给鲍勃发送信息，她把信息绑在信鸽腿上，然后送往鲍勃。鲍勃可以正常收到并阅读信息。

但如果马洛里拦截了信鸽，她既可以阅读信息，也可能在转发之前篡改信息。鲍勃没有办法仅凭这封明文信件判断它是否被修改。

这就是没有 TLS 保护的 HTTP 通信：请求和响应可能被窃听，也可能被篡改。因此，银行、支付和登录等敏感业务不应只使用明文 HTTP。

5.2 隐蔽的密码：对称加密

如果爱丽丝和鲍勃事先共享一个秘密密码，他们可以用这个密码加密和解密消息。

原文使用了凯撒密码作为示例：把每个字母向后移动三位：

secret message -> pbzobq jbppxdb

知道密钥的人可以反向还原消息。由于加密和解密使用同一个密钥，这属于对称加密。

不过，凯撒密码只是帮助理解“共享密钥”的教学例子，实际不安全，不能用于保护真实通信。并且，仅仅加密不一定能阻止篡改，现代协议还需要认证标签或数字签名来验证完整性和来源。

5.3 如何安全地协商密钥

问题在于，爱丽丝和鲍勃如果此前没有安全地见过面，就没有一个简单的安全渠道来约定对称密钥。

如果他们把密钥直接写在信中，马洛里可以同时截获密钥和后续通信。马洛里甚至可以在双方通信时分别伪装成爱丽丝和鲍勃，建立两条独立的通信链路，这就是典型的中间人攻击。

因此，除了协商共享秘密，还必须验证对方身份。只交换公钥并不能自动防止中间人攻击，因为马洛里也可以发送自己的公钥。

5.4 通过信鸽传递带锁的盒子：公钥密码

可以把公钥密码想象成一个带有公开锁的盒子：

1. 鲍勃公开一个任何人都能使用的锁，也就是公钥；
2. 爱丽丝用这个公开锁把消息锁进盒子；
3. 只有持有对应私钥的鲍勃，才能打开盒子；
4. 旁观者即使拿到公钥，也不能直接打开已经锁住的盒子。

这里的盒子是对公钥加密的类比，公钥用于加密，私钥用于解密。对于数字签名，方向相反：持有私钥的一方签名，其他人使用公钥验证签名。

需要注意，真实 TLS 1.3 主要通过 ECDHE 协商共享秘密，而不是用服务器公钥直接加密全部 HTTP 数据。公钥密码学主要用于身份认证和密钥协商，对称加密则负责高效保护后续数据。

5.5 如何信任公钥：证书和 CA

即使公钥密码能够保护盒子，鲍勃仍然需要确认：收到的公钥确实属于爱丽丝，而不是马洛里伪造的公钥。

TLS 使用数字证书解决这个问题。证书中包含域名、公钥、有效期、用途等信息，并由认证机构 CA 签名。浏览器和操作系统预先内置了一批受信任的根证书，因此可以验证：

网站证书
    ↓ 由中间 CA 签发
中间 CA 证书
    ↓ 由根 CA 签发或锚定
浏览器/操作系统信任的根证书

CA 的作用是验证并签名“域名与公钥之间的绑定关系”，不是替网站保管私钥，也不是保证网站业务内容一定可信。

浏览器信任一个网站证书，需要同时检查域名、有效期、证书链、签名和用途等条件。只有这些检查通过后，客户端才会信任该站点的 TLS 身份。

对于需要客户端身份认证的场景，还可以使用双向 TLS（mTLS）：服务器也要求客户端提供证书，从而对客户端进行证书级认证。但普通 HTTPS 通常只默认认证服务器，用户登录和业务权限仍由应用层负责。

5.6 沉重的盒子：混合加密

非对称密码运算通常比对称加密慢，不适合直接加密大量网页内容。因此 HTTPS 采用混合加密的思路：

1. 使用证书和数字签名验证服务器身份；
2. 使用 ECDHE 等密钥交换算法协商共享秘密；
3. 使用共享秘密派生出对称会话密钥；
4. 使用 AES-GCM 或 ChaCha20-Poly1305 加密后续 HTTP 数据。

这样就兼具了两类密码学技术的优点：

• 非对称密码和证书：解决身份认证和密钥协商问题；
• 对称加密：高效保护大量数据；
• AEAD 认证标签：同时检测数据完整性。

六、HTTPS 不负责解决什么问题

理解 HTTPS 的边界同样重要：

1. HTTPS 不能保证服务器业务逻辑没有漏洞；
2. HTTPS 不能自动完成用户登录和权限控制；
3. HTTPS 不能阻止服务器端或客户端遭受 DoS 攻击；
4. HTTPS 不能防止终端设备被恶意软件读取明文；
5. HTTPS 不能隐藏所有元数据，IP 地址、连接时间、流量大小等信息在某些场景下仍可能被观察；
6. 如果 TLS 在代理处终止，代理之后的链路是否加密需要单独配置。

因此，HTTPS 是 Web 安全的重要基础，但不是完整的 Web 安全方案。

七、常见误区

7.1 “HTTPS 就是非对称加密”

不准确。HTTPS/TLS 是多个协议和算法的组合。通常使用非对称密码或数字签名完成身份认证和密钥协商，再使用对称 AEAD 算法加密应用数据。

7.2 “有证书就绝对安全”

不准确。证书只证明某个域名和公钥之间的绑定关系，并不保证网站业务可信，也不代表用户拥有访问权限。证书还必须通过域名、有效期、信任链和用途等校验。

7.3 “加密后就不能被篡改”

不准确。需要使用带认证的加密方式或额外的完整性保护。现代 TLS 使用 AEAD 认证标签检测篡改，篡改后的密文通常会被丢弃。

7.4 “RSA 可以保护所有 HTTPS 数据”

这是旧式 TLS 的常见理解。现代 TLS 1.3 不使用 RSA 密钥交换，而是优先使用临时 Diffie-Hellman 密钥交换；RSA 等算法仍可能用于数字签名，但不负责直接加密所有应用数据。

八、小结

HTTPS 可以理解为：

HTTP + TLS = HTTPS

其中：

• HTTP 负责请求和响应的业务格式；
• TLS 负责加密、完整性保护和服务器身份认证；
• 证书把域名与服务器公钥绑定起来；
• ECDHE 等算法协商会话秘密；
• AES-GCM、ChaCha20-Poly1305 等 AEAD 算法保护实际 HTTP 数据；
• 应用层仍然需要负责登录、授权、限流和业务安全。

当你访问一个 HTTPS 网站时，浏览器并不是简单地“把 HTTP 加密一下”，而是在验证服务器身份、协商会话密钥并建立安全记录层之后，才开始传输加密的 HTTP 请求和响应。

相关资料：

1. RFC 8446：The Transport Layer Security (TLS) Protocol Version 1.3
2. RFC 5246：The Transport Layer Security (TLS) Protocol Version 1.2
3. RFC 6176：Prohibiting Secure Sockets Layer (SSL) Version 2.0
4. RFC 7568：Deprecating Secure Sockets Layer Version 3.0
5. RFC 8996：Deprecating TLS 1.0 and TLS 1.1
6. MDN：HTTPS