TLS stands for “Transport Layer Security” and is closely related to “SSL” (Secure Socket Layer). TLS is one of the standard ways that computers transmit information over an encrypted channel. In general, when one computer connects to another computer and uses TLS, the following happens:

1. Computer A connects to Computer B (no security)
2. Computer B says “Hello” (no security)
3. Computer A says “Lets talk securely over TLS” (no security)
4. Computer A and B agree on how to do this (secure)
5. The rest of the conversation is encrypted (secure)

In particular:

• The meat of the conversation is encrypted
• Computer A can verify the identity of Computer B (by examining its SSL certificate, which is required for this dialog)
• The conversation cannot be eavesdropped upon (without Computer A knowing)
• The conversation cannot be modified by a third party
• Other information cannot be injected into the conversation by third parties.

TLS (and SSL) is used for many different reasons on the Internet and helps make the Internet a more secure place, when used. One of the popular uses of TLS is with SMTP.  See also:

• How Does Secure Socket Layer (SSL or TLS) Work?
• The Case for Email Security (Why normal email is insecure)

TLS with SMTP

The mechanism and language (i.e. protocol) by which one email server transmits email message(s) to another email server is called SMTP (Simple Mail Transport Protocol). For a long time now, email servers have had the option of using TLS to encrypt the message transmission from one server to the other. Use of TLS with SMTP, when available, ensures that the message contents are secured during transmission between the servers.

Not all servers support TLS. Use of TLS requires

• the purchase of one or more SSL certificates
• configuring the email servers to use them
• additional computational resources on the email servers involved.

For these reasons, many email servers do not support TLS at all (i.e. most free email servers like gmail and yahoo do not).

For TLS transmission to be used at all, the destination email server must support and advertise support for TLS (see: How to Tell Who Supports TLS for Email Transmission) and the sending server must be configured to use TLS connections when available.

The sending server could be configured for:

• No TLS — never use it.
• Opportunistic TLS — use it if it is available
• Forced TLS — use TLS or do not deliver the email at all

How Secure is TLS?

TLS protects the transmission of the content of email messages. It does nothing for protecting the security of the message before it is sent or after it arrives at its destination. However, transmission security is all that is required of many organizations (i.e. banks and health care). In such situations, enforced use of TLS is a good alternative to stronger and less user friendly encryption methods (like PGP and S/MIME) and can prevent insecure delivery of email.

The transmission itself is as secure as can be negotiated between the sending and receiving servers. If they both support strong encryption (i.e. AES 256) then that will be used. If not, a weaker grade of encryption may be used. The sending and receiving servers can choose what kinds of encryption they will support — and if there is no overlap in what they support, then TLS will fail (this is rare).

What about TLS on LuxSci servers?

LuxSci email servers:

• Support Opportunistic TLS. They will use TLS with any server that claims to support it. If the TLS connection to that server fails (due to misconfiguration or no security protocols in common), the message will not be sent.
  • All outbound email messages, encrypted via SecureLine or not, will also be transmitted over TLS if the recipient’s email servers support TLS.
• Support strong encryption, up to AES 256. They will use the strongest encryption supported by the recipient’s email server
• Will use “Forced TLS” with recipient servers that support TLS if email is being sent to those servers from any SecureLine account using TLS-Only delivery services (outbound email or forwarding). This ensures that messages will never be delivered to such servers even in the case that they stop supporting TLS.
• Support use of TLS for inbound email message delivery, with encryption up to AES 256. (It is up to the sending server to determine if this is used, however).
• Do not support weak, SSL v2, or export grade encryption strength options.

Does LuxSci have any other Special TLS Features?

When using SecureLine for outbound email encryption:

• Account administrators can choose to have messages “try TLS first” and deliver that way.  Only if TLS is not available would the messages fall back and use more secure options like PGP, S/MIME, or Escrow.  This makes email security easy, seamless, and automatic when communicating internally or with others who support TLS.
• Account administrators can restrict any server side email forwarding settings in their accounts from allowing forwarding to any email addresses which do not support TLS for email delivery.
• When TLS delivery is enabled for SecureLine accounts, messages will never be insecurely sent to domains that purport to be TLS-enabled. I.e. TLS delivery is enforced and no longer “opportunistic”.  The system monitors these domains and updates their TLS-compliance status daily.

Similar Posts:

• Enhanced Email Security Reports
• Secure TLS Email for Bank of America Partners
• SecureForm: now with SMTP TLS for Secure Form Email Delivery
• How Can You Tell if an Email Was Transmitted Using TLS Encryption?
• SSL and TLS are not enough to secure your email