TLS Basics: What is TLS connection control?

What would you discuss over a secure line? Some James Bondian plans?

Chances are, you’d more likely be doing something mundane, like scheduling your next meeting or online shopping. Whether or not you’re aware of it, encryption is already part of your email communication, and every email you send is essentially like chatting on a secure line.

Even though there are a variety of encryption protocols, most email clients, like Gmail, have made Transport Layer Security (TLS) encryption an essential part of their protocols. But what is TLS, and why is it important for email campaign managers to fine-tune their TLS connection control? We’ll dig into that now.

Let’s start with some basics. You probably know that sending without encryption is risky, but what could actually happen if your message wasn’t encrypted? Here are some common cybersecurity problems you’d face if you sent and received emails without encryption:

• Message tampering: Encryption protects the transmission of secure data and enables the recipient to see if the message was modified in transit.
• Eavesdropping: Anyone can capture and read your emails as they travel through the network. Without encryption, you’d have no privacy. In more technical terms, this prevents man-in-the-middle attacks.
• Privacy invasion: Unencrypted emails also transmit sensitive information, like your IP address, your city, or even your street address, which could also compromise your privacy.
• Identity theft:Hackers could potentially capture your login details if you aren’t accessing your email server or website over an encrypted connection.

Below, we’ll learn about TLS and how to work it into your email routine.

TLS is a cryptographic protocol that provides end-to-end security of data sent between web applications and web servers over the internet. It encrypts the connection through which data is sent over the internet, preventing third parties from seeing your data, like passwords, credit card numbers, and personal correspondence. In short, sending a message over the TLS protocol is like talking openly over a secured phone line.

Before diving into what exactly is TLS, let’s start with a brief history lesson.

The Internet Engineering Task Force (IETF) defined TLS 1.0 in 1999. Before that, the Secure Socket Layer (SSL) was the standard encryption protocol for the internet. Currently, SSL certificates just mean that a particular website is using some sort of cryptographic protocol to verify their ownership of the domain, a role which TLS fulfills. In fact, the SSL certificate should be more appropriately called a TLS certificate since it uses TLS, not SSL.

Don’t worry – the TLS used by modern systems isn’t actually from 1999. TLS versions 1.0 and 1.1 were deprecated in 2020 and are no longer used by most email service providers. Today,  TLS 1.3 is the current protocol version and TLS 1.2 continues to be supported.

TLS is the encryption protocol for securing most of the internet, and its easy to spot which sites are or aren’t compliant. Take a look at the URL for this article and notice how it starts with “https” and has a closed gray padlock icon. Connections secured by TLS are labeled Hypertext Transfer Protocol Secure (HTTPS) instead of just HTTP.

Ancient history aside, TLS is important because there are three main things the protocol enables:

• Encryption: TLS secures the data in your emails from third parties.
• Authentication: TLS authenticates the server (and optionally, the client) from which a message is being sent.
• Integrity: TLS verifies the data integrity to check it’s free from forgery and tampering.

All of these work together to ensure a secure end-to-end email experience for both you and your subscribers.

Constant vigilance is the key to preventing data breaches and other cybersecurity attacks. Use TLS encryption to strengthen your business’s data security over the web and in email marketing campaigns and in transactional emails. Most browsers will also alert users if your website or email communications aren’t secure, which could lead to lower web traffic and could make your brand look less legitimate.

Although TLS provides adequate security for communications, your business may need extended authentication to provide increased protection for sensitive data. In these cases, your organization can opt for business-level authenticationTLS/SSL certificates, which come in the following three security levels:

• Domain validation certificates: This is the most basic TLS/SSL certificate, which requires you to prove that you control the domain name you’ve supplied. Keep in mind that the domain validation certificate doesn’t confirm the identity of you or your business.
• Organization validation certificates: This certificate builds off of the domain validation certificate. Not only does it require you to prove that you control the domain name you’ve supplied, but it also requires you to prove that your company is legally registered as a business. We recommend this for public-facing sites that collect data from your users.
• Extended validation certificates: This is the most secure TLS/SSL certificate. In addition to proving ownership of your domain name and establishing the legality of your company, these certificates include additional verification steps designed to protect data from tampering.

Now that we know what TLS is, let’s go over how exactly the TLS protocol works to secure your online communication.

Modern TLS, including versions 1.2 and 1.3, use two types of cryptography to maintain high performance along with reliable security:

