Display a TLS icon for messages that are TLS secured (Outlook)

Question

One of my colleagues at a large financial institution has customised Lotus Notes to show a TLS icon for messages that are TLS secured.

I'm interested in imitating this feature in Outlook, and believe this requires VBScript, custom forms, and possibly the Custom Forms Library in Exchange.

Has anyone experimented with changing the way an email displays based on either NamedProps, or text that is accessable in the email header?

Solution 1

Mutually enforced TLS, also known as Domain Security, is supported in Exchange 2007 and newer. Proper configuration of this feature is common vendor audit requirement in the financial industry: large financial institutions require their vendors and business partners to enforce TLS according to the e-mail domain names of partner institutions. This feature avoids relaying via untrusted SMTP servers by ensuring that messages are delivered directly to the recipient institution's Exchange server, encrypted via TLS, without passing through any untrusted mail servers en route.

The feature that you are requesting (identifying domain secured messages to end users) is already built into Microsoft Outlook. If Domain Security is configured correctly, any messages whose transport has been secured in this fashion will be designated with a green checkmark icon. You do not need scripting or custom forms to make this happen.

Solution 2

TL;DR

You can't do what you're asking. The only thing you can reliably verify with any real value from a security standpoint is encryption of the message itself (S/MIME, PGP, or similar).

---

The Long Version

From your comment

TLS secured on transport on the open internet is sufficient for the business (and many large peer businesses)

This sounds like your business (and its "many large peer businesses") don't understand what "TLS secured on transport on the open internet" means in terms of security for email.

Email (SMTP) is NOT a point-to-point connection. It is a relay race.
The security analogy is this:

1. SMTP + TLS puts your message in a blank envelope and hands it to a stranger on the street.
2. That person opens the envelope and reads the message to see who it's addressed to.
   • If the message is for them, they keep it.
   • If the message is for someone else, they put it in a new blank envelope and hands it to another stranger on the street.

It's at the second point under (2) where things go all pear-shaped as the message can be intercepted (copied or modified) with impunity - TLS is protecting the channel (so other people on the street can't see your letter when it's being handed off) but not the content, which the intermediate servers are going to need to decrypt in order to see who the message is addressed to.

Bluntly there's no way for you to verify SMTP TLS in messages sent over the public internet. You can consult the header data, but the header data is just a post-it note stuck on your letter by each stranger who touches it -- the headers can be a pack of lies.

You can verify that the last server that handled your message (the one talking to you) used TLS when they talked to you because you know the details of that connection, but that's all you can verify and that doesn't protect the rest of the chain (or the content of the message as noted above).

At least in my field (Medical) TLS in the message chain is completely inadequate as authentication/signature or encryption/confidentiality technology -- It's useful for its own purposes, but not reliable enough to hang your hat on in an audit.

---

There is some value in verifying that the reading connection (POP, IMAP, RPC/HTTP (Outlook), Webmail) is secured with SSL/TLS, but again this doesn't protect the message itself (nor does it ensure the SMTP half of the email process had any security whatsoever) -- it just keeps prying eyes from reading over your users' virtual shoulders when they're downloading their mail and protects their password (which is pretty important).

Comments

[84104]

Unless you're talking about S/MIME "TLS Secured" messages aren't really a thing.

[Juanjo Daza]

@84104 In the context of many large banks, and all the email administrators of said banks, it is a "thing" in the commercial world, the administrators and email admins who promote it. Granted it is not an RFC, or hasn't been standardized, nor is it even close to perfect / ideal

[Michael Hampton]

Messages are not TLS secured, network flows are. Whatever "security" he is showing with the icon, it isn't TLS.

[Juanjo Daza]

@MichaelHampton The business problem we are solving is that a message must be encrypted when sent. This satisfies audit requirements, however we need to conceptualize this for an end user. I want to avoid the alternative which is PortalBased Encryption... which requires a username/password and has general security and audit concerns that are off topic...

[Michael Hampton]

So it's the message that's encrypted. That's generally S/MIME. And yes, I'm fairly sure it's pretty standardized.

[Juanjo Daza]

S/MIME is rejected by the business due to deployment and 3rd party audit concerns. TLS secured on transport on the open internet is sufficient for the business (and many large peer businesses), and I'm focused on that problem. What phrasing would you suggest that would be a compromise between technical accuracy and the end user who knows nothing other than TLS is sufficient? @MichaelHampton

[voretaq7]

@makerofthings7 I don't care what terminology you use with your users, but please modify your question to use standard terminology. "TLS Secured email" means nothing - If you're talking about encrypting the payload (the email), say so. If you're talking about encrypting the transport (SMTP+STARTTLS, IMAPS, etc.) specify that. If you must have both, specify both. Your question as it is makes no sense. (In the spirit of not letting your users sound like idiots you may want to teach them proper terminology as well…)

[mfinni]

If you're doing this to pass an audit, what the hell does a GUI badge in outlook prove? If you need to show that a given message was sent or received with TLS, you need to present SMTP logs. Why is your mail admin team not involved with this project for you?

[Hecter]

This GUI badge for messages delivered securely is already a built-in feature of Outlook 2007 and newer. If the messages aren't already designated to the end user as Domain Secured, and messages are being delivered between Exchange 2007 (or newer) Edge Transport servers, then it is reasonable to assume that Domain Security is not configured correctly.

