HTTPS 握手为什么需要三个随机数？

简化版

TLS 1.2 握手用三个随机数生成对称密钥：Client Random（客户端发，明文）、Server Random（服务端发，明文）、Pre-master Secret（客户端生成，加密传输）。前两个明文随机数保证双方都参与、增加随机性、防重放；第三个是真正保密的秘密。三者共同推导出 Master Secret 再生成会话密钥——多个随机数叠加，让最终密钥更随机、更难预测、更安全。

详细版

三个随机数的来源和作用：

随机数	谁生成	怎么传	作用
Client Random	客户端	明文（Client Hello）	客户端贡献随机性、防重放
Server Random	服务端	明文（Server Hello）	服务端贡献随机性、防重放
Pre-master Secret	客户端	用服务器公钥加密传输	真正保密的核心秘密

怎么用：双方各自用 Master Secret = PRF(Pre-master Secret, "master secret", Client Random + Server Random) 推导出相同的 Master Secret，再由它生成对称会话密钥。

为什么不只用 Pre-master Secret 一个：如果只靠一个随机数，随机性来源单一、且无法防重放。加入双方各自的明文随机数，让通信双方都对最终密钥有贡献，且每次会话的随机数不同，能有效防止「重放攻击」。

完整版教学

一、核心目的：让密钥足够随机、不可预测

对称密钥的安全，很大程度取决于它够不够随机、能不能被预测。如果密钥的随机性来源单一或可被猜测，攻击者就可能推算出密钥。

用三个随机数，本质是叠加多个随机性来源：客户端出一个、服务端出一个、再加一个加密传输的核心秘密。三者混合后推导出的密钥，随机性更充分、更难预测。这是「不把鸡蛋放一个篮子」的思路——多方贡献熵，比单一来源更可靠。

二、为什么要「双方都参与」

前两个随机数（Client Random、Server Random）虽然是明文传输的（谁都能看到），但它们有个关键作用：保证通信双方都对最终密钥有贡献。

如果只用客户端生成的 Pre-master Secret，那么密钥完全由客户端单方决定，服务端只是被动接受。加入服务端的 Server Random 后，最终密钥由双方共同决定——任何一方都无法单方面控制或预测完整的密钥。这提升了安全性，也是密钥协商「双方协商」而非「一方指定」的体现。

三、明文随机数怎么防重放

「重放攻击」指攻击者录下一次合法的握手/请求，之后原样重发来冒充。前两个随机数正是防重放的关键。

因为 Client Random 和 Server Random 每次握手都重新随机生成，所以每次会话推导出的密钥都不同。攻击者即使录下了之前的握手报文原样重放，由于这次服务端会生成新的 Server Random，最终密钥对不上,重放无法成功建立有效会话。明文不要紧——它们的价值在于「每次都不同」带来的新鲜性（freshness），而不在于保密。

四、只有 Pre-master Secret 需要保密

三个随机数里，只有 Pre-master Secret 是加密传输的（用服务器公钥加密），因为它是推导密钥的真正秘密核心——攻击者只要拿到它，配合明文的两个随机数就能算出会话密钥。

而 Client/Server Random 明文传输无所谓——即使攻击者拿到这两个，缺了加密保护的 Pre-master Secret，也推不出会话密钥。所以保密的重担落在 Pre-master Secret 上，这也是它要用非对称加密保护的原因。

五、TLS 1.3 里的变化

上面讲的是 TLS 1.2 的 RSA 密钥交换流程。TLS 1.3 移除了 RSA 密钥交换、改用 ECDHE，密钥协商方式变了——不再有「客户端用公钥加密 Pre-master Secret」这一步，共享密钥由双方的 ECDHE 参数经 Diffie-Hellman 算出。但「双方各自贡献随机数、共同生成密钥」的思想仍然保留（Client/Server Random 依然存在，参与密钥派生）。所以「三个随机数」是 TLS 1.2 经典流程的说法，理解其思想（多方贡献随机性、防重放、只有核心秘密需保密）比背流程更重要。

六、常见误区

❌ 以为三个随机数都要保密——只有 Pre-master Secret 加密传输，前两个是明文。
❌ 以为明文随机数没用——它们保证双方都参与、每次不同，用于防重放和增加随机性。
❌ 以为直接用 Pre-master Secret 当密钥——是三者一起经 PRF 推导出 Master Secret，再生成会话密钥。
❌ 把它当成所有 TLS 版本的通用流程——这是 TLS 1.2 RSA 交换的说法，TLS 1.3 用 ECDHE 已改变。

六、常见误区与追问

考点	正确口径
Client Random	客户端贡献随机性
Server Random	服务端贡献随机性
Pre-master/共享秘密	密钥协商得到的核心秘密
会话密钥	由这些材料通过 PRF/HKDF 派生

TLS 1.2:
master_secret = PRF(pre_master, client_random, server_random)
TLS 1.3:
traffic_secret = HKDF(shared_secret, transcript_hash)

随机数可以明文传，真正必须保密的是 pre-master 或 ECDHE 共享秘密。

误区：三个随机数都必须保密。 Client Random 和 Server Random 是明文，保密的是 pre-master secret 或 ECDHE 私有材料。
误区：只要客户端随机数就够了。 双方都贡献随机性，可以避免单方随机数质量差完全决定密钥。
误区：随机数只是防重放的小装饰。 随机数参与密钥派生，保证每次会话密钥不同。
追问：为什么需要会话密钥不同？ 即使访问同一网站，每次连接也应使用不同密钥，降低流量关联和密钥复用风险。
追问：TLS 1.3 还有三个随机数说法吗？ 表达方式变化，ECDHE shared secret 和 transcript 参与 HKDF 派生，不再按旧 RSA 握手简单讲三随机数。
追问：明文随机数会不会被篡改？ 握手 transcript 会被 Finished 校验，篡改会导致双方校验失败。

七、加强记忆

TLS 1.2 握手三个随机数：Client Random、Server Random（明文，双方各贡献随机性、防重放）、Pre-master Secret（加密传输，真正的保密核心）。三者经 PRF 推导出 Master Secret 再生成会话密钥。多方叠加随机性让密钥更不可预测，明文随机数每次不同防重放，只有 Pre-master Secret 需保密。TLS 1.3 改用 ECDHE 后流程有变，但思想保留。

简化版

详细版