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:
- The sender’s computer talks to the sender’s email or WebMail server to upload the message.
- The sender’s email or WebMail server then talks to the recipient’s inbound email server and transmits the message to them.
- 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:At McAfee:At Hotmail:
What do These Received Headers Say?
The things to notice about these Received headers are:
- 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.
- Each Received line documents what a server did and when.
- 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 [18.104.22.168] (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 <email@example.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
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.