当服务器收到客户端发送的密钥（通常指在 TLS/SSL 握手过程中交换的预主密钥 Pre-Master Secret，或者在对称加密场景下交换的会话密钥 Session Key）后，服务器会执行一系列严谨的安全处理步骤，以确保通信的安全性和完整性，以下是标准流程（以最常见的 TLS 1.2/1.3 为例）：
验证密钥来源与完整性
- 解密预主密钥：如果使用的是非对称加密（如 RSA 密钥交换），服务器使用自己的私钥对客户端发送的加密预主密钥进行解密，得到明文预主密钥。
- 验证数字签名：如果使用的是临时 Diffie-Hellman（ECDHE）等密钥交换算法，服务器会验证客户端发送的密钥交换参数中的数字签名，确保该密钥确实来自声称的客户端，而非中间人攻击者。
生成主密钥（Master Secret）
- 服务器将以下三个值组合,通过伪随机函数（PRF, Pseudo-Random Function）生成主密钥（Master Secret）：
- 客户端发送的随机数（Client Random）
- 服务器发送的随机数（Server Random）
- 预主密钥（Pre-Master Secret）
注意：主密钥本身不会在网络上传输，仅在服务器和客户端本地计算得出。
派生会话密钥（Session Keys）
- 服务器使用主密钥和随机数,通过密钥派生函数（KDF）生成一组会话密钥，通常包括：
- 客户端到服务器的加密密钥（用于加密客户端发送的数据）
- 服务器到客户端的加密密钥（用于加密服务器发送的数据）
- 客户端到服务器的 MAC 密钥（用于消息认证码，确保数据完整性）
- 服务器到客户端的 MAC 密钥
- （在 TLS 1.3 中，加密和认证通常由 AEAD 算法如 AES-GCM 或 ChaCha20-Poly1305 统一处理）
发送“Finished”消息
- 服务器使用刚刚生成的会话密钥,对之前的握手消息进行哈希计算，生成一个“验证数据”（Verify Data），并发送 ChangeCipherSpec 和 Finished 消息给客户端。
- 这一步用于向客户端证明：服务器已成功计算出相同的会话密钥，握手过程未被篡改。
开始安全通信
- 一旦客户端验证了服务器的 Finished 消息，双方确认密钥一致且握手成功。
-
此后,所有应用层数据（如 HTTP 请求）都将使用派生的会话密钥进行对称加密和完整性校验，实现高效且安全的通信。
安全注意事项
- 密钥必须保密：服务器绝不能将主密钥或会话密钥记录在日志中或发送给第三方。
- 前向安全性（Forward Secrecy）：现代 TLS 推荐使用前向安全密钥交换算法（如 ECDHE），这样即使服务器私钥未来泄露，历史会话也不会被解密。
- 密钥更新：在长连接中，服务器可能定期重新协商密钥或更新密钥材料，以限制单个密钥的暴露风险。
如果你指的是其他特定场景（如 SSH、自定义协议、API 密钥等），请提供更多上下文，我可以给出更具体的回答。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/478582.html
评论列表（1条）
光看标题就来气！说好的密钥交换，结果服务器直接拿去用了？那中间人偷看了咋办？真以为加密是儿戏啊，无语了😒