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协议的兼容问题；