Relaxing Email TLS Requirements on SMTP Port 25

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

This really is not a good idea, otherwise we would be supporting SSL3 and earlier are “okay”.

Skiff Mail won’t be added until they at very least have CAA or DANE, and a MTA-STS policy.

The fact they have not got one really says a lot about the authors. I think this is being plugged on social media, which is why it keeps getting suggested.

1 Like

What? I don’t even know what you are saying. I need you to re-read, lol

I did read what you wrote.

I doubt that is true at all.

We have already disabled TLS 1.0 and 1.1 for most Microsoft 365 services in the world wide environment. Rollout will continue over the following weeks and months. For Microsoft 365 operated by 21 Vianet, TLS 1.0/1.1 will be disabled on June 30, 2023.

1 Like

We’re recommending the best privacy providers. Not “the average” ones. That change has been there for quite some time, and I do not think it’s going to get anymore relevant.

We should update the link however for:

And point it to the final RFC. The way I read that it doesn’t mean that supporting TLS 1.0 and 1.1 means you get removed, as in the case of Tutanota, Mailbox.org, Startmail, they still do. It means you should be thinking about it.

The reason Skiff’s TLS is marked as yellow, is because of the Weak key exchange:

This server uses key exchange parameters that are weak. When using the ephemeral Diffie-Hellman key exchange (DHE), parameters below 2048 bits are considered weak. For sufficient security, use 2048-bit parameters. It is generally not advisable to use stronger DHE key exchange because there is a measurable performance penalty and there is no meaningful increase in security. A well-configured TLS server should generally prefer the faster ECDHE key exchange anyway. When it comes to ECDHE, aim for at least 256 bits; anything below 200 bits is weak. For best results, use secp256r1 and secp384r1, which are required in practice, and x25519 as an emerging standard.

Key exchange length: 1024

Key exchange algorithm: DHE_RSA

Example suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA

The examples on Hardenize: Comprehensive web site configuration test and privacyguides.org do not show weak key exchanges, so they have an overall green square.

The criteria was roughly written around what Hardenize thought was “important”, enough to give a “green” tick to, vs a “yellow” one.

1 Like

Checking again, I think I misread our current requirements, which seem to be mostly in line with what I’m asking. I actually think the only changes (in addition to the change you mentioned) I’d want to see are:

  • No TLS errors/vulnerabilities when being profiled by tools such as Hardenize, testssl.sh or Qualys SSL Labs, this includes certificate related errors, poor or weak ciphers suites, weak DH parameters such as those that led to Logjam.

Changed to something along the lines of:

  • No TLS errors or vulnerabilities when being profiled by tools such as Hardenize, testssl.sh or Qualys SSL Labs, this includes certificate related errors and weak DH parameters such as those that led to Logjam.
  • A server suite preference (optional on TLSv1.3) for strong cipher suites which support forward secrecy and authenticated encryption.

Because I think “poor or weak cipher suites” is unclear, and Tutanota (probably others) do support weak cipher suites at a lower preference. I also believe server suite preferences are not required for TLSv1.3 to accommodate low-power clients which may only support certain encryption schemes in hardware (since all TLSv1.3 ciphers are considered secure at the moment).

I do think this is clearer.

Agreed.

I think server suite preference is still required. It simply is the server saying “I prefer to talk TLS v1.3”. Yes, the cipher suite for TLS 1.3 is much smaller, you are correct on that.

I think that and replacing draft-ietf-tls-oldversions-deprecate with RFC8996 would also be good.

1 Like

No, server suite preference means that the cipher suite used will be chosen in exactly the order the server prefers based on compatibility, i.e. the order of priority is exactly the order shown on Hardenize:

Thus in this situation, a client could not choose to use TLS_RSA_WITH_AES_256_CCM_8 if it supports TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, for example.

If server suite preference is disabled (i.e. it’s client suite preference) that means the client would be free to choose from any suite on the above list even if it supports a cipher suite stronger than the one it chose to use. It has nothing to do with the TLS version used, which should(?) always be the strongest available.

You see this with Google for example, they have server suite preference enabled for TLSv1.0 and TLSv1.1 and client suite preference enabled for TLSv1.2 (which is questionable) and TLSv1.3.

To further elaborate, the reason you would want client suite preference with TLSv1.3 is because TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, and TLS_AES_128_GCM_SHA256 provide basically the same security, but clients may only support one or two of those efficiently, so the choice should be left up to them for performance reasons.

Oh yeah you are right actually. I remember this from when I was mucking around with RADIUS.

New → In Progress