You may have heard the terms SSL and TLS, but do you know what they are and how they’re different?
SSL (Secure Sockets Layer) and TLS (Transport Layer Security) are methods of securing (encrypting) the connection between a mail client and mail server (Outlook and MDaemon, for example) or between mail servers (MDaemon and another mail server, for example). They’re also the technology that secures the connection between a website and your browser. In this post, we’ll focus on their use for encrypting email connections.
Without SSL or TLS, data sent between mail clients and servers would travel in plain text. That potentially opens up your business to theft of confidential information, stolen credentials, and accounts being hijacked to send spam. SSL and TLS help protect that data, allowing users to securely transmit sensitive information such as Social Security numbers, credit card numbers, or medical records over email.
A quick note on terminology before we go further: although nearly everyone still says “SSL,” the SSL protocol itself is obsolete. Every secure connection made today actually uses TLS. The “SSL” name has simply stuck around in everyday language (and in phrases like “SSL certificate”), so when you see SSL and TLS used together, think of TLS as the modern protocol doing the real work.
How do SSL and TLS work?
To use TLS, you’ll need an SSL/TLS certificate installed on the server. The certificate contains a public key and is paired with a private key kept secret on the server. Together they let a client confirm it’s talking to the genuine server and establish an encrypted connection.
When a mail client or server connects to another server using TLS, the secure connection is set up through a process called the “TLS handshake.” During the handshake the two sides agree on which protocol version and cipher to use, the client verifies the server’s certificate, and both sides cooperatively generate a shared session key. The public/private key pair is only used during the handshake to authenticate the server and safely establish that session key. Once the secure connection is in place, all transmitted data is encrypted with the symmetric session key.
This diagram provides a simplified overview of how a TLS connection is established:
Both SSL and TLS protect data privacy through data-in-motion encryption, provide server-side and (optionally) client-side authentication of the communication channel, and help ensure message integrity.
Note: In addition to encryption of the connection via TLS, MDaemon can be configured to encrypt the actual email message (not just the connection) using OpenPGP. More info can be found here: https://knowledge.mdaemon.com/enable-and-configure-mdaemon-pgp.
Email ports and encryption
POP, IMAP, and SMTP traffic is transmitted over designated ports, and there’s a dedicated encrypted port for each protocol:
- IMAP uses port 143 for unencrypted connections and port 993 for IMAP over TLS.
- POP3 uses port 110 for unencrypted connections and port 995 for POP3 over TLS.
- SMTP uses port 25 for server-to-server mail delivery. For mail submission from a client, port 587 is the standard submission port (typically secured with STARTTLS), and port 465 is used for submission with TLS active from the moment the connection opens.
For encryption to take place over these connections, the mail client and mail server must both be configured to use the proper ports, and a valid certificate must be installed on the server.
Note: Here's how to enable and configure SSL & TLS in MDaemon: https://knowledge.mdaemon.com/how-to-enable-configure-ssl-tls-for-smtp-pop3-imap-in-mdaemon
You’ll notice there are two ways to add encryption here, which brings us to an important distinction.
STARTTLS vs. Implicit TLS
There are two ways a mail connection can become encrypted:
STARTTLS (explicit TLS). The client first connects on a normal “plaintext” port (such as 587 for submission, 143 for IMAP, or 110 for POP3), then issues a STARTTLS command (STLS for POP3) to upgrade that connection to an encrypted one before any sensitive data is sent.
Implicit TLS. The client connects to a dedicated port (465 for submission, 993 for IMAP, 995 for POP3) and the TLS handshake happens immediately, before any other commands are exchanged. The connection is encrypted from the very first byte.
The catch with STARTTLS is that it’s opportunistic by default: the brief plaintext moment before the upgrade gives a network attacker a window to strip out the STARTTLS offer and trick the two sides into never encrypting at all (a “downgrade” or “STRIPTLS” attack). Because of this, RFC 8314 now recommends preferring implicit TLS where possible, and recommends configuring clients to require TLS so they refuse to send mail in the clear if encryption can’t be negotiated. (This is also why port 465, once deprecated, was officially brought back for submission with implicit TLS.)
MDaemon supports both approaches. It implements STARTTLS over TLS for SMTP and IMAP and STLS for POP3, as well as implicit TLS on the dedicated ports. You can also use MDaemon’s STARTTLS List and No STARTTLS List to specify hosts and addresses that must, or must not, use STARTTLS.
What are the differences between SSL and TLS?
TLS is the successor to SSL. It was introduced in 1999 as an upgrade to SSL 3.0. TLS 1.0 is so similar to SSL 3.0 that it was sometimes called “SSL 3.1”, but the two are not interoperable. The SSL protocol came in versions 2.0 and 3.0, while TLS has progressed through 1.0, 1.1, 1.2, and 1.3 (the current version).
Because the protocols aren’t interoperable, the client and server negotiate which one to use at the start of the handshake. Older guidance used to suggest “falling back” to SSL 3.0 when a newer protocol wasn’t available. That advice is now obsolete and unsafe, since SSL 3.0 is broken (more on that below).
Without getting too deep into the technical weeds, the main improvements TLS introduced over SSL are:
- More detailed alerts. TLS defines a richer set of alert and error messages than SSL did, which makes connection problems easier to diagnose.
- Stronger message authentication. TLS uses HMAC to verify that a message hasn’t been altered in transit, which works with a wider range of hash functions than SSL’s older MAC approach.
- Modernized cipher suites. TLS supports a different and stronger set of cipher suites - the combinations of key exchange, authentication, encryption, and integrity algorithms used to secure a connection. TLS 1.3 in particular removed every legacy, weak option and keeps only a small set of strong, modern ones.
Why are SSL and TLS important?
Businesses have a responsibility to protect financial data such as credit card information, along with consumer records like names, addresses, phone numbers, and medical information. Without some form of encryption, whether an encrypted connection using TLS, or encrypting the message itself with a tool like OpenPGP, sensitive data can be vulnerable to interception and other forms of unauthorized access.
Which version is recommended?
A lot has changed since the early days of SSL, and several older protocols are now considered unsafe:
- SSL 2.0 and SSL 3.0 are obsolete and should be disabled. SSL 3.0 in particular suffers from the well-known POODLE vulnerability (Padding Oracle On Downgraded Legacy Encryption). SSL 2.0 was deprecated back in 2011, and SSL 3.0 in 2015.
- TLS 1.0 and TLS 1.1 are also deprecated. The major browsers disabled them in 2020, and the IETF formally retired them in RFC 8996 in 2021. Most compliance frameworks (such as PCI DSS) no longer permit them.
Our recommendation: use TLS 1.2 as a minimum, and prefer TLS 1.3 wherever it’s supported. TLS 1.3 is the current standard. It’s faster, drops all the old weak algorithms, and builds in protections like forward secrecy by default. Running TLS 1.3 with TLS 1.2 available as a fallback for older clients is today’s best practice.
On Windows, the protocols and ciphers that MDaemon and SecurityGateway can use depend on the operating system, and they’re controlled through the Windows registry. A simple way to enable the right protocols and disable the obsolete ones is the free IIS Crypto tool, which sets the appropriate registry keys for you: https://www.nartac.com/Products/IISCrypto
Going further: protecting mail between servers
Encrypting the connection is the foundation, but two newer standards build on top of TLS to make server-to-server email delivery considerably more trustworthy. Both are supported natively in MDaemon and SecurityGateway.
MTA-STS (Mail Transfer Agent Strict Transport Security - RFC 8461). STARTTLS between mail servers is opportunistic, which means an attacker who can tamper with the connection could downgrade it to plain text. MTA-STS lets your domain publish a policy stating that other servers must use TLS with a valid certificate when sending mail to you. The policy is published two ways for tamper-resistance: a DNS TXT record at _mta-sts.yourdomain.com and a policy file served over HTTPS at https://mta-sts.yourdomain.com/.well-known/mta-sts.txt. Policies run in one of three modes: none, testing (failures are reported but mail still flows), and enforce (mail is refused if TLS can’t be negotiated securely). It pairs naturally with TLS Reporting (TLS-RPT, RFC 8460), which sends you daily reports of any TLS negotiation failures, so the recommended rollout is to start in testing mode, watch the reports, and switch to enforce once you’re confident nothing legitimate is failing.
From our knowledge base:
RequireTLS (RFC 8689). Where MTA-STS is a policy you publish for incoming mail, RequireTLS works at the level of an individual outgoing message. You can flag a specific, sensitive message so that it will only be delivered over a verified TLS connection; and if that’s not possible, the message bounces back to the sender rather than being sent in the clear. In MDaemon, a message is flagged for RequireTLS treatment with a Content Filter rule action or by addressing it to a <localpart>+requiretls@yourdomain.com style address. (For this to work, the recipient’s mail server must support RequireTLS and its MX must be validated via DNSSEC or MTA-STS.) It’s a useful tool when delivery of a particular message should never happen unless it can happen securely.
Together, STARTTLS/implicit TLS encrypt the connection, MTA-STS prevents inbound connections from being quietly downgraded, and RequireTLS lets you guarantee secure delivery on your most sensitive outbound messages.
I hope this helps clear up any questions about SSL and TLS, and which encryption options are recommended. As always, if you have questions or comments, let us know!
