HTTPS 与 TLS 握手
面试回答： HTTPS 是运行在 TLS 安全通道之上的 HTTP，主要提供机密性、完整性和服务器身份认证。以 TLS 1.3 的完整握手为例，客户端在 ClientHello 中发送支持的版本、加密套件和 ECDHE 密钥参数；服务器选择参数并返回自己的密钥参数、证书和握手签名。客户端验证证书链、域名、有效期和签名后，双方基于 ECDHE 共享秘密派生会话密钥，并用 Finished 消息确认握手未被篡改。后续 HTTP 数据使用高效的对称认证加密传输。证书私钥主要用于证明服务器身份，不直接加密所有业务数据。
1. HTTP 为什么需要 TLS？
明文 HTTP 无法解决三个核心问题：
| 风险 | 可能发生的事情 | TLS 提供的能力 |
|---|---|---|
| 窃听 | 中间人读取账号、请求参数和响应内容 | 机密性 |
| 篡改 | 数据在传输途中被修改 | 完整性 |
| 冒充 | 客户端连接到伪造服务器 | 身份认证 |
HTTPS 可以理解为：
TLS 保护的是客户端与服务器之间的传输链路。它不能修复服务器漏洞、前端 XSS、弱密码或用户终端被控制等问题。
2. TLS 组合了哪些密码学能力？
TLS 不是只使用某一种“加密算法”，而是组合多类能力完成不同任务。
数字证书与数字签名
服务器证书把域名、公钥、有效期、颁发者等信息绑定在一起，并由证书颁发机构（CA）签名。
服务器在握手中使用证书对应的私钥签名握手信息，证明自己确实持有该私钥。客户端使用证书中的公钥验证签名。
非对称密钥交换
现代 TLS 通常使用 ECDHE 完成密钥交换。客户端和服务器各自生成临时密钥参数，交换公开部分后，可以独立计算出相同的共享秘密，而旁观者无法仅凭公开参数得到它。
对称认证加密
握手完成后，HTTP 请求和响应使用从共享秘密派生出的会话密钥进行对称认证加密，例如 AES-GCM 或 ChaCha20-Poly1305。
对称加密适合大量数据传输；认证标签还能检测密文是否被篡改。实际连接不会用证书私钥逐段加密所有 HTTP 数据。
3. 浏览器如何验证服务器证书？
收到服务器证书后，浏览器至少需要检查：
- 证书链：服务器证书能否沿中间 CA 追溯到本地信任的根 CA。
- 签名：证书内容是否通过颁发者的数字签名校验。
- 有效期：当前时间是否位于证书有效期内。
- 域名：访问域名是否与证书的 Subject Alternative Name 匹配。
- 用途与策略：证书是否允许用于服务器身份认证，以及是否满足浏览器的安全策略。
证书链解决的是“这个公钥是否被可信体系授权给当前域名”。服务器随后还要在握手中证明自己持有对应私钥，否则复制一张公开证书并不能冒充服务器。
4. TLS 1.3 完整握手流程
下面以首次连接、需要服务器证书认证的典型 TLS 1.3 握手为例。
第一步：ClientHello
客户端发送：
- 支持的 TLS 版本；
- 支持的加密套件；
- 客户端随机数；
- ECDHE 公共参数（
key_share）； - 目标域名、应用层协议等扩展信息。
第二步：ServerHello
服务器选择 TLS 版本和加密套件，返回服务器随机数与自己的 ECDHE 公共参数。
此时双方可以分别计算出相同的 ECDHE 共享秘密，并从共享秘密和握手上下文派生出握手阶段使用的密钥。后续大部分握手消息已经受到加密保护。
第三步：服务器证明身份
服务器继续发送：
EncryptedExtensions：协商后的扩展参数；Certificate：服务器证书链；CertificateVerify：使用证书私钥对握手上下文签名；Finished：对当前握手记录计算验证数据。
客户端验证证书链和 CertificateVerify，确认服务器身份；再验证 Finished，确认此前的握手消息没有被篡改。
第四步：客户端完成握手
客户端返回自己的 Finished。双方完成验证后，派生应用数据密钥，开始传输加密的 HTTP 请求和响应。
完整的 TLS 1.3 握手通常需要 1-RTT 才能发送受保护的应用数据，相比传统 TLS 1.2 完整握手减少了一次往返。
5. TLS 1.2 的 RSA 握手为什么仍会被问？
经典面试资料经常描述下面的流程：
- 客户端和服务器交换随机数。
- 服务器发送包含 RSA 公钥的证书。
- 客户端生成 Pre-Master Secret，并用服务器 RSA 公钥加密。
- 服务器用私钥解密，双方据此派生会话密钥。
这是 TLS 1.2 及更早版本中的 RSA 密钥交换模型，适合帮助理解“非对称密码解决密钥传递、对称密码负责业务数据”的分工，但不能直接当作现代 TLS 1.3 的握手流程。
TLS 1.2 也可以使用 ECDHE。使用 ECDHE 时，证书私钥主要用于签名临时密钥参数，而不是解密客户端发送的 Pre-Master Secret。
6. TLS 1.2 与 TLS 1.3 的关键区别
| 对比项 | TLS 1.2 | TLS 1.3 |
|---|---|---|
| 完整握手往返 | 通常 2-RTT | 通常 1-RTT |
| 密钥交换 | 可能使用 RSA，也可以使用 ECDHE | 移除静态 RSA 密钥交换，使用具备前向安全性的临时密钥交换 |
| 加密套件 | 组合项较多，包含一批旧算法 | 套件简化，只保留现代 AEAD 算法 |
| 握手加密 | 较多握手消息明文传输 | ServerHello 之后的大部分握手消息加密 |
| 会话恢复 | Session ID / Session Ticket | PSK 恢复，可选择 0-RTT Early Data |
TLS 1.3 移除了 RC4、3DES、静态 RSA 密钥交换等旧机制，也减少了错误组合算法的空间。
7. 为什么 ECDHE 能提供前向安全性？
ECDHE 使用每次握手临时生成的密钥参数。会话结束后，即使服务器证书私钥在未来泄露，攻击者也不能仅凭过去抓取的握手和密文还原当时的共享秘密。
相反，在旧式 RSA 密钥交换中，如果攻击者保存了历史流量，之后又获得服务器私钥，就可能解密当时传输的 Pre-Master Secret，进而恢复历史会话密钥。
8. 会话恢复与 0-RTT
首次完整握手后，服务器可以向客户端提供会话恢复信息。再次连接时，双方基于预共享密钥（PSK）减少握手成本。
TLS 1.3 的 0-RTT Early Data 允许客户端在握手完全结束前发送部分应用数据，但这些早期数据存在重放风险。因此，登录、支付、创建订单等非幂等操作不应该在没有额外防重放设计时使用 0-RTT。
0-RTT 是会话恢复的可选优化，不代表普通 TLS 1.3 首次握手不需要往返。
9. HTTPS 能保护和不能保护什么？
加密通道可以保护：
- HTTP 方法、路径、查询参数、请求头和请求体；
- 响应头和响应体；
- Cookie 在传输链路中的内容；
- 数据是否在链路中被修改。
连接仍可能暴露部分元数据，例如目标 IP、连接时间、流量大小，以及在未使用相应隐私机制时暴露的 DNS 查询或服务器名称信息。
HTTPS 也不代表网站业务一定可信。证书主要证明客户端正在与证书授权的域名通信，并不替网站的业务内容和安全质量背书。
10. 高频追问
为什么不一直使用非对称加密？
非对称密码适合身份认证和密钥协商，但计算成本高，也不适合直接处理大量应用数据。TLS 用它建立信任和共享秘密，再使用高效的对称认证加密保护业务数据。
CA 为什么值得信任？
操作系统或浏览器预置受信任的根证书。服务器证书需要通过中间 CA 构成一条可验证的证书链。这个体系并非绝对不会出错，因此浏览器还会结合证书透明度、安全策略和证书吊销等机制降低风险。
中间人替换自己的证书可以吗？
攻击者可以发送任意证书，但如果它不能构成受信任的证书链、域名不匹配，或者攻击者无法证明持有对应私钥，浏览器就会中止连接或显示证书警告。
HTTPS 会隐藏访问的域名吗？
不一定完全隐藏。目标 IP 本身对网络路径可见，传统 DNS 和 TLS 中的服务器名称也可能暴露域名。DoH、DoT、ECH 等机制分别尝试保护不同环节，但不能简单概括成“有 HTTPS 就看不到访问了哪个站点”。
11. 总结
- HTTPS 是 HTTP over TLS，提供机密性、完整性和身份认证。
- 证书建立域名与公钥的信任关系，私钥签名证明服务器身份。
- 现代 TLS 使用 ECDHE 协商共享秘密，并使用对称认证加密传输 HTTP 数据。
- TLS 1.2 的 RSA Pre-Master Secret 流程是经典旧模型，不应冒充 TLS 1.3 流程。
- TLS 1.3 将完整握手降低到通常 1-RTT；0-RTT 只用于特定恢复场景且存在重放风险。