If it is true (Does URLConnection support TLS 1.2 out of the box? - #2 by Greg_O_Lone) that URLConnection uses "whatever the OS is capable of", how can I force the use of TLS 1.2?
Specifically, I run some applications (console and web) on Windows Server 2016 (which, by default, has TLS 1.0, TLS 1.1, and TLS 1.2 protocols enabled).
Following several similar guides on the Internet, I tried disabling TLS 1.0 and TLS 1.1 in the Windows registry, also setting TLS 1.2 as the default protocol.
But (according to the service provider’s logs) it seems that URLConnection still does NOT use TLS 1.2.
The provider is only giving me a few days to change the configuration, after which it will block access if I don’t switch to TLS 1.2.
I hope I’m not left "at the mercy" of Windows Server settings…
Has anyone had similar experiences or can Xojo staff clarify the problem and suggest a stable solution?
thank you.
IIRC, in some older Windows OSes, you needed to enable TLS 1.2 because it was experimental.
Internet Options -> Advanced > Use TLS 1.2
If not, this article shows three ways to enable it using the registry, powershell or CMD.
Otherwise, you shouldn’t need to do anything. URLConnection negotiates with the other end to make the best connection that the two can agree on.
TLS 1.2, TLS 1.1, and TLS 1.0 are enabled by default in Windows Server 2016.
there are many guides on the internet (including the one @Greg_O pointed out), but in the end there seems to be no way to disable TLS 1.1 and TLS 1.0
difficult to understand the reasons. operating systems are complex. moreover, with all the updates made over the years, they become even more so.
my question to the community: can URLConnection be forced to use TLS 1.2?
if not, it is a big trouble. URLConnection is easy to use, but if you’re left at the mercy of the OS, it’s more troubles than benefits.
Note: as I write this, I assume that other libraries (cURL etc.) are independent from the O.S. I don’t know if this is true.
In which case, the server that you are connecting to should be negotiating for a TLS 1.2 connection. The typical way these things work is to start with the most restrictive security and work downward, as in 1.2, 1.1 and then 1.0 if all else fails.
I see only three possibilities with what we know:
- The server you are connecting to is not suggesting 1.2 before the others.
- The TLS 1.2 library is not enabled on your server for some reason
- The TLS 1.2 library is somehow corrupt and can’t be used
Looking at this article, it might be worth checking if there are any specific overrides on your system:
It looks like you’re looking for:
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client
With a key of Enabled set to either 1 or 0.
If this entry does not exist, it simply means that the system settings are used.
Switching a (D)TLS or SSL protocol version to Disabled state may cause AcquireCredentialsHandle calls to fail due to the lack of protocol versions enabled system-wide and at the same time allowed by particular SSPI callers. In addition, reducing the set of Enabled (D)TLS and SSL versions may break interoperability with remote peers.
In other words, If this server is a VPN somewhere, you could lock yourself out if your connection relies on the version that you disable.