Probably the most annoying thing about email security these days is the fact that there are still organizations out there that don’t offer TLS encryption on their SMTP servers. In my opinion, we are well past the point where this should be enabled on all servers. It’s a very simple configuration change that takes no more than 5 minutes to enable. So I’m now advocating TLS enforcement on SMTP. I won’t say anything about what version of TLS gets used (yet), but for heaven’s sake, we really need to be requiring this. “But I have a cloud secure delivery system!” you might say. Great! Here’s a fun fact…Cloud secure mail delivery is, in some ways, less secure than TLS on SMTP. Yes, you have encryption in transit and at rest. But you also have to nix the age old recommendation that your users never click on links in email. Those systems are handy for making sure you are compliant with HIPAA, SOX, and other regulations, but there are mountains of phishing attacks that take advantage of the “click here to read your encrypted message” thing. The benefits only slightly outweigh the risks. And that feature can be pretty expensive. Anyway, griping over…Here’s what to do about it in your Exchange environment (onprem or cloud). Linux dudes need to mess with their systems without my help 😛 If you’re using Domino…You have my condolences.
Check Yourself
Before forcing TLS on your environment, you’ll want to make sure you are able to use it outside your environment. If you have certain firewalls or devices in place that perform Deep Packet Inspection, you’ll want to either be aware of the risks of doing so or disable that on port 25, because DPI regularly breaks the STARTTLS features in ESMTP sessions, meaning that you have no option to encrypt email with TLS. This is bad, and you need to fix it. If you want to verify whether your TLS capability is available on the Internet, CheckTLS has a cool tool that will allow you to test your mail server for TLS capability. Go here and set the tool view with the below options:
We’re looking to get the following results, with the pertinent values highlighted. You want to see the TLS column in the results matrix to show OK. The connection log should also show the 250-STARTTLS verb is available, and the log results should show that TLS is available and usable. If you get something other than the results shown, you will want to investigate why.
Transport Rule
Once we’ve verified that TLS is available, we will want to configure Exchange to require TLS. Setup is simple…Just create a transport rule with the following settings (you’ll need to scroll down and select More Options first):
This will reject any message that isn’t TLS encrypted. It will also create an audit record that you can look up by going to the Rule Matches for Mail report (If you just want to know who is not using TLS, set the option to Test instead of Enforce). Audit reports are accessible by clicking the option shown below:
Results
Unfortunately, I can’t show you what happens when someone sends a message that isn’t TLS encrypted when this setup is in place. I don’t have access to port 25 on my home network, like pretty much everyone. However, the result is fairly simple, the sender will get a notification that the message couldn’t be sent. Note, however, that it may take a long time for that NDR to get to the sender, so you need to stay on top of the rule matches, which is why I tell you to audit this, and why I recommend doing this with a Transport Rule. If you do it with a connector, which is possible, you will have a much more difficult time figuring out who is sending to you and failing. The audit capabilities with Transport Rules are much more friendly and useful, so go with this technique instead. And that’s it. Please note, though, that this will only provide encryption in transit. At rest encryption requires PGP, S/MIME, or secure mail delivery systems. Or Bitlocker.
