暂无图片
暂无图片
暂无图片
暂无图片
暂无图片
首页 / SSL EMS｜一次因DHE算法引发的Windows终端间歇性故障分析

SSL EMS｜一次因DHE算法引发的Windows终端间歇性故障分析

小咩社长 2021-11-06
2046
阅读提示｜本文大概4529字   阅读需要7分钟

写在前面：

    2021年的第一场雪（北京），感觉比以往来的更早一些，摸着屋里冰冷的暖气片，感觉顿时思维踊跃，先撸一篇再说！！

   上周在大连出差，周六的晚上正当我撸着皮皮虾，嗦着梭子蟹，觥筹交错期间，远在北京的一个客户给我打了一通电话说：涛哥，我们这有个业务，访问有点问题，具体现象是一个PC终端（Windows server 2012），通过HTTPS协议调用应用接口的时候（该业务通过F5对外发布，SSL证书卸载也终结在F5上，后端服务器为HTTP明文），每两百多笔交易（HTTPS请求），会有一次失败的情况，客户端程序报错信息：“请求被中止: 未能创建 SSL/TLS 安全通道”。

   听到这，手里的大螃蟹突然就不香了，出门点了根烟，在露台上吹着大连略带湿气的海风，捋了捋思绪。

梳理下客户提供的线索：

1. 客户端是Windows Server

2. 业务通过F5对外发布，并提供SSL卸载

3. 客户端程序报错：请求被中止: 未能创建 SSL/TLS 安全通道

问题分析排查思路

    经过和用户进一步沟通，用户反馈在F5 v13版本测试没问题，在v12版本就会出现这个故障现象，同样的测试终Win server 2012，同样的测试程序，在不同的F5版本下测试出现了比较大的差别。听到这一般的工程师会说：肯定是版本兼容的问题，升级个版本完事。但是作为一名资深F5工程师（资深可以理解为踩的坑多，并无其他含义）来说，本着格物致知的心态，必须把这个问题给定位，撸圆了！

通过客户端程序报错，大概能判断出，具体失败的原因为SSL协商过程中出错，按着这个思路继续往下分析。由于问题很好复现，和用户协商下，当客户端测试的时候，客户端和F5端同时进行抓包，并且客户端记录下报错时间点，综合分析。

梳理客户访问流程

1. WinSever 2012 发起HTTPS的请求调用应用接口 

2. 该应用接口通过F5对外发布，并实现SSL卸载终结

3. F5将SSL卸载后的明文流量分发到后台真实的应用服务器处理业务请求

4. 应用服务器处理完请求返回给F5，由F5转发给真实的客户端（WinServer）

客户端抓包分析

1. 通过客户端测试，并使用wireshark抓包，我们得到了一手信息，通过客户提供的程序报错时间点，我们定位了故障数据包，如下图所示：

2. 通过查看客户端提供的数据包包我们可以看到有一个Handshake Failure Code 40的报错，进一步查询F5官方可以看到该Code 40的报错解析：大概意思是协商的安全参数有问题

3. 通过数据包我们把客户端和F5端协商的SSL cipher suit单独拿出来看一下：

#SSL握手协商过程
cleint Hello
Cipher Suites (26 suites)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
    Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
    Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
    Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
    Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
    Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
    Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x006a)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x0040)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
    Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
    Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
    Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)


Server Hello
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)


#可以看到两端SSL协商的cipher suit最终为
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)

3. 看到这我们或许有点疑惑，cipher suit都协商出来了为啥还会报Code 40呢，正在这有点尬住的时候，客户提供了一个链接过来，上图：

趁胜追击

 1. support.microsoft.com给的提示

管理员的高级信息


