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

简介

最近,我们一个多机房部署的服务,调用方反馈有问题,在调用新加坡机房时正常,而调用印度机房则报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/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握手报错?

粗略来讲,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-ciphers.html

这也就是说,此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 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系列算法,也没找到相关解释,只好就此打住。

总结

这个问题在报错能被稳定重现出来时,其实就不难了,但排查思路与使用到的工具还是挺值得分享的,如下:

  • 客户端与服务端支持的密码套件没有交集,会导致SSL握手失败。
  • 使用-Djavax.net.debug=SSL可以调试java的SSL握手过程。
  • 通过curl --ciphers指定客户端密码套件访问服务端,可以确认服务端是否支持此密码套件。
  • 通过SSLServerSocketFactory.getSupportedCipherSuites()可获取JDK支持的密码套件。
  • 使用nmap --script ssl-enum-ciphers可扫描出服务端支持的密码套件。
  • 同样版本的JDK,不同发行商发行的,也可能存在着差异。

当前文章:一次SSL握手异常,我发现JDK还有发行版区别
当前网址:http://www.shufengxianlan.com/qtweb/news8/476358.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联