Note: TLS 1.2 Sunsetting

API Q&A
1

Good morning!

With our latest upgrades we will be defaulting to TLS 1.3 (introduced in 2018) for secure connections with remote services, as TLS 1.2 is now considered insecure. For backwards compatibility we will continue to support TLS 1.2 for now, but you should upgrade packages that include it to their latest versions at your earliest convenience, both for compatibility with our services and as a general security precaution to safeguard your traffic.

To check to see if your service supports TLS 1.3 without digging through configuration you can use the openssl client with the following command and see if the Protocol line outputs a response:

openssl s_client -connect www.google.com:443 -tls1_3 2>/dev/null | grep ‘Protocol’

1 Like
2

@Tom_Scott - The command needed a bit more refining and explanation.

By adding the "echo | " prefix you will get a response of “Protocol : TLSv1.3” if TLS v1.3 is active, otherwise No Response is given.

TLS v1.3 - If you get no response, you will need to upgrade to TLS v1.3.

echo | openssl s_client -connect www.google.com:443 -tls1_3 2>/dev/null | grep 'Protocol'

TLS v1.2 - If you get a response of “Protocol : TLSv1.2”, you will need to upgrade to TLS v1.3.

echo | openssl s_client -connect www.google.com:443 -tls1_2 2>/dev/null | grep 'Protocol'

When is the sunset due?

Older Microsoft Windows Servers may be more impacted with this change.

3

We have not set a finalized date for shutting off support for TLS 1.2 yet; this is a pre-emptive notification due to ongoing Java SDK updates that exposed the concern, specifically in the Apache httpcomponents libraries.

4

If you are using a SAK and posting via cURL, then wouldn’t we need to test the cURL connection?

curl -v https://google.com 2>&1 | grep "SSL connection using"