The Time Has Arrived: Upgrading to TLS Version 1.2 or Newer

The time has arrived to upgrade to TLS 1.2, if you have not already done so for any of your systems. At Circonus, we will be dropping support across our platform for all connections using TLS versions less than 1.2 on January 21, 2021. Virtually none of our customers will be impacted by this change, as this has been in the works for a very long time, and most customers will have made this transition already.

If you are not sure whether you are connecting to any Circonus platform interfaces using any version of TLS older than version 1.2, it would be worth checking that out and updating those connections. This includes services that submit metrics data to an HTTPTrap check, as well as those that interact with the Circonus API. Simple instructions to check this are provided later in this blog post.

This is important to consider for several reasons. Obviously, one reason is that since Circonus will no longer support older versions of TLS, it will be important to upgrade to keep all of your systems correctly monitored by Circonus. But beyond that, older versions of TLS simply no longer provide adequate security. TLS 1.2 has been the recommended protocol for over 10 years. All older versions have been officially deprecated by the IETF.

Thus far, Circonus has continued to support older versions of TLS, in order to provide a grace period for all of our customers to upgrade any required systems. Analysis of incoming traffic indicates that virtually none of our partners are still using the old versions of TLS. So, we are ready to move forward with deprecating older versions of TLS at this time.

There are some simple steps that can be taken to ensure that you are using TLS version 1.2 or above. One easy method is to use the nmap utility. From a system that is used to connect to Circonus servers, you can run a command similar to the following:

$ nmap --script ssl-enum-ciphers -p 443 api.circonus.com

If you run the on-premises version of Circonus, replace the “api.circonus.com” host name with the name of the host for your Circonus API installation.

The output of this command will be similar to the following:

Starting Nmap 7.91 ( https://nmap.org ) at 2021-01-05 18:57 EST
Nmap scan report for api.circonus.com (35.201.69.199)
Host is up (0.029s latency).
rDNS record for 35.201.69.199: 199.69.201.35.bc.googleusercontent.com

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       64-bit block cipher 3DES vulnerable to SWEET32 attack
|_  least strength: C

Nmap done: 1 IP address (1 host up) scanned in 2.64 seconds

The presence of the TLSv1.2 section indicates that the system is able to communicate with the Circonus API using a new enough version of TLS. If that section is not present, that indicates that an update is required.

Another method that can be used to detect if the version of TLS is new enough is to use the curl command. This can be useful on servers where nmap cannot be installed. The following command can be run:

$ curl https://api.circonus.com/ --tlsv1.2 --verbose

The output of the command, if successful will look something like the following:

* About to connect() to api.circonus.com port 443 (#0)
*   Trying 35.201.69.199...
* Connected to api.circonus.com (35.201.69.199) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=*.circonus.com,OU=PremiumSSL Wildcard,O="CIRCONUS, INC.",STREET=11850 W MARKET PL STE A,L=Fulton,ST=MD,postalCode=20759,C=US
*       start date: Dec 22 00:00:00 2017 GMT
*       expire date: Feb 19 23:59:59 2021 GMT
*       common name: *.circonus.com
*       issuer: CN=COMODO RSA Organization Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> GET / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: api.circonus.com
> Accept: */*
>
< HTTP/1.1 302 Found
< Date: Wed, 06 Jan 2021 00:10:27 GMT
< Server: Apache
< Location: https://login.circonus.com/resources/api
< X-Circonus-API-Version: 2.00
< X-Circonus-Server: api1-gcp-ia
< X-Circonus-Tag: tag1kwwPD2yOnfE
< Content-Length: 362
< Content-Type: text/html; charset=utf8
< Via: 1.1 google
< Alt-Svc: clear
…

If the connection fails, an error message will be displayed, and that indicates that the version of TLS installed on the system is not new enough.

If you find that you need to upgrade to a newer version of TLS, the process for doing so is dependent on your operating system. If you are using one of the Linux operating systems, you will most likely need to update OpenSSL. The instructions for doing so vary by individual OS, so it would be a good idea to check with your system administrator or the OpenSSL instructions for your operating system before attempting to perform the upgrade.

However, the steps will be something like the following:

Step 1

You can verify the version of OpenSSL that is running on your machine with the following command:

$ openssl version

And the response will be something like the following:

OpenSSL 1.0.2n 7 Dec 2017

TLS 1.2 is supported on OpenSSL version v1.0.1 or later. If your OpenSSL version is below that version, then you’ll need to upgrade your OpenSSL package.

Step 2

If you are using Linux as your operating system, you need to know which distribution you are using. You can run the following command to determine your distribution:

$ cat /etc/*-release

And, the response to this command will be something like the following:

CentOS release 6.5 (Final)

You may upgrade your Linux system to the minimum distribution which supports OpenSSL v1.0.1 or later, before upgrading the OpenSSL package.

On Debian

You’ll need to upgrade your Operating system to Debian 7 (Wheezy) or later.

On Ubuntu

You’ll need to upgrade your Operating system to Ubuntu 12.04 (Precise) or later. If you already on Ubuntu 12.04 or later, you could upgrade OpenSSL package by running the command:

$ sudo apt-get update && sudo apt-get install --only-upgrade openssl libssl-dev

Restart your server once the OpenSSL upgrading process is finished.

On RedHat Enterprise Linux, or CentOS

You’ll need to upgrade your Operating system to CentOS 6 / Red Hat Enterprise Linux 6 or later. If you are already using CentOS 6 / Red Hat Enterprise Linux 6 or later, you could upgrade OpenSSL package by running the command:

$ sudo yum update openssl

Restart your server once the OpenSSL upgrading process is finished.

Step 3

Once upgrading process is done, you should re-check OpenSSL package version by running the following command:

$ openssl version

You’ll see your OpenSSL package has been upgraded.

Once again, it is recommended that you consult specific instructions for your individual operating system before attempting to upgrade OpenSSL or any other components.

While our research shows that most customers will not be affected by this change, it does not hurt to be on the safe side, and check to verify that you will not lose connectivity when Circonus drops support for TLS versions 1.1 and below. There are lots of good security reasons to verify this besides just ensuring that you won’t lose your connections to Circonus.

And besides, it is a new year and that’s a great opportunity to check that you are up to date with the latest security requirements.