system.setProperty导致的https血案

system.setProperty导致的https血案

  • 现象
  • 排查
  • 思考
  • 建议

现象

系统外调签名服务突然无法使用,排查发起请求的服务正常,查看日志报recieve fatal alert: protocal_version, 当时大家没有深入研究代码,印象里最近没有动过服务,就网络抓包看,发现报错时,https协议从TLS变成了GMTLS,故认为网络有影响,问了网络同事,未遂。

排查

我介入的时候,前面的现象和调查已经都做了。我从头了解了一下情况,然后在交流中,知悉生产并没有问题,遂问区别在那里,此时,开发人员说测试拆分了前置服务,这块不一样,其他接口都已经运行了很久了。那我就提议,先停止新拆分的服务,使用旧服务,监控一下午看看,一下午均正常。
在监控的时候,我也去翻看了两个前置服务的代码,发现新拆分的服务,目前只有一个外调服务在用,使用了https双向证书。又回去看了之前的服务的代码,有好几个https外调,但这部分已经上线许久了,应该不是问题原因。于是,就对比了两个服务https的代码逻辑,发现了些许差异,唯一特别的是新服务用到了system.setProperty(“https.protocols”,“TLSv1”)。一开始并没有注意到这块,而是一直被GMTLS牵着走,想到原服务里的国密代码,是不是有影响。但不管那块,都需要验证,遂让开发人员在晚上对测试环境做了system.setProperty(“https.protocols”,“TLSv1”)代码移除。最后复现确实是这个引起的。

思考

问题虽然解决了,但是根本原因是什么,目前没有网上资料解释,本人做了一个猜测:如果原来使用TLS1.2 进行通讯,突然有代码降低了TLS版本,那么后续的TLS版本会根据通讯证书进行推断,也就是这个导致协议变成了GMTLS。为什么会推断成国密,我猜还是跟国密那部分代码有关系,此处最近验证一下。

建议

https 请求时,不用设置jvm参数,防止多处不同TLS协议的兼容问题;

你可能感兴趣的:(编程,https,网络协议,TLS)