1. 当协商 TLS_DHE_* 密码套件时，尝试与不支持扩展主密钥 (EMS) 的设备进行传输层安全 (TLS) 连接的 Windows 设备可能会间歇性地在 256 次尝试中失败约 1 次。 若要缓解此问题，请按照优先顺序实施下列解决方案之一：


    在客户端和服务器操作系统上执行 TLS 连接时，启用对扩展主密钥 (EMS) 扩展的支持。


    对于不支持 EMS 的操作系统，请从 TLS 客户端设备的操作系统的密码套件列表中删除 TLS_DHE_* 密码套件。 有关如何在 Windows 上执行此操作的说明，请参阅优先处理 Schannel 密码套件。




2. 在恢复后仅以完全握手方式发送证书请求消息的操作系统不符合 RFC 2246 (TLS 1.0) 或 RFC 5246 (TLS 1.2)，并将导致每个连接失败。 RFC 不保证能够恢复，但 TLS 客户端和服务器可自行决定使用恢复。  如果遇到此问题，则需要联系制造商或服务提供商，以获取符合 RFC 标准的更新。


3. 不符合 RFC 2246 (TLS 1.0) 和 RFC 5246 (TLS 1.2) 的 FTP 服务器或客户端可能无法在恢复或简短握手时传输文件，并将导致每个连接失败。 如果遇到此问题，则需要联系制造商或服务提供商，以获取符合 RFC 标准的更新。


通过官方给的说法，我们回顾一下客户端提供的故障数据包中，SSL hanshake Failure的报错信息是啥，没错是DHE：

TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)

按照Windows官方的建议，用户从客户端设备的操作系统的密码套件列表中删除 TLS_DHE_* 密码套，用户windows server 2012修改完后，测试正常，接口调用不在报错。

F5侧分析定位

通过微软官方网站给的说法：当协商 TLS_DHE_* 密码套件时，尝试与不支持扩展主密钥 (EMS) 的设备进行传输层安全 (TLS) 连接的 Windows 设备可能会间歇性地在 256 次尝试中失败约 1 次。最开始我描述过用户在13版本测试没有任何问题，在12版本测试出现以上故障，故障现象基本和以上描述相符。通过查询F5官方介绍，可以看到v12版本确实不支持EMS，上图：

另外F5 support也提供了另外一个解决思路，就是禁用掉DHE和DH Cipher

#根据F5介绍，建议使用ECDHE算法，或者手动关闭DHE和DH算法
#F5 ssl profile Cipher手动关闭DHE和DH算法方式
Cipher：DEFAULT:!DHE:!DH

总结

    根据以上分析基本能够得出，该故障场景只有在特定的情况下才会发生，很刁钻。同时我们也可以通过多种方式去解决这个问题，任选一种即可：

1. 客户端调整配置

2. F5侧调整Cipher

3. 系统升级

     当我撸完这篇文章的时候，屋里的暖气片依旧是凉凉的，我随手拿起了我的羽绒服披在了身上……


参考链接：

https://support.microsoft.com/zh-cn/topic/%E5%BD%93%E8%BF%9E%E6%8E%A5%E6%88%96%E5%B0%9D%E8%AF%95%E6%81%A2%E5%A4%8D%E6%97%B6-%E4%BC%A0%E8%BE%93%E5%B1%82%E5%AE%89%E5%85%A8-tls-%E8%BF%9E%E6%8E%A5%E5%8F%AF%E8%83%BD%E4%BC%9A%E5%A4%B1%E8%B4%A5%E6%88%96%E8%B6%85%E6%97%B6-326bd5b1-52a1-b367-8179-b154e5c01e90

https://support.f5.com/csp/article/K10433354

https://support.f5.com/csp/article/K66202244


觉得本文对你有帮助，请分享给更多人


- EOF -

推荐阅读  点击标题可跳转

1、Wireshark｜记一次批处理异常报错的故障排除

2、一文读懂F5 REST API的细粒度角色访问控制

3、手把手教你使用Rancher快速创建一个kubernetes集群

4、tcpdump抓包拆解flannel vxlan模式下的容器跨主机通信流程

5、Rancher Server自动下发F5负载均衡策略实践｜7层负载均衡

数据库
文章转载自小咩社长，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

评论