fix(http): enable TLSv1.3; disable TLSv1.0 TLSv1.1

[ricellis]

The setupTLSProtocol function in HttpClientSingleton was hard-coded to TLS_1_0 TLS_1_1 TLS_1_2 thus preventing negotiation to TLSv1.3 even if it was available in the supported protocols for the socket and on the server.

Since configureHttpClient is using the MODERN_TLS connection spec anyway this change determines the set of protocols to enable from the union of the protocols listed in MODERN_TLS and the protocols supported by the socket.

It should be noted that:

• The protocols allowed by MODERN_TLS gets updated with OkHttp updates (as such updating in future may disable additional protocols or enable new ones if they are also supported by the runtime environment).
• MODERN_TLS currently allows only TLSv1.2 and TLSv1.3.

So this change will also disable TLSv1.0 and TLSv1.1 connections, but that should not pose a problem as we should be using TLSv1.2 minimum since 1.0 and 1.1 have known insecurities and are considered deprecated.

I added a test to validate that each enabled protocol on a socket created from the configured client was valid against both the MODERN_TLS list and the supported protocols list from the socket.

I also noticed that when using disableSslVerification the [existing] protocol filtering was not applied. I did not see a reason that the same protocol set should not be used even if the certificates and hostnames were going to be universally trusted. I've made that change and added a test for it in a separate commit so if others disagree it can be easily removed.

[CLAassistant]

All committers have signed the CLA.

[padamstx]

Looks great, @ricellis !
Is this ready to merge?

[ricellis]

Is this ready to merge?

I marked it as fix because it should be transparent given using TLSv1.2 min in services anyway, but I suppose there is a risk that some test environment somewhere that uses disableSSLVerification and doesn't provide TLSv1.2 might see a break. Personally I think that's an acceptable risk and assuming others agree then yes, this is ready to merge.

[padamstx]

I think that's an acceptable risk and assuming others agree then yes, this is ready to merge.

agreed

I've tested this version of the java core with the platform-services java sdk (ran integration tests for several of the services) and all seems to be working well.

@ricellis Thank you for contributing this change!

[ibm-devx-sdk]

🎉 This PR is included in version 9.10.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