SMTP Checker Help
Version 2012.10.16
This is a copy of the agreement that is presented to any customer when they authorize LuxSci Technical Support to connect to their computer to assist with the resolution of a technical support issue..
About the TLS Checker Tool
The LuxSci SMTP TLS Checker is solely concerned with TLS in relation to the receipt of email (SMTP); specifically, whether the recipient’s inbound email servers support TLS (Transport Layer Security). When LuxSci’s email servers connect to the recipient’s email servers, they check to determine if TLS encryption is available and, if so, if the security options are “good enough” to be considered actually “secure.”
By entering the domain from someone’s email address and clicking on the “Analyze Domain” button, LuxSci will examine the domain’s inbound email servers and determine if they are capable of using TLS. We will also see how securely these servers are configured for SMTP TLS.
Understanding the TLS Checker Results
Email can be delivered to any one of the inbound email servers published in the DNS MX records for a domain (see Understanding DNS). The TLS Checker analyzes each of the published MX records, in turn,* and reports on the following items.
MX Priority
Email can be delivered to any one of the inbound email servers published in the DNS MX records for a domain (see Understanding DNS). The TLS Checker analyzes each of the published MX records, in turn,* and reports on the following items.
SMTP TLS Enabled?
This checks that the server is listening to SMTP, advertises “STARTTLS” as a feature, and that LuxSci can negotiate a successful TLS connection using some protocol version and cipher. This checks for bare minimum SMTP TLS functionality.
TLS Certificate for:
TLS Certificates are issued for a specific domain or domains. The report lists the primary domain (Common Name) listed in the certificate presented by this server. Note that some certificates can have multiple domain names within them — the report will not display all certificate names, just the primary one (though we support all of them in the next step, “Certificate Verifiable.”
Certificate Verifiable?
In order to properly authenticate a TLS-secured connection, one must have (a) a TLS certificate that is signed by a trusted third-party certificate authority (CA), (b) that has not expired, and (c) whose listed domain name(s) match the name of the name of the MX record to which your are connecting.
This “verifiable” check look as all three of these criteria.
Unfortunately, most email sending servers do not validate TLS certificates. They do not check if the domains names match, if they are expired, or even if they are trusted. This is because many email servers have issues with their certificates. They often present ones with mismatching names and ones that are “self signed.” This is not great. It means that SMTP TLS provides good protection against passive eavesdropping but not against active main-in-the-middle attacks. There is progress towards “fixing” this issue — see “SMTP MTA STS,” below.
Everyone should working on improve their certificates over time so that eventually SMTP TLS communications can be authenticated as well and commonly as HTTPS communications.
SSL v3 Off?
SSL protocol version 3 is extremely weak in terms of security. It has been abandoned for years by the internet community and best practices are that it should never be enabled on any SSL/TLS-supporting server. See also: SSL vs. TLS: what’s the difference?
If this check finds SSL v3 enabled, it should be disabled ASAP.
TLS v1.0 Supported?
This check lets you know if TLS v1.0 is supported by the server. For general compatibility with email on the internet at large, TLS 1.0 is OK to be used, even according to the very latest NIST 800-52r2 recommendations.
For closed government systems and situations where you know that everyone sending email to you must support TLS v1.2, it is required and/or preferable to disable TLS 1.0 support.
Note that the PCI/DSS requirements that TLS v1.0 not be used do not apply to your inbound email servers, as long as these are independent of the servers involved in credit card processing and/or storage.
TLS v1.2 Supported?
This check lets you know if TLS v1.2 is supported by the server. Every server supporting SMTP TLS should support TLS v1.2.
Weak Ciphers Off?
There is extremely wide support across the internet for strong ciphers. If your server still uses “Export,” “Low,” or “Medium” strength ciphers or ciphers using outdated algorithms like RC2, RC4, and MD4, the server really needs to be updated ASAP. There is generally no reason that such ciphers should still be in use anywhere and they seriously decrease the security of those systems.
Additionally, ciphers using 3DES should be removed from servers as they are known to be vulnerable. There were included in the NIST 800-52r1 recommendations, but have been removed from the 800-52r2 recommendations.
Ideally, all DES ciphers and all ciphers not in the NIST 800-52r1 and 800-52r2 lists should be removed from the server. Or at least, remove all “weak” ciphers.
Having weak ciphers available is especially poor if there is an active man-in-the-middle. If there is only passive eavesdropping, then the client and server will generally pick one of the best available ciphers and not one of the available weak ones. If there is an active man-in-the-middle, all bets are off anyway unless the sender is doing certificate validation or supporting SMTP MTA STS. Weak ciphers should be removed; however, having weak ciphers does not significantly detract from your “Score” currently.
NIST 800-52r1 Good Cipher Support?
In 2014, NIST produced Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. This contains the official recommendations for what TLS ciphers to use for “good security.”
Having good ciphers allows the communications to be more secure against passive eavesdroppers. Using ciphers from the NIST list makes it more likely that they are generally used and are well vetted.
The “revision 2” if this specification is still a “Draft.” It is a best practice to support some or all of the ciphers in the 800-52r1 specification. For more on this, see What level or TLS is required for compliance?
NIST 800-52r2 Better Cipher Support?
NIST produced version 2 of Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. This contains updated official recommendations for what TLS ciphers to use for “good security” and improves on “version 1”.
Having good ciphers allows the communications to be even more secure against passive eavesdroppers. Using ciphers from the NIST list makes it more likely that they are generally used and are well vetted.
The “revision 2” if this specification is still a “Draft;” however, its recommended list of ciphers is better than that in “version 1.” It is a best practice to support the ciphers in 800-52r2 that are not in the 800-42r1 recommendations. For more on this, see What level or TLS is required for compliance?
NIST 800-52r2 Better Cipher Support?
NIST produced version 2 of Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations. This contains updated official recommendations for what TLS ciphers to use for “good security” and improves on “version 1”.
Having good ciphers allows the communications to be even more secure against passive eavesdroppers. Using ciphers from the NIST list makes it more likely that they are generally used and are well vetted.
The “revision 2” if this specification is still a “Draft;” however, its recommended list of ciphers is better than that in “version 1.” It is a best practice to support the ciphers in 800-52r2 that are not in the 800-42r1 recommendations. For more on this, see What level or TLS is required for compliance?
SMTP MTA STS
SMTP MTA Strict Transport Security is a method where you can publish (via DNS and a secure web site) which MX records support TLS for email delivery. Armed with this information, a sender can know that the MX record (a) supports TLS 1.2+, (b) the MX records TLS certificate will validate properly, and (c) TLS should be used on all connections. This goes a long way to prevent active man-in-the-middle attacks and protocol downgrade attacks.
While this specification is still in draft, it is already being adopted by the big players. It is recommended that you setup SMTP MTA STS for your critical email domains.
*Note, in cases where a DNS MX records points to an IP address that is load balanced across a number of servers, the TLS Checker will only test one of those servers: whichever one responds to its request. It is possible that the load balanced servers are not all configured the same and that some may be configured insecurely. This tool does not try to exhaustively determine if that is the case.
Note also, that if your inbound servers are flaky and tend to “time out” or “refuse connections,” then some tests may incorrectly indicate that the server does not support specific things.
Overall Results
The overall results section gives you a general score (between F and A+) based on the results of all of your MX records.
- In particular:
You score is based on the worst MX record. - Your score is significantly impacted by: No TLS 1.2 support, SSL v3 support, using a TLS certificate that is expired or not trusted, and not supporting any NIST 800-52r1 ciphers.
- Your score is slightly impacted by: using a TLS certificate where the hostname does not match the MX records, using weak ciphers, and not supporting any NIST 800-52r2 ciphers.
LuxSci’s SecureLineTM email encryption service supports “Forced TLS” as a method of encryption between LuxSci and recipient servers. However, we will only permit Forced TLS to be a valid option if the recipient’s inbound email servers:
- ALL support TLS
- ALL support TLS 1.0 and/or TLS 1.2
- All support at least 1 of the ciphers in the NIST 800-52r1 recommendation
Recommendations
If the TLS scan did not return a perfect score, we list recommended improvements for each MX record.