加密套件问题导致部分服务器响应空白

问题描述

一套单体系统部署在38和39服务器上，大部分用户直连39环境，无法登陆，而直连38环境能正常访问。

诊断流程

总体流程概述

首先，我们先检查39服务器，重点包括SSL是否配置正确、是否已开启SSL拒绝日志记录、域日志是否有异常，结果尚未发现问题。

其次，准备在异常客户端系统上，检查网络问题。

1. 使用ping检查和比较38、39网络连通性，结果正常；

2. 使用tracert命令检查和比较38、39路由情况，结果正常。

3. 安装wireshark软件，详细检查网络包。

第三，通过网络异常包，分析并解决。

网络包检查

分三次拦截，每次访问并拦截38/39 https请求，生产三组pcapng文件。

我们只需截取网络报文中的从请求到第一次弹框阶段报文即可。经反复比较，认为在SSL握手阶段 “server hello”,38、39返回的报文首次不同，如下：

39

38

很显然38和39返回的加密套件Cipher Suite 不同，加密套件用于后续会话秘钥加解密，跟加密套件有关的程序包括操作系统、浏览器插件、JDK。操作系统决定了套件的实现总集合，浏览器插件或JDK根据情况选择合适的加密套件。接下来检查39环境加密套件设置，期望返回如38一致的加密套件，测试通过则证明其是主因。

加密套件检查与修复

通过cmd systeminfo检查38、39操作系统，发现版本一致，尚未发现问题。

接下来我们的方向应调整39，使返回的加密套件和38一致。

1. 检查注册表regedit,发现38/39一致。

2.检查SSL配置 gpedit,39中存在如下部分，而38不存在。

点开密码套件顺序，设置“已启用”后，经测试“server hello”返回跟以前一样。

下载Windows更新程序，此程序官方说明已包括EC 套件。经测试仍然不行。

调整39 JDK1.6版本为JDK1.7后，经测试，返回套件与38一致，并且界面能够弹出UKEY。

异常终端测试

对之前访问39异常的客户电脑，共计5台，重新测试后都正常。