TLS握手四步协商如何同时解决窃听篡改冒充三个问题

[[数字证书用CA公证打破公钥可信分发的鸡生蛋问题]]解决了信任起点问题， TLS（前身SSL）要做的是把”确定加密算法→生成密钥→分发公钥→CA认证→ 核验→签名→验证”这一整套繁琐流程自动化封装进传输层之上、应用层之下， 让上层的HTTP协议对此完全无感知。以TLS 1.2为例，四次握手分两轮完成： 客户端Hello（明文发送支持的协议版本、随机数、密码学套件列表）；服务端 Hello（明文确认协议版本和套件、发第二个随机数，并附上X.509证书，若是 基于证书的密钥交换算法则公钥信息也在此时给出）；客户端确认（先验证证书 合法性——是否可信CA颁发、域名是否匹配、是否过期或被吊销，验证通过后 用证书里的公钥加密第三个随机数即PreMasterSecret发给服务端，三个随机数 一起算出后续对称加密要用的MasterSecret）；服务端确认（双方各自确认后续 通信将采用协商好的加密方式）。整个过程同时解决三个问题：窃听——正式内容 用协商出的对称密钥加密传输；篡改——一旦内容被改动，后续解密或哈希校验 就会失败，立刻能被发现；冒充——证书验证环节确保拿到的公钥确实属于它 声称的身份。TLS 1.3把原本固定的两轮四次握手压缩到一轮，连接复用时甚至 能做到零往返（0-RTT），显著提升了建连速度。

结构图：

sequenceDiagram
    participant C as 客户端
    participant S as 服务端
    C->>S: Client Hello: 协议版本+随机数1+密码学套件列表(明文)
    S->>C: Server Hello: 确认版本+随机数2+证书+选定套件(明文)
    Note over C: 验证证书合法性(CA/域名/有效期/吊销)
    C->>S: 用证书公钥加密随机数3(PreMasterSecret)+握手结束通知
    Note over C,S: 三个随机数算出MasterSecret作为对称密钥
    S->>C: 编码改变通知+服务端握手结束通知
    Note over C,S: 后续通信全部用MasterSecret对称加密