Improve Transport Encryption

[yawnbox]

Hello. Kindly,

Thank you for prioritizing TLS_AES_256_GCM_SHA384 and x25519 in the default DeltaChat nginx configuration.

However, the overall state of this TLS configuration is not good. You're defaulting to RSA-2048 asymmetric keys. Please only support RSA-4096. You're supporting a myriad of legacy protocols and cipher suites. TLS 1.2 is 17 years old, please turn off TLS 1.2. We are in 2025; OpenSSL 3.5, now 3.6, supports MLKEM groups. When arguing on fedi about why DeltaChat is "better" than Signal, then you should have some basic quantum resistance.

Here are some suggestions -- with OpenSSL 3.6:

certbot certonly -d <hostname> --key-type rsa --rsa-key-size 4096

    ssl_protocols TLSv1.3;
    ssl_conf_command Groups X25519MLKEM768:SecP384r1MLKEM1024:SecP256r1MLKEM768:MLKEM1024:X25519:secp384r1;
    ssl_conf_command Options +ServerPreference;
    ssl_conf_command Options +PrioritizeChaCha;
    #ssl_conf_command Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384;

You can test DeltaChat servers for PCQ groups with this script:

https://github.com/yawnbox/test-pqc/

Control:

$ ./test-pqc.sh 
Enter domain to test (e.g. example.com): yawnbox.eu

Target : yawnbox.eu
Server : nginx
OpenSSL: 3.5.1 1 Jul 2025 (Library: OpenSSL 3.5.1 1 Jul 2025)

Key        TLS      Group                                  Cipher                              Res 
───────────────────────────────────────────────────────────────────────────────────────────────────
RSA(4096)  TLSv1.3  SecP384r1MLKEM1024                     TLS_AES_256_GCM_SHA384              OK
RSA(4096)  TLSv1.3  SecP384r1MLKEM1024                     TLS_CHACHA20_POLY1305_SHA256        OK
RSA(4096)  TLSv1.3  SecP384r1MLKEM1024                     TLS_AES_128_GCM_SHA256              OK
RSA(4096)  TLSv1.3  SecP256r1MLKEM768                      TLS_AES_256_GCM_SHA384              OK
RSA(4096)  TLSv1.3  SecP256r1MLKEM768                      TLS_CHACHA20_POLY1305_SHA256        OK
RSA(4096)  TLSv1.3  SecP256r1MLKEM768                      TLS_AES_128_GCM_SHA256              OK
RSA(4096)  TLSv1.3  X25519MLKEM768                         TLS_AES_256_GCM_SHA384              OK
RSA(4096)  TLSv1.3  X25519MLKEM768                         TLS_CHACHA20_POLY1305_SHA256        OK
RSA(4096)  TLSv1.3  X25519MLKEM768                         TLS_AES_128_GCM_SHA256              OK
RSA(4096)  TLSv1.3  MLKEM1024                              TLS_AES_256_GCM_SHA384              OK
RSA(4096)  TLSv1.3  MLKEM1024                              TLS_CHACHA20_POLY1305_SHA256        OK
RSA(4096)  TLSv1.3  MLKEM1024                              TLS_AES_128_GCM_SHA256              OK
RSA(4096)  FAIL     MLKEM768                               TLS_AES_256_GCM_SHA384              FAIL
RSA(4096)  FAIL     MLKEM768                               TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(4096)  FAIL     MLKEM768                               TLS_AES_128_GCM_SHA256              FAIL
RSA(4096)  FAIL     MLKEM512                               TLS_AES_256_GCM_SHA384              FAIL
RSA(4096)  FAIL     MLKEM512                               TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(4096)  FAIL     MLKEM512                               TLS_AES_128_GCM_SHA256              FAIL
RSA(4096)  FAIL     X448MLKEM1024                          TLS_AES_256_GCM_SHA384              FAIL
RSA(4096)  FAIL     X448MLKEM1024                          TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(4096)  FAIL     X448MLKEM1024                          TLS_AES_128_GCM_SHA256              FAIL

Summary: 12 OK, 9 FAIL  (timeout=3s)

DeltaChat:

$ ./test-pqc.sh 
Enter domain to test (e.g. example.com): delta.disobey.net

Target : delta.disobey.net
Server : nginx
OpenSSL: 3.5.1 1 Jul 2025 (Library: OpenSSL 3.5.1 1 Jul 2025)

Key        TLS      Group                                  Cipher                              Res 
───────────────────────────────────────────────────────────────────────────────────────────────────
RSA(2048)  FAIL     SecP384r1MLKEM1024                     TLS_AES_256_GCM_SHA384              FAIL
RSA(2048)  FAIL     SecP384r1MLKEM1024                     TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(2048)  FAIL     SecP384r1MLKEM1024                     TLS_AES_128_GCM_SHA256              FAIL
RSA(2048)  FAIL     SecP256r1MLKEM768                      TLS_AES_256_GCM_SHA384              FAIL
RSA(2048)  FAIL     SecP256r1MLKEM768                      TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(2048)  FAIL     SecP256r1MLKEM768                      TLS_AES_128_GCM_SHA256              FAIL
RSA(2048)  FAIL     X25519MLKEM768                         TLS_AES_256_GCM_SHA384              FAIL
RSA(2048)  FAIL     X25519MLKEM768                         TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(2048)  FAIL     X25519MLKEM768                         TLS_AES_128_GCM_SHA256              FAIL
RSA(2048)  FAIL     MLKEM1024                              TLS_AES_256_GCM_SHA384              FAIL
RSA(2048)  FAIL     MLKEM1024                              TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(2048)  FAIL     MLKEM1024                              TLS_AES_128_GCM_SHA256              FAIL
RSA(2048)  FAIL     MLKEM768                               TLS_AES_256_GCM_SHA384              FAIL
RSA(2048)  FAIL     MLKEM768                               TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(2048)  FAIL     MLKEM768                               TLS_AES_128_GCM_SHA256              FAIL
RSA(2048)  FAIL     MLKEM512                               TLS_AES_256_GCM_SHA384              FAIL
RSA(2048)  FAIL     MLKEM512                               TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(2048)  FAIL     MLKEM512                               TLS_AES_128_GCM_SHA256              FAIL
RSA(2048)  FAIL     X448MLKEM1024                          TLS_AES_256_GCM_SHA384              FAIL
RSA(2048)  FAIL     X448MLKEM1024                          TLS_CHACHA20_POLY1305_SHA256        FAIL
RSA(2048)  FAIL     X448MLKEM1024                          TLS_AES_128_GCM_SHA256              FAIL

