微软官宣 6.16 全面抛弃 IE，在技术领域这无疑是值得肯定的进步，但对身处风险厌恶、技术保守型行业的 IT 工程师来说——夹在激进的 IT 行业和保守的从业环境之间，替换之路并不容易走，时常感到左右为难。
距离推动生产环境部署 Openshift 已近一年，负责的第一个运行其上的应用最近也正式投入使用，在兼容 IE 的过程中也踩了几个坑，拣有意思的记录一下。
遇到的其中一个问题是 IE11 访问 Openshift Router 暴露的 https 地址无法打开。提示启用相关安全协议，进 Internet 选项高级里确认默认都是勾选的，仍然不行。诡异的是在某些一样版本的 window 7 系统上，使用 IE11 又可以正常访问。
最后抓包看了一下，在 tcp 连接建立后进行 tls 协商时失败了。
Server Hello 信息太简洁，没有太多有价值的线索，检查 Client Hello，发现最可疑的就是 Cipher Suites，这里列举出的是客户端支持的选项，猜测可能和服务端支持的没有匹配上。
为了进一步验证猜测，抓包了正常的 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 小时，导致一夜过后引发半开连接问题——半开连接也是一种典型问题，来源于 tcp 连接的一端由于没有正常通知对端连接已经关闭，导致对端的连接还开着。
0 条评论