关于https:一次SSL握手异常我发现JDK还有发行版区别

4次阅读

共计 3701 个字符，预计需要花费 10 分钟才能阅读完成。

原创：扣钉日记（微信公众号 ID：codelogs），欢送分享，转载请保留出处。

最近，咱们一个多机房部署的服务，调用方反馈有问题，在调用新加坡机房时失常，而调用印度机房则报 SSL 握手异样。

排查花了一些工夫，同时也积攒了一些教训，故记录一下，读完本文，你将理解到如下内容：

SSL 握手过程
SSL 握手异样时的排查思路与工具
同版本的 JDK，也是有所差别的

废话不多说，往下看 …

调用方调用印度机房服务时，报错信息如下：

这个异样是共事始终在看，通过一翻搜寻，狐疑是 JDK 版本的问题，通过询问调用方，发现调用方版本是1.8.0_91-b14，于是共事打算下载此版本 JDK 本地测试一下。

但这个版本 JDK 不太好找，于是共事就问了下我，我也找了一会也没找到，于是打算从源码编译一个此版本 JDK。

通过一段时间，我通过源码编译进去了这个版本的 jdk，同时共事也在网上找到了一个此版本的 JDK，如下：
JDK 源码：https://github.com/openjdk/jdk8u，tag 抉择 jdk8u91-b14 即可。
网上的 JDK 包：https://github.com/ojdkbuild/…

弄到 1.8.0_91-b14 版 JDK 后，我和共事都进行了测试，奇怪的是，共事网上找的 JDK 重现了调用方的报错，即新加坡机房失常，而印度机房 SSL 握手失败，但我本人编译的 JDK 则两个机房都失常，咱们可是雷同版本的 JDK 啊！

好家伙，当初有 2 个疑难了，如下：

为啥新加坡机房失常，而印度机房 SSL 握手报错？
为啥雷同版本的 JDK，本人编译的没有问题？

因为我之前解决过一次 SSL 握手异样的 bug，也写成了一篇文章一次 IOS 告诉推送问题排查全过程，起因是因为客户端与服务端明码套件不统一导致的。

粗略来讲，SSL 握手过程如下：

客户端发送 Client Hello 包给服务端，其中除了蕴含密钥协商相干的数据外，还会告知本人反对的明码套件列表。
服务端收到 Client Hello 包后，会给客户端回复 Server Hello，其中也蕴含了密钥协商数据，以及服务端抉择了哪个明码套件。

但有一种状况是，客户端第一步发送的所有明码套件，服务端都不反对，因而服务端会回复一个 SSL 握手异样包，进而导致客户端失败报错。

注：明码套件，指的是加密零碎将多种密码学算法混合应用，以实现多种平安需要，如 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256，应用 ECDHE 实现密钥协商、RSA 实现证书认证、AES 实现加密、SHA256 实现音讯防篡改。

如何确认是否是下面起因呢？我进行了如下测试：

增加 JVM 参数-Djavax.net.debug=SSL，并调用失常的新加坡机房，看看 SSL 握手抉择的是什么明码套件。
```
$ bin/java -Djavax.net.debug=SSL SgSendRequest
```
能够看到，客户端提供了很多明码套件，服务端抉择了TLS_DHE_RSA_WITH_AES_128_GCM_SHA256，那么极有可能是印度机房不反对此明码套件，导致印度机房申请失败，可用 curl 确认下：
应用 curl 以指定明码套件 DHE-RSA-AES128-GCM-SHA256 拜访印度机房。
```
$ curl -v https://in.xxx.be.srv.com --ciphers DHE-RSA-AES128-GCM-SHA256
```
能够发现，印度机房的确不反对此明码套件。

注：jdk 明码套件名称与 curl 的名称略微有点不统一，curl 的能够在这里查找 https://curl.se/docs/ssl-ciph…

这也就是说，此 JDK 反对的密码学套件与印度机房反对的密码学套件没有交加，服务端无奈选出一个单方都反对的明码套件，能够进一步确认下，如下：
jdk 反对的明码套件能够通过 SSLServerSocketFactory.getSupportedCipherSuites() 获取。

$ bin/jrunscript -e "print(java.util.Arrays.toString(javax.net.ssl.SSLServerSocketFactory.getDefault().getSupportedCipherSuites()))"

印度机房反对的明码套件能够应用 nmap 扫描获取，如下：

$ nmap --script ssl-enum-ciphers -p 443 in.xxx.be.srv.com

通过我的查看，发现 jdk 的明码套件与印度机房的明码套件的确没有交加，印度机房只反对一些较新的明码套件，这就是调用印度机房服务时 SSL 握手失败的起因。

用雷同的办法，我也确认了新加坡机房，发现新加坡机房的明码套件与 jdk 的明码套件有交加，而 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 就在其中。

要解决这个问题也比拟容易，要么让调用方降级 jdk 以反对新的明码套件，要么让印度机房 SRE 调整 SSL 配置以反对旧的明码套件，咱们抉择了前者。

那么，还有一个问题，为啥我本人编译的同版本的 JDK 就没有问题呢？

有点蛊惑，我用下面雷同办法确认了一下我本人编译的 JDK 反对哪些套件，如下：

$ bin/jrunscript -e "print(java.util.Arrays.toString(javax.net.ssl.SSLServerSocketFactory.getDefault().getSupportedCipherSuites()))"

能够发现，我本人编译的 JDK，反对 ECDH 系列的新密码套件，这是为啥？

为了弄清区别，我应用问题 JDK 进行了调试，如下：

import javax.crypto.KeyAgreement;
import java.security.NoSuchAlgorithmException;

public class EcdhTest {public static void main(String[] args) throws NoSuchAlgorithmException {KeyAgreement ka = KeyAgreement.getInstance("ECDH");
        System.out.println(ka);
    }
}

在问题 JDK 外面，会报如下异样：

$ bin/java EcdhTest
Exception in thread "main" java.security.NoSuchAlgorithmException: Algorithm ECDH not available
        at javax.crypto.KeyAgreement.getInstance(KeyAgreement.java:184)
        at EcdhTest.main(EcdhTest.java:6)

有异样就好办了，只有顺着异样产生的过程调试上来即可，大略调试了如下相干办法：

sun.security.ssl.JsseJce.getKeyAgreement("ECDH")  
sun.security.ec.SunEC

当调试到 SunEC 类时，我发现在加载 sunec 动静库时会报错，如下：

于是，我去问题 jdk 目录下查找这个动静库文件，动静库文件在 Linux 下个别是 .so 结尾，如下：

$ find | grep sunec
./jre/lib/ext/sunec.jar
./jre/lib/amd64/libsunec.so_DISABLED
./jre/lib/amd64/libsunec.diz

懵逼了，在这个问题 JDK 里，libsunec.so居然被改名为了libsunec.so_DISABLED，而我看了下我本人编译的 JDK，这个文件是没有改名的！

终于，第二个问题也找到了起因，原来是网上找的这个 JDK，通过改名 libsunec.so 将 EC 系列算法禁用了。
我大略看了会那个 JDK 下载页面，这个 JDK 构建工夫挺久了，是 RedHat 晚期为 CentOS6 构建的一个 JDK8 版本，至于为啥要禁用 EC 系列算法，也没找到相干解释，只好就此打住。

这个问题在报错能被稳固重现进去时，其实就不难了，但排查思路与应用到的工具还是挺值得分享的，如下：