Summary: 0 OK, 21 FAIL  (timeout=3s)

I understand that legacy mail servers need to support a broader range of transport encryption. However, I have absolutely no interest in passing legacy email. We run a relay to support DeltaChat only.

My testing was performed on our relay, delta.disobey.net. Thank you for your work.

[missytake]

Looking at it later in detail, just one comment for now as it's my job to hold up the interoperability flag ;)

I understand that legacy mail servers need to support a broader range of transport encryption. However, I have absolutely no interest in passing legacy email. We run a relay to support DeltaChat only.

Right now, any Delta Chat profile which has been around for longer than May 2024 is using a classic mail server, so we can not assume that everyone who is using the app is on chatmail relays.

And there continue to be legit usages for classic mail servers, e.g. if the same profile needs to be compatible with classic mail users, that could be an organizational account, a team-bot, the 2-3 friends which you can only reach via e-mail, etc.

With multi-transport, this might not be a problem anymore - if we can at some point create relay addresses for any profile which fails to deliver a message to a chatmail relay via a classic mail server, we can safely turn it on.

For now, it would be worthwhile to measure how many of these servers rely on outdated ciphers :) shouldn't be hard to do, and on nine we get a lot of mail from various servers. Note that even today, our mail queue is full (350+) of mails which can't be delivered because of TLS problems.

We could also start making the TLS configuration more strict, but put more servers on the may list. Right now we only exempted nauta.cu, which is used by many Cubans who constitute one of the largest Delta Chat user bases. They rely on nine.testrun.org chatbots for basic internet functionality, when nauta.cu is the only thing that works for them. But other mail servers where burnt-out and/or hobbyist admins can't handle the demands of modern email could be put there as well.

Generally I also wouldn't consider it super-urgent - we rely on TLS encryption mostly for protecting metadata, everything else is still openPGP encrypted after all, where PQC is also upcoming.

[adbenitez]

They rely on nine.testrun.org chatbots for basic internet functionality, when nauta.cu is the only thing that works for them.

just a note: notice that nauta.cu (the gov) blocked federation with nine.testrun.org, arcanechat.me and many other chatmail servers since long ago, so interaction between nine and nauta.cu is not of any concern

about people using nauta.cu, most of the Cubans these days use chatmail, not nauta.cu since many don't even know how to create nauta.cu accounts which was a free email account you would get in the past while registering for a "internet WiFi on parks" service the internet provider ETECSA was offering before internet via mobile data was available

[link2xt]

TLS 1.2 is 17 years old, please turn off TLS 1.2.

It does not matter how old TLS 1.2. TLS 1.3 was standardized in 2018.

TLS 1.2 is only enabled on ports 443 and port 25. Port 443 is to allow old devices to see the website, e.g. for users whose only device is some old mobile device. Port 25 is for compatibility with other mail servers, we don't want to reduce interoperability unnecessarily. SMTP ports used for submission and IMAP ports require TLS 1.3: #454 TLS 1.3 has downgrade protection, so there is no immediate threat in supporting TLS 1.2. chatmail core does only one connection attempt with TLS 1.3 preference enabled, it will not try to establish TLS 1.2-only connection if this fails. Can always be argued that leaving TLS 1.2 enabled increases attack surface, but there is no known downgrade attack possible that affects clients supporting TLS 1.3.

We are in 2025; OpenSSL 3.5, now 3.6, supports MLKEM groups.

Debian 12 (bookworm) has OpenSSL 3.0.17. Debian 13 (trixie, stable) has OpenSSL 3.5.1. Upgrading to Debian 13 requires resolving #476

[link2xt]

The only actionable items I see:

1. Increase acmetool RSA key size from the default 2048 to 4096. (acmetool: Increase RSA key size from 2048 to 4096 #688) Replace RSA with ECDSA. (acmetool: use ECDSA keys instead of RSA #689)
2. Change smtpd_tls_security_level for port 25 from may to encrypt and require incoming connections on port 25 to use TLS. Submission ports already have this setting. (opened Require STARTTLS for incoming port 25 connections #684)
3. Require TLS 1.2 for outgoing SMTP connections. Default for smtp_tls_protocols is >=TLSv1 according to postconf -d. We can change it to >=TLSv1.2. We already require TLS for outgoing connections. We may even change it to >=TLSv1.3 and make it impossible to send mails to servers that don't support TLS 1.3, but this will only unnecessarily reduce interoperability, I would not do it without having statistics on the number of mails sent using TLS 1.2. (opened Require TLS 1.2 for outgoing SMTP connections #685)