LuxSciLuxSci
Secure Email,
Web and Form Solutions
Phone: 800-441-6612
sales@luxsci.com
support@luxsci.com

How Can You Tell if an Email Was Transmitted Using TLS Encryption?

Frequently, we are asked to verify if an email that someone sent or received was encrypted using SMTP TLS while being transmitted over the Internet.  For example, banks, health care organizations under HIPAA, and other security-aware institutions have a requirement that email be secured at least by TLS encryption from sender to recipient.

This can and should be locked down to ensure that the email message content cannot be eavesdropped upon.  This check, to see if a message was sent securely, is fairly easy to do by looking the the raw headers of the email message in question.  However, it requires some knowledge and experience.  It is actually easier to tell if a recipient’s server supports TLS than to tell if a particular message was securely transmitted.

To see how to analyze a message for its transmission security, we will look at an example email message sent from Hotmail to LuxSci, and see that Hotmail did not use TLS when sending this message.  Hotmail is not a good provider to use when security or privacy is required.  Even Gmail does not provide a level of security and privacy required for HIPAA compliance.

An Example Email Message

First, we must understand that an email message typically passes through several machines on its way from sender to recipient.  Roughly speaking:

  1. The sender’s computer talks to the sender’s email or WebMail server to upload the message.
  2. The sender’s email or WebMail server then talks to the recipient’s inbound email server and transmits the message to them.
  3. Finally, the recipient downloads the message from his/her email server.

(for more details, see this article) It is step 2 that people are most concerned about; they usually assume or check that everything is secure and OK at the two ends.  Indeed, most users who need to can take steps to ensure that they are using SSL-enabled WebMail or POP/IMAP/SMTP/Exchange services so that steps 1 and 3 are indeed secure.  The middle step, where the email is transmitted between two different providers,  is where most messages are insecurely transmitted.

In order to determine if the message was transmitted between the sender’s and recipient’s servers securely (over TLS), we need to extract the “Received” header lines from the received email message.  If you look at the “source” of the email message, these are all the lines at the top that start with “Received:“.  In an example email message from someone on Hotmail, the Received headers look like this (I replaced the email addresses, IPs and such with fake ones for obvious reasons):

At LuxSci:
Received: from abc.luxsci.com ([1.1.1.1])
	by def.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfLgH003867
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2013 10:41:21 -0400
Received: from abc.luxsci.com (localhost.localdomain [127.0.0.1])
	by abc.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfK0Z030182
	for <user-xyz@def.luxsci.com>; Mon, 19 Aug 2013 09:41:20 -0500
Received: (from mail@localhost)
	by abc.luxsci.com (8.14.4/8.13.8/Submit) id r7JEfKXD030178
	for user-xyz@def.luxsci.com; Mon, 19 Aug 2013 09:41:20 -0500
Received: from p01c11m074.mxlogic.net (mxl144v247.mxlogic.net [2.2.2.2])
	by abc.luxsci.com (8.14.4/8.13.8) with ESMTP id r7JEfIkK030002
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)
	for <someone@luxsci.net>; Mon, 19 Aug 2013 09:41:19 -0500
At McAfee:
Received: from unknown [65.54.190.216] (EHLO bay0-omc4-s14.bay0.hotmail.com)
	by p01c11m074.mxlogic.net(mxl_mta-7.1.0-4)
	with ESMTP id e8e22125.0.638203.00-2056.897597.p01c11m074.mxlogic.net
        (envelope-from <someone@hotmail.com>);
	Mon, 19 Aug 2013 08:41:18 -0600 (MDT)
At Hotmail:
Received: from BAY403-EAS373 ([65.54.190.199]) by bay0-omc4-s14.bay0.hotmail.com
       with Microsoft SMTPSVC(6.0.3790.4675); 
       Mon, 19 Aug 2013 07:41:19 -0700

What do These Received Headers Say?

The things to notice about these Received headers are:

  1. They are in reverse chronological order.  The first one listed shows the last server that touched the message; the last one is the first server that touched it.
  2. Each Received line documents what a server did and when.
  3. There are three sets of servers involved in this example: one machine at Hotmail, one machine at McAfee, where our Premium Email Filtering takes place, and some machines at LuxSci where final acceptance of the message and subsequent delivery happened.

Presumably, the processing of email within each provider is secure (though maybe that is too presumptuous for many providers — it is true of LuxSci).  So, what you really have to watch out for are the hand-offs between Hotmail and McAfee and between McAfee and LuxSci … as these are the big hops across the Internet between providers.

In the line where LuxSci accepts the message from McAfee, we see:

(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT)

This section, which is typical of most email servers running “sendmail” that have TLS support, indicates that the message was encrypted during transport with TLS using 256-bit AES encryption. (“Verify=not” means that LuxSci did not ask McAfee for a second SSL client certificate to verify itself, as that is not usually needed or required for SMTP TLS to work properly) .

