7

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?

13
  • 5
    Messages are not TLS secured, network flows are. Whatever "security" he is showing with the icon, it isn't TLS. Nov 20, 2013 at 18:06
  • 4
    @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…)
    – voretaq7
    Nov 20, 2013 at 21:24
  • 2
    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?
    – mfinni
    Nov 20, 2013 at 22:25
  • 2
    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.
    – Skyhawk
    Nov 20, 2013 at 23:02
  • 4
    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. Nov 20, 2013 at 23:42

2 Answers 2

11

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.

Exchange Domain Authenticated E-mail Dialog Box Example

7
  • Oh look, Microsoft software is lying to its users by oversimplifying. Again.
    – MadHatter
    Nov 21, 2013 at 17:43
  • 1
    Well, it's not lying. It's enforcing TLS between your org and a single known org, not the world.
    – mfinni
    Nov 21, 2013 at 18:04
  • 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.
    – MadHatter
    Nov 25, 2013 at 9:45
  • 1
    @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.
    – Skyhawk
    Nov 26, 2013 at 4:32
  • 1
    @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.
    – Skyhawk
    Nov 26, 2013 at 23:52
6

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).

11
  • 1
    Great analogy. :)
    – EEAA
    Nov 20, 2013 at 22:46
  • 1
    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.
    – Skyhawk
    Nov 20, 2013 at 22:46
  • 1
    @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.
    – Skyhawk
    Nov 20, 2013 at 22:57
  • 2
    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. Nov 20, 2013 at 23:27
  • 4
    @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.
    – voretaq7
    Nov 21, 2013 at 1:29

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .