TLS Version 1.0 and 1.1 Deprecation

Since Mailgun’s early days, we’ve made a point to ensure that our senders could send their emails as securely as possible. When we announced TLS support in 2014, we did this with the customer in mind, and we continue to do so now as we move to deprecate TLS 1.0 and 1.1 in favor of the more secure TLS version 1.2. 

That said, it’s important to note that on March 8, 2021, Mailgun will no longer allow TLS connections using the outdated 1.0 and 1.1 versions.

Why Deprecate TLS 1.0 and 1.1? 

The older TLS versions are riddled with security vulnerabilities. As such, these protocols are updated over time to patch out these vulnerabilities and keep users safe. TLS 1.0 came out in 1999 and has had many issues with heartbleed, POODLE, CRIME, etc. That said, it’s been a long time coming for companies to drop their support of 1.0 and 1.1.

When it comes to TLS deprecation, many other tech companies have chosen to sunset these old protocols as well. In March 2020, all four major internet browser providers ended their support of TLS 1.0 and 1.1 – which was a major push in the right direction for better security. While Mailgun isn’t the first or the last company to announce their TLS 1.0 and 1.1 support deprecation, now is the perfect time to check and make sure your environment supports 1.2 so you don’t experience any downtime.

If you’re already utilizing TLS 1.2 – great! Doing these sorts of maintenance updates is imperative, so getting ahead saves you some time in the future. If you aren’t sure if your environment supports TLS 1.2, now is an excellent time to double-check. 

It’s a simple process, but we’ve gone ahead and listed how you can check your TLS version with Mailgun below.

How to check if your environment supports TLS 1.2

The steps to check your environment’s TLS 1.2 support are pretty straightforward. We’ve listed the details on how to check via Linux and Windows systems below. If it does support 1.2, there are no further steps to follow as we’ll default to that version.  Should your environment not support TLS 1.2, you have some extra work ahead of you.

Linux

If you’re running your sending application on a Linux server, you can use the nmap utility to check which versions of TLS your stack supports. On your local machine, run the following command, replacing ‘api.mailgun.net’ with your own domain:

nmap --script ssl-enum-ciphers -p 443 api.mailgun.net

Here’s an example output for api.mailgun.net:

Starting Nmap 7.70 ( https://nmap.org ) at 2020-09-11 13:39 CDT

Nmap scan report for api.mailgun.net (3.220.71.10)

Host is up (0.047s latency).

Other addresses for api.mailgun.net (not scanned): 34.198.11.146 3.93.126.5 52.87.122.201 52.7.64.51 3.226.21.161 52.7.38.97 34.199.221.7

rDNS record for 3.220.71.10: ec2-3-220-71-10.compute-1.amazonaws.com

PORT    STATE SERVICE

443/tcp open  https

| ssl-enum-ciphers:

|   TLSv1.0:

|     ciphers:

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

|     compressors:

|       NULL

|     cipher preference: server

|   TLSv1.1:

|     ciphers:

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

|     compressors:

|       NULL

|     cipher preference: server

|   TLSv1.2:

|     ciphers:

|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A

|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A

|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A

|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A

|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A

|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A

|     compressors:

|       NULL

|     cipher preference: server

|_  least strength: A

As you can see in the output above, api.mailgun.net supports TLSv1.2, so I’m good to go. As long as you get a similar output showing TLSv1.2, then so are you!

If not, then you’ll want to start by updating Apache/Nginx and OpenSSL and/or updating your nginx.conf or Apache configuration files to enable TLSv1.2.

Windows

For you .NET users, first off, you’ll want to ensure your server supports TLS 1.2.  If you’re running Server 2008 or 2012, TLS 1.2 support was not available by default, so you’ll want to make sure you have the relevant updates installed in order to support TLS 1.2. If you’re running Server 2012 R2 or 2016, TLS 1.2 should already be installed and default. 

Next, we highly recommend updating all of your applications to use the .NET 4.6 or higher framework, as these support TLS 1.2 and are set by default. If not, you may be able to use the following workarounds for older versions of .NET:

1. .NET 4.5. TLS 1.2 is supported, but it’s not a default protocol. Using the following code will make TLS 1.2 default. You’ll need to execute this code before making a connection to any secured resource:

System.Net.ServicePointManager.SecurityProtocol |= SecurityProtocolType.Tls12;

2. .NET 4.0. TLS 1.2 is not supported, but if you have .NET 4.5 (or higher) installed on the same system then you still can opt in for TLS 1.2. Since the SecurityProtocolType in .NET 4.0 doesn’t have an entry for TLS1.2, you’ll have to use a numerical representation of this enum value:

ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;

Or use the following registry hack.

3. .NET 3.5 or below. Ensure you have the following updates, as well as the registry keys.

As we make these changes and migrations to newer versions in the future, remember that we always have you in mind. With blog posts and email reminders, we aim to make sure no customer gets caught by surprise.