服务器抛出Encryption alert(Alert(21))及连接重置问题求助

核心问题拆解 #

• 使用密码套件 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 发送应用数据后，服务器抛出Encryption alert(21)错误
• 抓包显示服务器已推进握手流程，但客户端未发送Finish报文，握手未完成

排查方向及解决方案 #

1. 修复握手流程顺序错误
   TLS 1.2协议要求必须完成双向握手（客户端发送Client Key Exchange→Change Cipher Spec→Finish，服务器回复Change Cipher Spec→Finish）后，才能传输应用数据。如果客户端在握手未完成时就发送应用数据，服务器会因无法解密（会话密钥未同步）抛出decryption_failed（告警码21）。需检查客户端代码逻辑，确保应用数据发送逻辑在握手完成回调之后执行。

2. 验证DHE密码套件兼容性
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256依赖客户端生成DHE密钥对，部分服务器对DHE密钥长度（如要求2048位以上）有强制限制，若客户端生成的密钥不符合要求，会导致密钥协商失败，进而引发握手中断（客户端未发送Finish）。可临时更换为非DHE类套件（如TLS_RSA_WITH_AES_128_GCM_SHA256）测试，若问题消失，需调整客户端DHE密钥配置或更换兼容的套件。

3. 排查客户端TLS栈异常
   客户端未发送Finish报文，大概率是TLS库在生成Finish报文时出现错误：

   • 检查客户端TLS库版本，是否存在已知的DHE握手bug（如部分老旧OpenSSL版本在特定DHE参数下的异常）
   • 验证密钥计算流程：客户端需用服务器发送的Server Key Exchange参数生成会话密钥，若此过程出现计算错误，会导致无法生成Finish报文所需的验证数据

4. 解析告警码21的具体触发点
   告警码21对应decryption_failed，说明服务器无法解密客户端发送的应用数据，本质原因是握手未完成导致双方会话密钥不一致，或者密钥协商过程中出现数据篡改、参数不匹配。可通过抓包对比客户端发送的应用数据加密参数，确认是否与握手阶段协商的算法、密钥一致。

内容的提问来源于stack exchange，提问作者Ahamed Fayaz.