TLS如何保证数据不被篡改？数字签名验证流程是什么？

## 作用 - **保证完整性、防篡改**：TLS 在连接建立后的通信过程中，使用协商出的密钥对数据进行加密，并通过签名、验签或 AEAD/MAC 校验确认数据在传输过程中没有被修改。 - **保证保密性**：应用数据使用握手阶段协商出的会话密钥进行对称加密，第三方即使截获报文也无法读取明文。 - **身份认证**：握手阶段通过证书及数字签名验证通信方身份，防止冒充服务端或客户端。 - 文章还指出，TLS 1.2 使用 SHA256 等更安全的算法替代 MD5/SHA1；TLS 1.3 仅保留 AEAD 类型的对称加密算法，并对 ServerHello 之后的消息加密。 ## 原理 ### 1. 握手阶段先完成身份验证和密钥协商 以文章描述的 TLS 1.1/1.2 流程为例： 1. **客户端发送 ClientHello** - 携带用于生成密钥的随机数等信息。 2. **服务端返回 ServerHello 及证书** - 返回另一个随机数。 - Certificate 消息中包含服务端证书，证书中有签名算法、公钥等信息。 - 必要时发送 ServerKeyExchange 补充密钥交换参数。 - 如需认证客户端，会发送 CertificateRequest。 3. **客户端验证服务端证书** - 校验证书有效性以及服务端身份。 4. **客户端进行密钥交换** - 如果使用 RSA，客户端生成随机数，并用服务端证书公钥加密后发送。 - 如果使用 DH，则发送 DH 参数。 5. **双方生成会话密钥** - 双方结合随机数及密钥交换参数生成相同的会话密钥。 6. **双向发送 Finished 消息** - Finished 消息使用协商出的密钥加密并包含握手过程的校验数据。 - 双方通过验证 Finished，确认握手消息未被篡改、密钥协商一致且身份认证通过。 ### 2. 数字签名验证流程 文章中涉及的签名和验签流程可概括为： 1. **证书提供公钥** - 服务端证书中包含服务端公钥、签名算法等信息。 - 客户端先验证证书本身是否有效、是否可信。 2. **签名方使用私钥签名** - 发送方对待发送或握手相关数据计算摘要。 - 使用自己的私钥对摘要进行签名。 - 在客户端证书认证场景中，客户端会发送 CertificateVerify，内容是使用客户端证书对应私钥生成的签名，用于证明自己持有该私钥。 3. **验证方使用证书公钥验签** - 接收方使用证书中的公钥验证签名。 - 同时重新计算收到数据的摘要。 - 如果验签通过且摘要一致，说明数据来源对应证书主体，并且数据没有被篡改。 4. **验证失败则拒绝连接或拒绝认证** - 证书无效、私钥签名不匹配或握手数据被改动，都会导致验证失败。 ### 3. 后续应用数据如何防篡改 握手完成后： - 双方使用协商好的会话密钥和加密算法传输应用数据。 - 每条受保护记录都会带有完整性校验值；接收方重新计算并比对，不一致就说明数据可能被篡改。 - 在 TLS 1.3 中，主要通过 **AEAD** 算法同时提供加密和完整性保护；攻击者修改密文后，接收方进行认证解密时会校验失败，从而丢弃被篡改的数据。