一次SSL握手异常，我发现JDK还有发行版区别

最近，我们一个多机房部署的服务，调用方反馈有问题，在调用新加坡机房时正常，而调用印度机房则报SSL握手异常。,排查花了一些时间，同时也积累了一些经验，故记录一下，读完本文，你将了解到如下内容：,废话不多说，往下看…,调用方调用印度机房服务时，报错信息如下：,,这个异常是同事一直在看，经过一翻搜索，怀疑是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/ojdkbuild/releases/download/1.8.0.91-3/java-1.8.0-openjdk-1.8.0.91-1.b14.el6.x86_64.zip,弄到1.8.0_91-b14版JDK后，我和同事都进行了测试，奇怪的是，同事网上找的JDK重现了调用方的报错，即新加坡机房正常，而印度机房SSL握手失败，但我自己编译的JDK则两个机房都正常，我们可是相同版本的JDK啊！,好家伙，现在有2个疑问了，如下：,为啥新加坡机房正常，而印度机房SSL握手报错？,为啥相同版本的JDK，自己编译的没有问题？,粗略来讲，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握手选择的是什么密码套件。,,可以看到，客户端提供了很多密码套件，服务端选择了TLS_DHE_RSA_WITH_AES_128_GCM_SHA256，那么极有可能是印度机房不支持此密码套件，导致印度机房请求失败，可用curl确认下：,使用curl以指定密码套件DHE-RSA-AES128-GCM-SHA256访问印度机房。,,可以发现，印度机房确实不支持此密码套件。,注：jdk密码套件名称与curl的名称稍微有点不一致，curl的可以在这里查找 https://curl.se/docs/ssl-ciphers.html,这也就是说，此JDK支持的密码学套件与印度机房支持的密码学套件没有交集，服务端无法选出一个双方都支持的密码套件，可以进一步确认下，如下：,jdk支持的密码套件可以通过SSLServerSocketFactory.getSupportedCipherSuites()获取。,,印度机房支持的密码套件可以使用nmap扫描获取，如下：,,经过我的检查，发现jdk的密码套件与印度机房的密码套件确实没有交集，印度机房只支持一些较新的密码套件，这就是调用印度机房服务时SSL握手失败的原因。,用相同的方法，我也确认了新加坡机房，发现新加坡机房的密码套件与jdk的密码套件有交集，而TLS_DHE_RSA_WITH_AES_128_GCM_SHA256就在其中。,要解决这个问题也比较容易，要么让调用方升级jdk以支持新的密码套件，要么让印度机房SRE调整SSL配置以支持旧的密码套件，我们选择了前者。,那么，还有一个问题，为啥我自己编译的同版本的JDK就没有问题呢？,有点迷惑，我用上面相同方法确认了一下我自己编译的JDK支持哪些套件，如下：,,可以发现，我自己编译的JDK，支持ECDH系列的新密码套件，这是为啥？,为了弄清区别，我使用问题JDK进行了调试，如下：,在问题JDK里面，会报如下异常：,有异常就好办了，只要顺着异常产生的过程调试下去即可，大概调试了如下相关方法：,当调试到SunEC类时，我发现在加载sunec动态库时会报错，如下：,,于是，我去问题jdk目录下查找这个动态库文件，动态库文件在Linux下一般是.so结尾，如下：,懵逼了，在这个问题JDK里，libsunec.so​竟然被改名为了libsunec.so_DISABLED，而我看了下我自己编译的JDK，这个文件是没有改名的！,终于，第二个问题也找到了原因，原来是网上找的这个JDK，通过改名libsunec.so将EC系列算法禁用了。,我大概看了会那个JDK下载页面，这个JDK构建时间挺久了，是RedHat早期为CentOS6构建的一个JDK8版本，至于为啥要禁用EC系列算法，也没找到相关解释，只好就此打住。,这个问题在报错能被稳定重现出来时，其实就不难了，但排查思路与使用到的工具还是挺值得分享的，如下：