Can you really be sure if an email message was transmitted using TLS?
Our latest “Ask Erik” question involves TLS delivery of email over SMTP.
Hello! I read the “How Can You Tell if an Email Was Transmitted Using TLS Encryption?” article, and found it very helpful and informative! I am currently looking into Mail Chimp’s encryption practices. On their website they advertise “SSL Encryption”. I’m not sure whether this actually means TLS yet, but I’m wondering: (1) is it possible to see if an email is SSL-encrypted (actually SSL, not TLS) other than by looking at the email headers? (2) if an email header does not contain “TLS” or “SSL”, like Hotmail’s “received” header from the article, does this necessarily mean it was sent unencrypted? Or is it possible (or likely) that hotmail would not record its encryption use?
This is a great question! Lets address the nuances in turn.
Could SSL mean TLS?
I would bet that Mail Chimp really means TLS. Almost everyone has switched to TLS due to serious issues with SSL. However, the term “SSL” is in such common meaning “stuff that secures a connection” that many places will use the term “SSL” to mean “SSL” or “TLS,” as that is just simpler for most people to understand right now. For more details on this, see:
Is it possible to see if an email is SSL-encrypted (actually SSL, not TLS) other than by looking at the email headers?
The only place that you can see if SSL or TLS was used, at least in the email message itself, is in the “Received” mail headers. Beyond that, there may be records of the communication security used in the email server provider’s mail logs. However, you may not have access to these and the provider may or may not expose SSL/TLS-delivery information to you in delivery status reports (LuxSci does).
If an email header does not contain “TLS” or “SSL”, like Hotmail’s “Received” header from the article, does this necessarily mean it was sent unencrypted?
No, it does not necessarily mean that it was received unencrypted.
Each mail server will have a configuration that determines if the TLS/SSL connection status is printed in the “Received” headers or not. Generally speaking, a particular mail server will either (a) never say anything about SSL/TLS, or (b) always indicate if it was used. So, if you are looking at a message that was received by server that is known to include TLS/SSL information in the mail headers and you do not see any such information, then either (a) the message was received without SSL/TLS, or (b) that server was misconfigured when the message arrived. Lack of TLS or SSL information in the headers is not definitive proof that it was received insecurely. Better proof can usually be found in the receiving email server’s raw mail logs.
It should be noted that there are many “Received” lines in an email header and often many of these lines are for servers in the same email company. It is not unusual for messages passing between servers in the same organization to not reflect TLS/SSL usage. This can be perfectly OK.
Some servers may not be configured to record TLS/SSL usage; some internal server-to-server transmission stages can be encrypted or protected using other means; some stages can be performed over dedicated private network links that do not need TLS encryption. What you should be really interested in are the server-to-server transmission stages that show the message being transferred from one service provider, like LuxSci, to another, like Gmail. These are the hops that really need to be secured.