So, the hop between McAfee and LuxSci was locked down and secure.  What about the hop between Hotmail and McAfee?  The McAfee server’s Received line makes no note of security at all!  This means that the message was probably NOT encrypted during this step.  Whose fault is that?  Well, at the time of this example, either Hotmail did not support opportunistic TLS encryption for outbound email, OR  McAfee did not support receipt of messages over TLS and thus TLS could not be used…. without further context you would not know which server (or both) did not support  TLS.

We know for a fact that McAfee, like LuxSci, supports inbound TLS encryption.  In fact, from another example message that we have, where LuxSci itself was sending a message to McAfee, we see the Received line:

Received: from unknown [44.44.44.44] (EHLO wgh.luxsci.com)
	by p01c11m003.mxlogic.net (mxl_mta-6.1.0-3)
        over TLS secured channel
	with ESMTP id b-022.p01c11m003.mxlogic.net
        (envelope-from <from@domain.com>);
	Mon, 02 Feb 2009 19:28:27 -0700 (MST)

It is apparent that the message was indeed encrypted.  However, unlike LuxSci, McAfee does not record what kind of encryption was used, just that it was “over a TLS secured channel”.

Some things to consider when making your own analysis of email headers for encryption usage

  1. It is the receiving server that will log in the message headers what kind of encryption, if any, was used in the receipt of the message.
  2. Different email servers use different formats and syntax to display what kind, if any, encryption was used in the receipt of the message.  You should look for keywords like “SSL”, “TLS”, “Encryption”, etc., which will signify this information.
  3. Not all servers will record the use of encryption — there is nothing that says that they have to encrypt email.  I.e., while LuxSci has always logged encryption use,  McAfee has only been logging this since 2008. Prior to that time, TLS encryption was still possible and normal with their servers, but there was no way to tell from the headers if it was in fact used.
  4. Messages passed between servers at the same provider do not necessarily need TLS encryption to be secure.  For example, LuxSci has back-channel private network connections between its servers so that information can pass between them unencrypted but not subject to eavesdropping by any other server anywhere.  This is faster and more efficient than using TLS on every connection.  So, the lack of TLS usage between two servers does not mean that the transmission between them was “insecure” per-se.
  5. If you are a LuxSci customer, you can look at your online email deliver reports to see if TLS was used for any particular message and recipient that you have sent.  We record this fact in our delivery reports so there is no need to obtain and read messages headers.

With some servers not reporting use of TLS, and in some cases TLS not being needed, how can you really determine if a message was transmitted securely from sender to recipient?

You really have to understand the properties, servers and networks involved in order to answer this question accurately.  While you may be able to answer in the affirmative, based on headers, in some cases, you cannot necessarily answer in the negative without knowing what things are recorded by each system’s servers. In our example of a message from Hotmail to LuxSci, you need to know that:

  1. McAfee and LuxSci will always log use of TLS in the headers — this tells us that the Hotmail to McAfee hop was not secure as nothing is recorded there.
  2. Transmission of messages within LuxSci’s infrastructure is secure due to private back channel transmissions.  So, even though there is no mention of TLS in every Received line after LuxSci accepts the message from McAfee (in this example), the transfer of the messages between servers in LuxSci is effectively as secure as using TLS.  Also, multiple received lines can be added by the “same server” as it talks to itself.  Generally, these hand offs on the same server will not use TLS, as there is no need.  We see this also in the LuxSci example, as “abc.luxsci.com” adds several headers.
  3. We don’t know anything about Hotmail’s email servers and so don’t know how secure the initial transmissions within their network are.  However, since we do know that they did not transmit the message to McAfee securely, even though they could have, we do not have much confidence that the transmissions and processing within Hotmail (which may have gone unrecorded) were secure at all.

What about the initial sending and receipt of the message?

So, we skipped steps 1 and 3 and focused on step 2 — the transmission between servers.  Steps 1 and 3 are equally if not more important.  Why?  Because eavesdropping on the Internet between ISPs is less of a problem than eavesdropping near the sender and recipient (i.e. in their workplace or local wireless hotspot).  So, one must take care that messages are sent securely and received securely.  This means:

  • Sending: Use SMTP over SSL or TLS when sending from an email client or use WebMail over a secure connection (SSL / HTTPS).
  • Receiving: Be sure that your POP or IMAP connection is secured via SSL or TLS; If using WebMail to read your email, be sure it is over a secure connection (SSL / HTTPS).
  • WebMail: There is generally no record in the email headers to indicate if a message sent using WebMail was transmitted from the end user to WebMail over a secure connection (SSL  / HTTPS).

You can generally control one side and make sure that it is secure; you generally can’t control the other without taking extra steps.  So, what can you do to ensure that your message is secure even if it might not be transmitted securely and if your recipient might try to access it insecurely?

You could use end-to-end email encryption (like PGP or S/MIME which are included in SecureLine) or a secure email pickup service like SecureLine Escrow that doesn’t require the recipient to have to install or setup anything in order to get your secure email message.  These all meet the security requirements of HIPAA, and organizations that mandate email transmission encryption.

