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

简介

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

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

  1. SSL握手过程
  2. SSL握手异样时的排查思路与工具
  3. 同版本的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个疑难了，如下：

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

为啥SSL握手报错？

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

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

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

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

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

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

  1. 增加JVM参数-Djavax.net.debug=SSL，并调用失常的新加坡机房，看看SSL握手抉择的是什么明码套件。

    $ bin/java -Djavax.net.debug=SSL SgSendRequest


    能够看到，客户端提供了很多明码套件，服务端抉择了TLS_DHE_RSA_WITH_AES_128_GCM_SHA256，那么极有可能是印度机房不反对此明码套件，导致印度机房申请失败，可用curl确认下：

  2. 应用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没有问题？

有点蛊惑，我用下面雷同办法确认了一下我本人编译的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 EcdhTestException 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系列算法，也没找到相干解释，只好就此打住。

总结

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

  1. 客户端与服务端反对的明码套件没有交加，会导致SSL握手失败。
  2. 应用-Djavax.net.debug=SSL能够调试java的SSL握手过程。
  3. 通过curl --ciphers指定客户端明码套件拜访服务端，能够确认服务端是否反对此明码套件。
  4. 通过SSLServerSocketFactory.getSupportedCipherSuites()可获取JDK反对的明码套件。
  5. 应用nmap --script ssl-enum-ciphers可扫描出服务端反对的明码套件。
  6. 同样版本的JDK，不同发行商发行的，也可能存在着差别。

往期内容

一次IOS告诉推送问题排查全过程
密码学入门
接口偶然超时，竟又是JVM进展的锅！
耗时几个月，终于找到了JVM进展十几秒的起因
mysql的timestamp会存在时区问题？
真正了解可反复读事务隔离级别
字符编码解惑