Transport Layer Security (TLS) is the unsung champion and defender of all good citizens of the Internet. Rather like some invisible, altruistic Marvel superhero, it works tirelessly behind the scenes each and every day helping to protect the things we need and like to do online. Along with its now atrophied predecessor Secure Sockets Layer (SSL), it has seen its fair share of archnemesis over the years. These have included villainous vulnerabilities with scary, attention-grabbing monikers like BEAST and CRIME, as well as some equally evil but not quite so scary ones. (That means you, POODLE.) Even more recently, we’ve heard about DROWN. One of the most overlooked aspects of this particular nasty was the risk it posed to mail servers that had failed to disable obsolete SSL protocol versions. Such a threat raises questions around TLS and its ability to protect corporate mail, particularly when used in an opportunistic arrangement. Configuring Mail Transfer Agents (MTAs) to use opportunistic TLS through the use of the STARTTLS command is certainly a sensible, cost-effective and pragmatic alternative to sending all of your mail and attachments blithely across the big, bad internet in cleartext. In fact, it is an approach that should perhaps fall under the ‘Why wouldn’t you?’ category of security measures. Many organizations have utilized TLS for some time now, and the more that do it well, the healthier the email ecosystem gets for us all. However, it should be stated that Opportunistic TLS does not necessarily provide you with ‘secure email.’ It simply provides a layer of security for email whilst it is in transit, and that is only when it has been properly configured at both ends. Misconfiguration is all too commonplace, as is evident in an early analysis of DROWN by the estimated amount of mail servers that still used a version of a protocol which should respectfully have been shot in the head years ago. But the ‘fail open’ nature of Opportunistic TLS means the mail keeps on flowing, as indeed it is intended. This is, after all, a best attempt (as the term ‘opportunistic’ implies) to negotiate a secure SMTP connection. One simply ‘fails open’ when it can’t achieve such a connection for whatever reason. (By ‘fail open’ here, we mean that if it can’t establish an appropriately secured connection. It will downgrade or simply revert to using plain old ‘up for grabs’ cleartext. This type of system is the opposite of a ‘fail safe’ scenario where the connection is refused and the mail is not delivered, an arrangement which presents its own business and operational risks.) In order to accommodate a ‘fail open’ approach, discrepancies around the matching of the X.509 certificates (intended to verify that the recipient domain is who they claim to be) are also often permitted. Unlike visiting a web page, which generally gives you a clear warning if there is a perceived problem with a certificate, the sender of a sensitive email to what they may believe is a trusted domain will have no choice in the matter as to whether to continue. These are all factors that can leave Opportunistic TLS open to a range of well-documented Man in the Middle (MITM) and DNS spoofing attacks. Where confidentially between certain parties is paramount and cannot be assumed or conceded, an alternative security improvement would be to establish ‘forced TLS’ whereby the ‘fail safe’ approach previously mentioned is adopted and the receiving mail domain has to be authenticated as a trusted source. This is fine – if you only need to guarantee such secured connections with a small and controlled number of trusted domains. It can be cumbrous administrative overhead to maintain beyond the smallest number of configurations, however. Such an effort in most cases becomes unwieldy and unmanageable in any real sense. It is certainly not the intention here to knock TLS (opportunistic or otherwise) per se, but it is important to at least properly research, assess, and understand the risks to your mail systems, particularly those that exchange personal, commercial, or otherwise sensitive data. Ask yourself in these scenarios whether one's best attempt is good enough. Would you want your online banking experience, for example, to be ‘opportunistic’? If the answer to that question there is "No," then you need to delve into a bigger box of security tricks. There are many enhanced features in managed mail solutions that are worth exploring, and there are specialized commercial tools that provide the advantage of actual message-level security in addition to data-in-transit protection. Additionally, some solutions also give you benefits around assurance of message integrity, auditability, non-repudiation, and the ability to revoke messages that are sent to the wrong recipients. These and other resources are worth considering for those assets with which you really can’t afford to take chances. Ultimately, it comes down to complexity, cost, and each organization's risk appetite for securing what was never intended to be a particularly secure communication channel in the first place. Some may take the view that the majority of their external email is not of a particularly sensitive nature or that they have alternative controls in place, such as corporate policies forbidding the use of email for the sharing of sensitive data. A best attempt approach to encrypting all mail transactions may, therefore, appear to be more than sufficient. But even if you have reached this conclusion and are quite sure of it, I urge you to not underestimate the amount of useful footprinting information that may be ripe for the picking in seemingly benign email conversations between those with elevated network privileges, financial authorization powers, or access to sensitive data and systems, among other rights. This is especially true in a rapidly accelerating era of spear-phishing and other highly targeted attacks. As for the question ‘Who would want to sniff our email traffic or attack our network anyway?,’ it's best to ask a number of compromised organizations about that one and keep those fingers firmly crossed. Opportunity as always knocks when you least expect it.
About the Author: Angus Macrae is an Information Security Manager and passionate cybersecurity enthusiast currently lucky enough to live in and publicly serve the beautiful county of Cornwall in the UK. Angus is also a proud family man, lifelong follower of Chelsea football club and distant blood relation of the late, great Joe Strummer RIP. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc. Title image courtesy of ShutterStock
