How can a non-technical user verify a message was sent "securely"? ...or over TLS?

Question

I have a situation where B2B and B2C communication needs to be sent securely and not visible to most SMTP hijackers. I don't care about conspiracy theories or NSA style attacks, but want to provide reasonable security for individuals who don't want their PII data exposed to less capable attackers.

This business requirement comes from Massachusetts data privacy laws that require PII for residents to be sent "encrypted" without much further elaboration of the technical requirements.

Our client's business relies heavily on email and the ability to send PII for life insurance, health insurance and other financial products.

To that end, I intend to use TLS to provide this security due to its ubiquity, ease of use, and that it co-operates well with financial compliance requirements. I envision creating a direct TLS tunnel between partner's MTA and ours. (Forced TLS not opportunistic)

The problem is that TLS "security" is buried in the SMTP headers, difficult to understand, and the borders of administration are hard to delineate. e.g.

  company1 ---->  MSFT Hosted Relay  -->  [TLS between providers] ----> Google Hosted --> Company 2

  company1 ---->  Proofpoint         -->  [TLS between providers] ----> Google Hosted --> Company 2

Question

Assume an insurance company needs to send a SSN in an email message (body or attachment). The next hop MTA is a Gmail, Yahoo, or other trusted private MTA.

• How can I give the recipient confidence that the message was sent securely over TLS?

• What alternative technical solutions or RFC would assist in giving me this assurance? (Perhaps a variant of DMARC/DKIM + TLS?)

Answer 1

Your objective is to drive in a screw, and you want to use a hammer because you have one handy and it's easy to use. I'm afraid the most likely outcome is a sore thumb.

TLS is fundamentally about point-to-point security. It is only attached to the connection, not to the data. Email, on the other hand, is fundamentally designed to bounce through multiple hops. While the hops do leave a stamp tracing their actions, you would be dependent on the hosts to not be malicious (each hop can fake the whole message including the stamps of its predecessors), to not be fooled (e.g. into misauthenticating their predecessor), and to leave the stamps that you expect.

You can give the recipient confidence that the message was transmitted securely by delivering a signed, encrypted message produced by the sender. TLS is not useful for this. RFC that can help you include RFC 3156, RFC 4880 (OpenPGP Message Format), RFC 5750 and RFC 5751 (S/MIME).

In other words: use PGP or S/MIME.

Answer 2

In fact you cannot really given any guarantee in any case. You cannot reliably guarantee that a given email will be protected by TLS on each hop, because the relevant servers do so opportunistically, and the list of relevant servers can change without notice (dynamic routing, even at the SMTP level, is common for highly used servers). Even for an email which was sent, you can know whether the connections were TLS-protected only insofar as the relevant servers were kind enough to state it (and then, only in the Received: headers), and, there again, only if the same server were kind enough not to lie about it.

The format of data in the Received: headers is purely traditional, not standard, and not all servers use the same format. This header is meant to be human-readable, at least for a notion of "human" which matches the social environment of early RFC writers. As you have noticed, not every customer can be expected to be "that kind of human".

An even more important point is that the Received: header can only be seen in the email which was received. Imagine an evil individual who wants to read some emails sent by other people to other people. If that evil individual is <insert here your favourite spy agency>, then he just has to bribe an intern at one of the places hosting a SMTP server. But let's suppose that the bad guy is a freelancer. He will want to intercept the email while being transferred from SMTP server G (as "Gahoo") to SMTP server Y (as "Ymail")(fictitious names, of course). So he employs the poor-man's MitM, known as DNS poisoning: he poses as SMTP server Y in the eyes of SMTP server G.

G connects, the attackers claims not to support TLS (or to support TLS with a bad certificate, or whatever); G then gracefully degrades to non-TLS, and sends the email "as is". Then, the bad guy does not acknowledge reception of the email, and instead breaks the connection abruptly. SMTP server G considers that occurrence to be some random network error, tries again, this time connects to the actual Y server (possibly relayed by the attacker, it does not matter), does TLS, sends the email. On the receiving part, there will be no trace whatsoever of the aborted non-TLS transfer which ended in the attacker's machine. The email contains a lot of Received: headers which all claim that TLS was used throughout -- because they only talk about the successful email connection.

---

While you cannot guarantee that the email was well protected, you might succeed in convincing a non-technical customer that is was well protected. For instance by not telling him any of the above...

Bottom-line is that email is not secure, and never was. For email security, you need a true end-to-end solution, i.e. PGP or S/MIME (assuming they are properly employed, which is not a given).