• Symmetriccryptography: This encrypts data using a secret key that has been shared with both the sender and the recipient. Keep in mind this secret key should be at least 128 bits in length.
• Asymmetriccryptography: This encrypts data with key pairs made up of a private key and a public key. Asymmetric cryptography is more secure than just using a secret key, but it also demands a greater bandwidth since the recommended minimum key length is 1024 bits.

TLS uses asymmetric encryption to establish a secure session between a client and a server. Then, it uses symmetric encryption to exchange data within the secured session. This process is defined as the TLS handshake: the process by which communication between a client and server is established and defined.

In other words, the TLS handshake process is a negotiation between the email client or web browser that sends your message and the web server it interacts. The two sit down and acknowledge each other, authenticate each other’s identities, designate encryption algorithms, and agree upon secure session keys.

Here’s how a TLS 1.3 handshake works:

1. The client contacts the server with a “client hello” message. This message alerts the server to the client’s TLS version to check for compatibility. It also shares a key and the client’s cipher suites. From there, the key is used to encrypt and decrypt messages.
2. The server responds to the client’s message and shared key with a “server hello” message. This message shares a key in response and indicates the server’s supported versions. The server may also request a TLS/SSL certificate and verifies it.
3. The client receives the certificate and verifies it, completing the client-side portion of the TLS handshake.

Now, the client can communicate with the server using a HTTP protocol.

Mailgun implements an opportunistic TLS by default. Whenever we connect to a mail exchange (MX) server, we first try to upgrade the connection to a TLS connection to deliver your messages. However, if it’s not offered or some kind of error occurs while establishing the connection (like an invalid certificate, for example), we use a plaintext SMTP connection instead.

We’ve also implemented ways for you to customize your connection settings for message delivery by:

• Exposing a new flag to ensure messages are only delivered over a TLS connection.
• Allowing you to enable or disable certificate verification.
• Exposing the MX server we delivered the message to, the TLS state of the connection, and whether or not we verified the certificate during delivery in our Logs.

Let’s dive into each of these below.

We’ve exposed a new flag – require tls – that allows you to control how your messages are delivered. Set this flag to True to require that the message must be sent over a TLS connection. If a TLS connection can’t be established, Mailgun won’t deliver the message.

The default for require tls is False, which means we will try to use a TLS connection but will still deliver your email over a plaintext SMTP connection if we can’t use TLS.

The new flag skip verification allows you to enable or disable certificate and hostname verification. If set to True, Mailgun won’t verify the certificate and hostname when trying to establish a TLS connection. Instead, Mailgun will accept any certificate during delivery.

By default, skip verification is set to False, which means that we’ll try to verify the certificate and if we can’t, a TLS connection won’t be established.

We’ve exposed three additional flags in our Logs which provide insight into how your email was delivered. First, navigate to the delivery-status document. Then, look for the following flags:

• tls: This flag indicates whether or not we used a TLS connection to deliver your message.
• certificate-verified: This flag indicates whether or not we verified the certificate when delivering your message.
• mx-host: This indicates the MX server we connected to deliver your message.

Let’s put the flags above into practice. In this section, we’ll go through examples of sending emails with custom connection settings in Mailgun, including:

• Sending a single message with custom connections.
• Configuring an entire sending domain to deliver messages with custom connections.
• Checking your configuration.

If you have a single message you’d like to deliver with custom connection settings, you can use the code below:

                            

                                curl -sk --user 'api:API_KEY'   
    https://api.mailgun.net/v3/DOMAIN_NAME/messages 
    -F from='foo@example.com' 
    -F to='bar@example.com' 
    -F subject='Hello' 
    -F text='Testing some Mailgun awesomness!' 
    -F o:require-tls='false' 
    -F o:skip-verification='true'
                            
                        

If you’d like to configure an entire sending domain to deliver messages in a particular manner, check out the code below:

                            

                                curl -sk --user 'api:API_KEY'   
    -X PUT https://api.mailgun.net/v3/domains/DOMAIN_NAME/connection 
    -F require_tls='false' 
    -F skip_verification='true'
                            
                        

Alternatively, you can also change your domain settings for any specific domain via the Mailgun control panel. To do so, navigate over to your sending tab and scroll down to `domain settings`, from there you can change your TLS settings under the `security` section.

Worried you made a mistake? You can check that your configuration was correct with the code below:

                            

                                curl -sk --user 'api:API_KEY'   
    -X GET https://api.mailgun.net/v3/domains/DOMAIN_NAME/connection
                            
                        

And that’s it! We’ve learned how the TLS protocol works and some ways you can customize your connection settings with Mailgun.

If you’re interested in learning more, check out our documentation here, or sign up for a free trial.

Author: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!