[Michael Hampton]

Yes, many of us have a "religious zeal" for doing things right. You should not be surprised to encounter it in the context of this question.

[Juanjo Daza]

There is more than one right way to solve a problem that transcends the limitations of technology. Allowing for a compromise is essential when trying to prevent over-engineering a solution that has high overhead, high administrative costs, and minimal benefit in comparison. (keeping the goal in mind)

[Juanjo Daza]

Also, are you serious you want business end users to say they want "SMTP+STARTTLS" and not "TLS Secured Mail". ... even techies have misspelled "smpt" on this site. If that is how you want the business to respond, requesting security with that acronym, I can't take you seriously. (my question to you was, "What phrasing do you suggest [for end users])". I'll assume your upvotes are not based in reality, and are just sock puppets. Good day, I'm done.

[mfinni]

I just had this discussion with my client - fortunately, he's a technical manager and totally gets it. Now we just have to explain this to the business.

[voretaq7]

@mfinni "Everyone on the Internet can read your email if you don't do it the way I'm telling you to." is how I usually explain it. They may not understand much, but they understand that.

[EEAA]

Great analogy. :)

[Hecter]

Respectfully, the financial industry has very different expectations than the medical industry. Regardless of whether or not it's the best way to encrypt mail flows between partner institutions, mutual enforcement of TLS encryption (a.k.a. Domain Security) is a very common audit requirement for financial institutions and their vendors, and it is supported out-of-the-box in Exchange 2007 and newer. It is factually inaccurate to suggest that messages delivered via secure transport cannot be identified to end users, because, in fact, Outlook does this automatically.

[Hecter]

@voretaq7 What may happen according to RFC 2821 is irrelevant in this context. In order for messages to receive the Domain Secured E-mail badge, they must be delivered directly from one organization's Edge Transport server to another organization's Edge Transport server via a connection secured with TLS. Under normal circumstances, only the NSA will be reading the contents of these messages.

[Juanjo Daza]

the headers can be a pack of lies. I disagree. The demarcation of trust begins and ends with the last server you trust. That could be one you own, or one at a vendor/external cloud host.

[Juanjo Daza]

-1 because in our world, I trust SMTP to the edge, and am only legally responsible to handing off to their one hop that is published by an MX record. A proper engineer designs something as simple as possible, but not simpler. Credits- A. Einsten

[voretaq7]

@makerofthings7 A proper engineer considers all failure cases in their design, especially the ones that are codified in standards (e.g. if their MX is a spam filtering service like Postini all bets are off). But hey, if your auditors are more forgiving than mine and you can wash your hands after the first handoff that means less work for you.

[MadHatter]

Oh look, Microsoft software is lying to its users by oversimplifying. Again.

[mfinni]

Well, it's not lying. It's enforcing TLS between your org and a single known org, not the world.

[MadHatter]

It's lying. When it says "The message and its content were not viewed or changed in transit", what it actually means is that it was not viewed or changed in the most recent hop in the delivery chain. It can't guarantee end-to-end integrity, but the message presented to the user makes that far from clear.

[Hecter]

@MadHatter There is no SMTP "delivery chain". For this to be configured correctly, there must be a send connector configured to deliver mail directly from one Exchange organization's edge transport server to another's.

[MadHatter]

And what about from the desktop to the sending server's Exchange server? If that delivery hop is via unencrypted SMTP, will the receiving server know not to display the icon?

[Hecter]

@MadHatter I don't know, but I can tell you that within the financial industry (where I've personally implemented this feature per client requests), allowing desktops to connect to the Exchange server using unencrypted SMTP or POP3 would result in an audit exception. I used to work for an company that was subject to 20+ IT security audits per year (due to a large number of banking industry clients, each of which took the initiative to audit us independently of the others), often including port scans of our network from the inside. Yes, this can be implemented incorrectly. Most things can.

[Hecter]

@voretaq7 With Domain Security enabled properly, the MX record never gets looked up. A domain-specific send connector is used instead, ensuring that any third-party MX services used for "normal" mail flows are bypassed. I'd be awfully surprised if Outlook/Exchange could be made to display the green checkmark badge on a message that hasn't been delivered directly from one Exchange edge server to another. I get that this approach is not necessarily the best way to encrypt mail, but it is a de facto standard in the banking industry, and it can be done correctly.

[voretaq7]

@Skyhawk You know me well enough to know that I have nothing complimentary to say about "de facto standards" - those gave us the <marquee> tag. I prefer interoperability according to published standards that work for everyone, because all the world is not <s>a VAX</s> running Exchange. I certainly like your answer (heck I even upvoted it as I've got no doubt it can be made to work and it's a more direct answer than mine), but I totally disagree with it from a philosophical perspective (It's not quite "DNS server hijacks NXDOMAIN to serve me ads" bad, but it's still bad…)

[MadHatter]

That's fair enough, but it's mixing technical and business policy. If the operation of this "Authenticated email" flag for the recipient is dependent on the sending server having been correctly set up, it's back to being meaninglessly oversimplified. If it doesn't, you have yet to offer a technical explanation for how it doesn't. I completely agree that security is dependent on implementation; I just really don't like software that thinks that hiding the complexities of that from the users serves them in any way whatsoever.