Answer 3

In the specific case outlined above, where you are sending from a known TLS-capable provider to a known TLS-capable receiver (with no inconvenient third-party backup MXs), you can trust the path, but there is no way for a recipient to confirm it other than by divining the Received headers (or SMTP logs on each hop) if TLS was used along the way.

Given the store-and-forward nature of SMTP, in the general case, you (the sender) can't know in advance that a specific message will arrive having used only TLS connections at every hop.

To the best of my knowledge, there is no interoperable way¹ to instruct an SMTP server on a per-message basis to only use TLS; and no common method for an MUA to indicate it, like a DKIM visual indicator in some email clients. Given that the Received header format varies from MTA to MTA, that's a more difficult problem that it might seem.

With a non-technical user base, one alternative might be encrypted PDF, this comes with a shared-secret requirement... that too may fall afoul of mandated content inspection policies though.

Another alternative commonly used (which again has either a shared-secret or authentication requirement) is email a HTTPS link to the content.

I'm guessing that showing the user how to cut-and-paste the headers is out too, though even mxtoolbox shies away from parsing TLS details, it would in theory be possible.

A TLS solution is not a great fit: it's layer 5 (session), you're trying to provide layer 7 (application) layer security (and without swallowing all three of the confidentiality, integrity, authentication bitter pills...)

---

¹ The SalesForce X-SFDC-TLS-NoRelay header seems to be a proprietary way, though I'm guessing here as I cannot find its documented intent.

Answer 4

The solution is not to send the PII via e-mail. Send that info via a web site where you can ensure it is TLS encrypted and also is easy to access for the consumer and insurance agents alike.

Answer 5

I had the same question and discovered that mxtoolbox.com (now) provides an interface to query an SMTP server and report on whether it supports TLS. That's the only evidence we seem to be able to present that TLS is in place.

Answer 6

You should never send PII via a cleartext email. Even if the network hops are protected by TLS, you can't be certain that the data are encrypted at rest. In many cases the data are available to third or fourth parties-- e.g. Google notably will sift through its users' emails to figure out what advertisements to show you, or to detect patterns in spam-- and you cannot confirm that all of the various systems involved are properly secure or compliant. And even if they are, you can still suffer significant reputational loss if, say, you "privately" email one of your customers about erectile dysfunction, then suddenly he starts seeing ads for Viagra everywhere, because Google leaked a certain keyword into his ad network.

Two alternatives come to mind:

1. Secure the content of the email with an encryption scheme like PGP.

2. Don't put the content in the email at all. Instead, provide a link to a site where the user can sign in and view the content. This is how Citrix secure envelope service works, for example.

Answer 7

Welcome to the problem of secure email. Lets look at your options:

1. SMTP

   At a protocol level, SMTP has no concept of security. Like most early internet protocols (I'm looking at you DNS), it was designed assuming no malicious servers around. Assume NOTHING about stuff sent over SMTP for reasons documented in the other answers here

2. PGP or S/MIME

   Both are application layer overlays securing fundamentally insecure lower layers. That's great but both require the network effect (of users) to work, a problem both inherit from their unavoidable usage of asymmetric encryption (the PKI problem). Considering email (as an application) has the largest number of internet users on the planet, I don't see that changing anytime soon. In a B2C (even in many B2C) situation you're sorely out of luck.

3. Layer of indirection (aka "Illusion of security")

   This bring no security whatsoever BUT if you're trying to comply with the MA laws on not sending PII, you might be able to send a GUID based link in email, which when clicked present the actual information in a browser. OR use HTML emails where the PII text is actually an image loaded over SSL inside the email client. Technically you're not sending the actual PII over an insecure transport. I don't need to tell you but you need to consult a lawyer if this covers your business risk.

4. Modify the business requirement ( <== recommended)

   Personally, this is what I'd pick. I'd avoid sending any PII in the email to begin with. If this is email marketing to new customers (B2C), you might actually creep them by putting PII in a cold-email. If you already have these customers (B2C), I'd recommend setting up a web based messaging center behind a login screen (assuming your business has a login portal for it's other stuff). Honestly, this is the approach taken by most banks and hospitals for the exact reason you're experiencing (nobody likes yet another messaging portal but are forced to). That way you can use regular email without PII for mass emails, escalate it to the web portal for cases were PII is required. Budget the builtout of the secure messaging portal (along with SSO integration) and present to the decision makers creating the business need of "must send PII in email" and let them decide if the price is worth the need.