Of course, if you can ensure that the email sent from you to your important recipients will always be transmitted securely, that is the best solution.

3 Responses to “How Can You Tell if an Email Was Transmitted Using TLS Encryption?”

  1. SMTP TLS Enforced Outbound Encryption with Fall Back to PGP, S/MIME, or Escrow Message Pickup | LuxSci FYI Says:

    [...] accounts that enable “TLS Only” can have their outbound email delivered over an SMTP TLS encrypted channel to recipients whose email services support it.  This mitigates the need for using PGP, S/MIME, or [...]

  2. avinash shitole Says:

    Very good information.
    with MX record and then using Telent port 25. EHLO command one can check if TLS is supported or not. but how once can check if

    TLS configured is Broken or in good shate?
    avindia@excite.com

  3. Erik Kangas Says:

    The only way to see if TLS is broken is to simulate an SMTP transmission using TLS. If your simulation gets through the STARTTLS command OK and can issue other commands, then their TLS is in good shape.

Leave a Comment

You must be logged in to post a comment.

TRUSTe EU Safe Harbor Thawte Extended Validation SSL Certificate McAfee Secure Authorize.net Merchant
• Access Anywhere
• Fast and Robust
• Super Secure
• Tons of Features
• Customizable
• Mobile Friendly

Send and receive email from your favorite programs, including:

 Microsoft Outlook
 Mozilla Thunderbird
 Apple Mail
 Windows Mail

... Virtually any program that supports POP, IMAP, or SMTP

Keep your email, contacts, and calendars in sync:

 Apple iPhone and iPad
 Android Devices
 BlackBerry
 Windows Phone

... Any device with Exchange ActiveSync (EAS) support

Relay your server's mail through LuxSci via smarthost:

• Resolve issues with ISP sending limits and restrictions
• Improve deliverability with better IP reputation and IP masking
• Take advantage of Email Archival and HIPAA Compliance
• Even setup smarthosting from Google Apps!

Free web site hosting with any email account:

• Start with up to 10 web sites and MySQL databases
• DNS services for one domain included
• Tons of features and fully HIPAA capable

LuxSci's focus on security and privacy:

• Read The Case for Email Security
• Read Mitigating Security & Privacy Threats
• Review our Privacy Policy

The most accurate, flexible, and trusted filters in the business:

• Premium protection with Intel Security Saas
• Realtime virus database guards against the latest threats
• Seven-day quarantine lets you put eyes on every filtered email
• Supplement with our Basic Spam Filter for even more features

End-to-end secure email encryption — to anyone, from anyone:

• No setup required — encryption is automatic and easy to use
• Secure outbound email with TLS, PGP, S/MIME, or Escrow
• Free inbound encryption via our SecureSend portal
• Independent of your recipient's level of email security
• Widely compatible and fully HIPAA Compliant

Add an extra layer of security with an SSL Certificate:

• Secure your web site
• Debrand LuxSci WebMail with your own secure domain
• Access secure email services via your own secure domain

Encrypt your service traffic via secure tunnel:

• Add another layer of security to your SSL connections
• WebMail, POP, IMAP, SMTP, web/database access
• SecureForm posts, SecureLine Escrow, SecureSend access
• Restrict your account to VPN access only

Secure long-term message archival:

• Immutable, tamperproof email retention with audit trails
• No system requirements — minimal setup, even less upkeep
• Realtime archival of all inbound and outbound messages
• Works anywhere — even with non-LuxSci email hosting

Free data backups included with all email hosting accounts:

• Automatic backups of all email, WebAides, web/database data
• Seven daily backups and up to four weekly backups
• Unlimited restores included at no additional cost
• Custom backup schedules for dedicated servers

Automate your email management:

• Save messages to specific folders or to LuxSci WebAides
• Advanced text scanning with regular expressions
• Tag messages, alter subject lines, or add custom headers
• Filter by message charset, type, TLS status, DKIM status
• Chain filters together for even more complex actions

• Bulk add and edit users, aliases and more
• Control sharing and access globally or on a granular level
• Delegate user roles through permissions
• Configure account-wide taglines, sending restrictions, and more
• Remotely administer account via SOAP API

Share, collaborate, organize, synchronize:

• Calendars, Contacts, Documents, Notes, Widgets, Workspaces
• Fine-grained access control and security
• Access anywhere via secure web portal or smartphone
• Save over solutions like Microsoft Exchange

Free folder sharing for all email hosting accounts:

• Share mail folders with other users in your account
• Subscribe to only the folders you want to see
• Set read-only or read-write access control
• View all personal and shared folders via unified web interface

Color code and label your email messages:

• Define and assign multiple IMAP keywords to each message
• Filter, search, and sort by tags
• Compatible and synchronizes with any IMAP email client
• Also usable with WebAide entries