HTTPS 的工作原理是什么？TLS 握手过程是怎样的？

简化版

HTTPS 就是 HTTP 跑在 TLS 之上。核心是 TLS 握手：用非对称加密安全地协商出一个对称密钥，之后所有数据用这个对称密钥加密传输。握手里服务器还会用数字证书证明自己身份（防止中间人冒充）。所以一次握手同时完成了三件事——验证身份、协商密钥、切换到加密通信。

详细版

为什么要「非对称协商 + 对称传输」的混合模式：非对称加密安全但慢，对称加密快但有「密钥怎么安全送给对方」的难题。HTTPS 用非对称加密在握手阶段安全地传递对称密钥，之后用对称加密传业务数据，兼顾安全和性能。

TLS 1.2（RSA 密钥交换）握手过程：

Client Hello：客户端发送支持的 TLS 版本、加密套件列表，以及一个随机数 Client Random。
Server Hello：服务器选定版本和加密套件，返回随机数 Server Random。
Certificate：服务器发送数字证书（含服务器公钥，由 CA 签名）。
客户端验证证书：验签、域名、有效期、是否由受信任 CA 签发。
Client Key Exchange：客户端生成第三个随机数 Pre-master Secret，用证书里的服务器公钥加密后发给服务器（只有服务器的私钥能解开）。
双方用 Client Random + Server Random + Pre-master Secret 各自推导出相同的会话密钥（对称密钥）。
双方发送 Change Cipher Spec + Finished，之后所有通信用会话密钥对称加密。

完整版教学

一、HTTPS 解决的三个问题，握手全包了

HTTP 明文有三大风险：被窃听、被篡改、被冒充。TLS 握手一次性建立起对抗这三者的能力：

协商对称密钥 → 之后数据加密传输，对抗窃听；
消息认证码（MAC） → 对抗篡改；
验证数字证书 → 对抗冒充（中间人）。

理解握手，就是理解「密钥怎么安全地协商出来」和「身份怎么验证」这两件核心事。

二、为什么是「非对称 + 对称」混合加密

如果全程用对称加密：快，但双方一开始没有共享密钥，怎么把密钥安全地告诉对方？直接发会被中间人截获。

如果全程用非对称加密：安全，但太慢，不适合加密大量业务数据。

HTTPS 的巧妙在于各取所长：

握手阶段用非对称加密——客户端用服务器公钥加密 Pre-master Secret 发过去，只有服务器私钥能解，安全地完成密钥交换；
数据阶段用对称加密——用协商好的会话密钥加解密业务数据，快。

这样「密钥分发」用非对称解决，「大量数据传输」用对称解决。

三、密钥不是直接传的，是「协商」出来的

一个常见误解是「客户端把对称密钥加密后发给服务器」。更准确的是：客户端传的是 Pre-master Secret（预主密钥），然后双方各自用三个随机数（Client Random、Server Random、Pre-master Secret）通过同样的算法推导出Master Secret，再由它生成会话密钥。

为什么这么绕？因为让双方都参与随机数、共同推导，能增强随机性、防重放（详见「HTTPS 握手为什么需要三个随机数」那道题）。真正加密传输的只有 Pre-master Secret，前两个随机数是明文交换的。

四、证书验证：防止中间人冒充

密钥协商解决了「加密」，但还有个漏洞：客户端怎么确认拿到的公钥真是目标服务器的、不是中间人伪造的？ 万一中间人把自己的公钥冒充成服务器的，它就能解密一切。

这靠数字证书：服务器公钥由权威 CA 用 CA 私钥签名，做成证书。客户端用内置的 CA 公钥验证证书签名、检查域名和有效期。中间人无法伪造一个被受信 CA 签名、且域名匹配的证书，冒充就被挡住（详见「数字证书」和「HTTPS 如何防中间人攻击」两道题）。

五、TLS 1.3 简化了握手

上面讲的是 TLS 1.2 的经典 RSA 密钥交换流程（2-RTT）。TLS 1.3 做了重大改进：握手压缩到 1-RTT（会话恢复可 0-RTT），且移除了 RSA 密钥交换，强制使用 ECDHE（带前向安全性）。所以 TLS 1.3 里不再有「用服务器公钥加密 Pre-master Secret」这一步，密钥交换改由 ECDHE 完成，证书只用于签名认证身份（详见「TLS 1.2 和 1.3 的区别」那道题）。

六、常见误区

❌ 以为 HTTPS 全程用非对称加密——握手用非对称协商密钥，数据传输用对称加密。
❌ 以为客户端直接把对称密钥加密发给服务器——传的是 Pre-master Secret，双方各自推导出会话密钥。
❌ 以为加密就够了——还要证书验证身份，否则中间人用自己的公钥就能冒充。
❌ 把 TLS 1.2 的 RSA 流程当成唯一方式——TLS 1.3 已改用 ECDHE，无 RSA 密钥交换。

六、常见误区与追问

考点	正确口径
身份认证	通过证书链验证服务器身份
密钥协商	用 ECDHE 等协商会话密钥
安全传输	握手后用对称加密保护 HTTP 数据

ClientHello
ServerHello + Certificate + Signature
key exchange -> traffic keys
Finished
encrypted HTTP

TLS 握手的结果不是传了一个固定密码，而是双方协商出后续通信密钥并确认对方身份。

误区：HTTPS 握手直接把对称密钥发过去。 现代 TLS 通过密钥交换协商出共享密钥，密钥本身不直接明文传输。
误区：证书只负责加密。 证书主要负责绑定域名和公钥，证明服务器身份。
误区：TLS 握手完成后还用非对称加密传数据。 应用数据使用高效对称加密，非对称主要用于认证和协商。
追问：ClientHello 里有什么？ 包含支持的 TLS 版本、随机数、密码套件、扩展和 SNI 等信息。
追问：Finished 消息有什么用？ 校验握手 transcript 和密钥是否一致，防止握手被篡改。
追问：TLS 1.3 相比 1.2 简化在哪里？ 减少往返、移除不安全算法，把更多握手内容加密保护。

七、加强记忆

HTTPS = HTTP + TLS。TLS 握手做三件事：验证服务器证书（防冒充）、用非对称加密协商出对称会话密钥（Client/Server Random + Pre-master Secret 推导）、之后切换成对称加密传数据（防窃听）+ MAC（防篡改）。混合加密是为了兼顾非对称的安全和对称的性能；TLS 1.3 把握手简化为 1-RTT 并强制 ECDHE。

简化版

详细版