[enhancement]: Cipher suite configuration is fragile and limited

[Avamander]

Which feature or improvement would you like to request?

I'd like to see TLS ciphersuite functionality a bit more robust against (mis)configurations.

• Cipher suites that aren't supported shouldn't always cause a fatal error. This makes it really difficult to figure out what ciphers are supported (or which primitive is lacking) as there's no HIGH:MEDIUM:!LOW shorthand (like OpenSSL has). This will cause really annoying issues should any of the ciphersuites be deprecated in the future and not included in the builds.

• Too restrictive of a cipher set should be warned against. E.g. only two "strong" TLSv1.2 ciphersuites is really not a good idea. Ideally it would also fall back to a safe default if there are none valid for a specific protocol. Security-related misconfigurations should in general be hard.

• The example configuration should also include ciphers needed for elliptic certificates. So TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 in addition to current TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256. This omission can cause misconfigurations.

• Support of secure (PFS) ciphers such as TLS_ECDHE_ECDSA_WITH_AES_256_CCM, TLS_ECDHE_ECDSA_WITH_AES_128_CCM (and their RSA equivalents) should be added to the Docker images.

• Support for TLSv1.1 in the Docker images.

I will note that I would certainly love to run a TLSv1.3-only MTA, but considering how the fallback is usually going to be plaintext, TLSv1.1 and/or "sufficient" ciphersuites are infinitely more preferable.

Code of Conduct

• I agree to follow this project's Code of Conduct

[mdecimus]

Thank you for the suggestion, the TLS documentation has now been updated. Please note that in the configuration file distributed with Stalwart the ciphers setting has been commented out, which means that all available cipher suites are offered to clients.

Regarding TLSv1.1 and cipher suite support, Stalwart Mail Server delegates encryption to the rustls library which supports the following cipher suites:

• TLS13_AES_256_GCM_SHA384
• TLS13_AES_128_GCM_SHA256
• TLS13_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

I agree with your point that bad encryption is better than no encryption. However, since rustls does not have plans to support TLSv1.1, it won't be possible to support this version in Stalwart either.
OpenSSL is not used in this project because, with the exception of the SQLite driver, Stalwart Mail Server aims to be a 100% Rust code base.

[Avamander]

Thank you for the suggestion, the TLS documentation has now been updated.

Awesome! Thanks.

Please note that in the configuration file distributed with Stalwart the ciphers setting has been commented out, which means that all available cipher suites are offered to clients.

I guess that could be mentioned in documentation as well. It seems that with at least rusttls it isn't possible to increase compatibility by defining a custom set of ciphersuites.

If anything, considering the current ciphersuite support, it would be good to emit a warning if someone does define a list.

which supports the following cipher suites:

Thanks for the list. It's a pity that AES-CCM ciphersuites are missing.

I agree with your point that bad encryption is better than no encryption. However, since rustls does not have plans to support TLSv1.1, it won't be possible to support this version in Stalwart either. OpenSSL is not used in this project because, with the exception of the SQLite driver, Stalwart Mail Server aims to be a 100% Rust code base.

That is somewhat unfortunate but understandable.

[mdecimus]

If anything, considering the current ciphersuite support, it would be good to emit a warning if someone does define a list.

I agree, I'll add that to the roadmap.

It's a pity that AES-CCM ciphersuites are missing.

In case you want to take a look at why rustls does not support certain protocols, there is a non features section in their documentation.

[Avamander]

In case you want to take a look at why rustls does not support certain protocols, there is a non features section in their documentation.

AES+CCM ciphersuites that are part of TLSv1.2 seem to provide Perfect Forward Security and AFAIK CCM is separate from MAC-then-encrypt modes. This conclusion seems to be supported by rustls/rustls#1034 still being open. This is however mostly out of the scope of this project.