Continuing the discussion from Skiff Mail:
(Firstly, I’m not suggesting this in order to recommend Skiff Mail, which has other unaddressed issues, but this reminded me of a discussion I recently had)
I think our minimum TLS recommendations for SMTP on Port 25 should be lowered to:
- Require TLS >= 1.2
- Allow TLS >= 1.0
- Server suite preference prioritizing strong ciphers over weak ciphers
- No unsafe TLS configurations (i.e. weak DHE parameters)
- I think >= 2048-bit DHE parameters should be accepted (they are on Hardenize) even though some tests (internet.nl) will flag them because they flag any use of RSA.
The reason for this is compatibility, because SMTP is the only port used for mailserver-to-mailserver communication, and because TLS on the regular SMTP port is only opportunistic encryption, SMTP is regularly plaintext. Hardenize explains this well:
We apply relaxed assessment criteria when evaluating TLS configuration of SMTP servers on port 25. This is because most delivery agents fall back to delivering via plaintext on failure to negotiate encryption. Some configuration elements that can be abused to attack other ports and protocols (e.g., SSLv2 and export cipher suites) are penalized in the same way as for other protocols. We will review this policy in the future.
TLS on all other TLS-supporting email ports (SMTPS 465, Submission 587, IMAPS 993, POP3S 995, etc.) must remain at TLS >= 1.2 and only support strong ciphers, because these ports make TLS mandatory, and are only used for mailserver-to-client communication, so email users have no excuse to not update their clients to one that supports strong encryption.
I’ll give you two examples to demonstrate. Our email server passes all of Hardenize’s Email TLS tests, however under our current criteria it would not be recommended due to allowing weaker encryption on port 25, despite stronger encryption schemes being prioritized. If we did not allow these protocols, communication to and from email servers that don’t support them would be unencrypted, which is worse than weak encryption. My understanding is that many servers out there are still TLS 1.0 only.
On the other hand, Skiff Mail (i.e. Amazon SES) would still not meet our requirements, but not because of the supported TLS versions and cipher suites, rather because of their improper Diffie-Hellman Key Exchange parameters, which is a separate issue:
One problem with this is that I can’t find any quick tests that will check the TLS configuration of ports 587, etc. We can do this with nmap, i.e.:
nmap --script ssl-enum-ciphers -p 587 mail.jonaharagon.net
Good
Nmap scan report for mail.jonaharagon.net (65.109.20.153)
Host is up (0.12s latency).
PORT STATE SERVICE
587/tcp open submission
| ssl-enum-ciphers:
| TLSv1.3:
| ciphers:
| TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| cipher preference: server
|_ least strength: A
nmap -Pn --script ssl-enum-ciphers -p 587 smtp.gmail.com
Not Good
Nmap scan report for smtp.gmail.com (172.217.214.108)
Host is up (0.022s latency).
rDNS record for 172.217.214.108: jr-in-f108.1e100.net
PORT STATE SERVICE
587/tcp open submission
| ssl-enum-ciphers:
| TLSv1.0:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.1:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| compressors:
| NULL
| cipher preference: server
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.2:
| ciphers:
| TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
| TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
| compressors:
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| TLSv1.3:
| ciphers:
| TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
| TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
| TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
| cipher preference: client
|_ least strength: C
