一次 TLS 协商失败问题分析

夜读春秋

已于 2022-08-21 12:08:59 修改

阅读量1.6k

点赞数

CC 4.0 BY-SA版权

分类专栏： web 网络文章标签： https 网络网络协议

于 2022-05-28 11:31:45 首次发布

本文链接：https://blog.csdn.net/alading2009/article/details/125016258

web 同时被 2 个专栏收录

22 篇文章

订阅专栏

网络

13 篇文章

订阅专栏

本文记录了解决IE11访问OpenshiftRouter暴露的https地址时遇到的问题及解决过程，涉及TLS协议、CipherSuite匹配及微软补丁更新。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

个人博客
微软官宣 6.16 全面抛弃 IE，但对身处风险厌恶、技术保守型行业或者企业的 IT 工程师来说——夹在激进的 IT 行业和保守的业内环境之间，替换之路并不容易走，时常感到左右为难。

距离推动生产环境部署 Openshift 已近一年，负责的第一个运行其上的应用最近也正式投入使用，在兼容 IE 的过程中也踩了几个坑，拣有意思的记录一下。

遇到的其中一个问题是 IE11 访问 Openshift Router 暴露的 https 地址无法打开，提示启用相关安全协议，进 Internet 选项高级里确认默认都是勾选的，仍然不行。诡异的是在某些一样版本的 window 7 系统上，使用 IE11 又可以正常访问。

最后抓包看了一下，在 tcp 连接建立后进行 tls 协商时失败了。
在这里插入图片描述

Server Hello 信息太简洁，没有太多有价值的线索，检查 Client Hello，发现最可疑的就是 Cipher Suites，这里列举出的是客户端支持的选项，难道和服务端支持的没有匹配上？

此图片的alt属性为空；文件名为image-1.png

为了进一步验证猜测，抓包了正常的 IE11 交互过程，发现服务端响应的 Cipher Suite 是 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256，连续找了两台抓包结果也是这个 Cipher Suite。同时找运维潘同学一起看了 Openshift Router 与 Cipher Suite 相关设置，貌似 Router 并没什么问题。

在这里插入图片描述

搜索了微软的官方补丁，发现在 KB3042058 （前置补丁 KB3020369）的补丁里提到新增了对 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 的支持，下载安装重启后，发现网页可以正常访问了。抓包协商过程，此时在 Client Hello Cipher Suites 里加入了 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 ，Server Hello 也进行了肯定。

说到网络，想起之前遇到的两次问题：一次是解决业务柜台连不上内部某网站，发现是防火墙策略拒绝了 ssl2；另一次是观摩其他同事解决连续几天早上 redis 连接失效问题，发现是防火墙上设置了 tcp 连接的最长有效时长为 8 小时，导致一夜过后引发 redis 半开连接问题——半开连接也是一种典型问题。