TLS 协议机制。

核心回答

TLS 在不可信网络上建立安全通道，主要解决机密性、完整性和对端身份认证。它分成两个重点：握手阶段协商参数、认证身份并建立密钥；记录层用这些密钥保护后续应用数据。HTTPS 就是在 HTTP 通信中使用这些能力。

以常见的 TLS 1.3、证书认证、临时 ECDHE 密钥协商为例，首次完整握手可以沿四步解释：

1. 客户端发起协商：ClientHello 携带支持的版本、算法和临时密钥份额等信息。
2. 服务端选择并建立握手密钥：ServerHello 返回选定参数及服务端的密钥份额。双方利用各自的临时私钥和对方的公开份额计算共享秘密，再派生握手密钥。共享秘密不直接在网络上传输。
3. 服务端证明身份：服务端发送证书链、CertificateVerify 和 Finished 等消息。客户端验证证书链、目标服务名称、有效期等，并验证握手签名和 Finished，确认身份、握手内容及密钥是否匹配。
4. 客户端完成握手，传输应用数据：客户端发送自己的 Finished；后续按协议使用派生的应用流量密钥，以对称 AEAD 算法保护数据，兼顾加密与完整性校验。

通常只认证服务端；如果需要双向 TLS，服务端还会请求并验证客户端证书。这与网站用户登录、角色权限控制属于不同层次。

进一步解释

证书、签名、密钥协商各负责什么？

证书把公钥和服务身份绑定起来。 客户端要验证证书链能否连接到信任锚，同时确认它适用于正在访问的目标服务，不能只判断“某个 CA 签过就行”。服务名称通常根据证书的 subjectAltName 等标识匹配。

CertificateVerify 证明对方持有证书对应的私钥。 它对握手上下文作数字签名，把本次协商与身份绑定；这和 CA 在证书上的签名是两项不同的验证。复制一张公开证书，并不能冒充持有者完成正常握手。

ECDHE 建立共享秘密。 双方交换的是临时公开份额，不是把最终流量密钥明文发送给对方。证书中的认证公钥与临时密钥协商材料各有职责，不能把两者混成一个“服务器公钥”。TLS 1.3 也支持 PSK 等模式，不是所有连接都必须重新发送证书。

Finished 和记录层怎样防止篡改？

Finished 使用从密钥材料派生的密钥，对握手摘要进行验证，帮助确认协商过程和计算出的密钥一致。校验失败时，协议要求终止连接，而不是继续使用可疑参数。

应用数据使用另一阶段派生的流量密钥，发送与接收方向也有各自的密钥。TLS 1.3 记录层使用 AEAD，例如 AES-GCM、ChaCha20-Poly1305，不能简化成“明文旁边附一个普通哈希就能防篡改”。

TLS 保护的是通道及认证对端；服务端收到数据后是否允许访问某个订单，仍应由应用做授权判断。

一个中间人为什么不能换张证书就继续通信？

假设客户端访问 api.example.com。攻击者即使拿出一张自己域名下、由可信 CA 签发的证书，也不能通过目标服务名称匹配；只复制 api.example.com 的真实证书，又缺少对应私钥，无法生成正常的握手签名。

这依赖客户端真正执行证书与名称验证。关闭验证会破坏身份认证这一环，不能仅凭流量“已经加密”就判断连接到了预期服务器。

常见追问

TLS 1.3 与旧式握手相比，有什么变化？

TLS 1.3 移除了静态 RSA 密钥交换；不能沿用“客户端生成 PreMasterSecret，再用证书 RSA 公钥加密发送”来解释它。ServerHello 之后的多数握手消息使用握手密钥保护。正常无额外重试的首次握手通常为 1-RTT，这不包含底层 TCP 建连时间。

会话恢复可复用先前建立的材料，并可能使用 0-RTT 早期数据。但 0-RTT 没有协议内建的完整重放保护，需要结合服务端防重放和业务语义决定是否启用，不能把扣款等有副作用操作直接当作安全的早期数据。

TLS 握手就是 HTTPS 完整建连流程吗？

不是。常见 HTTP/1.1、HTTP/2 场景还涉及域名解析、TCP 建连和应用协议协商等环节。HTTP/3 则使用集成 TLS 1.3 的 QUIC，不能固定套成“所有 HTTPS 都先建 TCP，再跑 TLS”。

参考资料