Skip to content

Conversation

@georglauterbach
Copy link
Member

@georglauterbach georglauterbach commented Aug 18, 2025

Description

This patch removes all custom DH parameters from DMS.

Fixes #4538

Type of change

  • Improvement (non-breaking change that does improve existing functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected) NOT SURE YET
  • This change requires a documentation update

Checklist

  • My code follows the style guidelines of this project
  • I have performed a self-review of my code
  • I have commented my code, particularly in hard-to-understand areas
  • I have made corresponding changes to the documentation (README.md or the documentation under docs/)
  • If necessary, I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes
  • I have added information about changes made in this PR to CHANGELOG.md

This patch removes all custom DH parameters from DMS.

The documentation update is NOT included in this patch yet.

ref: #4538

Signed-off-by: Georg Lauterbach <[email protected]>
@georglauterbach georglauterbach added this to the v16.0.0 milestone Aug 18, 2025
@georglauterbach georglauterbach marked this pull request as draft August 18, 2025 21:00
@georglauterbach georglauterbach mentioned this pull request Aug 18, 2025
13 tasks
@github-actions github-actions bot added the meta/stale This issue / PR has become stale and will be closed if there is no further activity label Sep 8, 2025
@docker-mailserver docker-mailserver deleted a comment from github-actions bot Sep 8, 2025
@polarathene polarathene added stale-bot/ignore Indicates that this issue / PR shall not be closed by our stale-checking CI and removed meta/stale This issue / PR has become stale and will be closed if there is no further activity labels Sep 8, 2025
@polarathene
Copy link
Member

TL;DR UPDATE: Dovecot ssl_cipher_list needs to be adjusted accordingly to drop the DHE cipher suites too (testssl.sh appears to misreport supported ciphersuites as a result), our tests caught the failure thankfully (although it wasn't obvious as to why unexpected suites were dropped)

( "intermediate" )
local TLS_INTERMEDIATE_SUITE='ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256'


Test failure in test/tests/parallel/set2/tls_cipherlists.bats is expected due to the removal of the FFDHE params, but these two particular tests have failed a bit unexpectedly:

[Security] (TLS) (cipher lists) 'TLS_LEVEL=intermediate' + RSA

# -- output differs --
# expected : "ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES128-SHA256 DHE-RSA-AES256-SHA256"
# actual   : "ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384"
# --


[Security] (TLS) (cipher lists) 'TLS_LEVEL=intermediate' + ECDSA with RSA fallback
# -- output differs --
# expected : "ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 DHE-RSA-AES128-SHA256 DHE-RSA-AES256-SHA256"
# actual   : "ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384"
# --

The actual has additionally excluded some CBC suites:

ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384

All dropped DHE ciphers were DHE-RSA (RSA cert for authentication), expected as there is none for ECDSA certs.

AES-CBC cipher is not an AEAD cipher, so only AEAD ciphers remain after this change. Apart from slight priority order/sort of the cipher suites between modern and intermediate TLS_LEVEL setting, these two profiles are now equivalent (EDIT: Only for Dovecot).


All related test failures were occurring at _verify_cipherlists() for the IMAP port 143, so this is Dovecot specific, confirming the difference to Postfix (which is leveraging the OpenSSL 3.0 support to continue supporting the DHE cipher suites).

# IMAP: Mandatory STARTTLS Explicit(143) and Implicit(993) TLS
check_cipherlists "${RESULTS_PATH}/port_143.json"

Since Postfix and Dovecot now diverge, we will need to either:

  • A: Update the tests with separate expected ciphersuite expectations between the two.
  • B: Configure Postfix to exclude the extra ciphers (shouldn't be necessary)
  • C: Retain the DH config for Dovecot. It's less likely that these ciphers are needed for Dovecot clients however but it would retain parity between Postfix and Dovecot 😅

For option A we would only have the following comparisons differing:

# RSA:
CIPHER_LIST["intermediate-rsa_TLSv1_2"]='"ECDHE-RSA-CHACHA20-POLY1305 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 DHE-RSA-AES128-SHA256 DHE-RSA-AES256-SHA256"'
CIPHER_LIST["modern-rsa_TLSv1_2"]='"ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384"'

# ECDSA + RSA fallback, dual cert support:
CIPHER_LIST["intermediate-ecdsa-rsa_TLSv1_2"]='"ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 DHE-RSA-AES128-SHA256 DHE-RSA-AES256-SHA256"'
CIPHER_LIST["modern-ecdsa-rsa_TLSv1_2"]='"ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES256-GCM-SHA384"'

Which needs to be used in _verify_cipherlists() only here:

# IMAP: Mandatory STARTTLS Explicit(143) and Implicit(993) TLS
check_cipherlists "${RESULTS_PATH}/port_143.json"
check_cipherlists "${RESULTS_PATH}/port_993.json"
# POP3: Mandatory STARTTLS Explicit(110) and Implicit(995)
check_cipherlists "${RESULTS_PATH}/port_110.json"
check_cipherlists "${RESULTS_PATH}/port_995.json"

This could be supported similar to how the port 25 variants are already done, using a suffix as a 2nd option for the lookup key:

# Compares the expected cipher lists against logged test results from `testssl.sh`
function check_cipherlists() {
local RESULTS_FILEPATH=$1
local p25=$2 # optional suffix
compare_cipherlist "cipherorder_TLSv1_2" "$(get_cipherlist "TLSv1_2${p25}")"
compare_cipherlist "cipherorder_TLSv1_3" "$(get_cipherlist 'TLSv1_3')"
}

Doing so with a suffix like _dovecot would work but will need a similar workaround for the the ECDSA variants that have no difference:

# ECDSA:
CIPHER_LIST["intermediate-ecdsa_TLSv1_2"]='"ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-SHA256 ECDHE-ECDSA-AES256-SHA384"'
CIPHER_LIST["modern-ecdsa_TLSv1_2"]='"ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305"'

# Port 25 is unaffected by `TLS_LEVEL` profiles, thus no difference for modern:
CIPHER_LIST["modern-rsa_TLSv1_2_p25"]=${CIPHER_LIST["intermediate-rsa_TLSv1_2_p25"]}
CIPHER_LIST["modern-ecdsa_TLSv1_2_p25"]=${CIPHER_LIST["intermediate-ecdsa_TLSv1_2_p25"]}
CIPHER_LIST["modern-ecdsa-rsa_TLSv1_2_p25"]=${CIPHER_LIST["intermediate-ecdsa-rsa_TLSv1_2_p25"]}


UPDATE: I've since found that the ECDHE mentioned cipher suites still negotiate successfully with openssl if choosing to use that ciphersuite directly:

timeout 1 openssl s_client -tls1_2 -cipher ECDHE-RSA-AES256-SHA384 -connect mail.example.test:143 -starttls imap -CAfile /tmp/tls/ca-cert.pem

The failure appears to be specific to testssl.sh itself and how it was handling server preference selection, where it bailed as soon as it came across one of the DHE cipher suites we still have listed for ssl_cipher_list in 10-ssl.conf, which Dovecot mistakenly communicated / implied that it supported negotiating those ciphersuites with the connecting client 😓 (technically not a bug per se, as it reflects what any client would do, like OpenSSL when negotiating a compatible cipher against server preference)

( "intermediate" )
local TLS_INTERMEDIATE_SUITE='ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256'

# Prefer the server's order of ciphers over client's.
ssl_prefer_server_ciphers = yes

I've been thinking we should disable server preference for some time now (at least with TLS_LEVEL=modern which uses all AEAD ciphers, but TLS_LEVEL=intermediate and Postfix port 25 does not..). EDIT: As noted in next paragraph, client preference is still affected too.

I think we may have seen some bug reports potentially related to this selection order "bug" in the past but the errors reported weren't helpful at identifying that 😓 (the problem of misconfigured server service like Dovecot here also affects negotiation with client preference)


Beyond the adjustment to the tests, we still need to consider docs. Which I'll address when I return to this (I'll apply any needed changes at that point too). Spent too much troubleshooting the above today 😝

@georglauterbach
Copy link
Member Author

Since Postfix and Dovecot now diverge, we will need to either:

Additional question before: Should we try to somehow update to Debian 13 first and then decide on this, if possible? We are currently seeing the Debian 12 / Dovecot 2.3 behavior - maybe we'd be having double work if we change it now, update, and then have to change it again.

@polarathene
Copy link
Member

Should we try to somehow update to Debian 13 first and then decide on this, if possible?

That's a good point. I don't think much will change though.

Given that Postfix will continue to provide DHE cipher suite support via the OpenSSL 3.0 fallback they have (which seems to be Postfix specific), and Dovecot only works by ensuring ssl_cipher_list excludes the DHE cipher suites, we could just retain configuration for DHE support in Dovecot?

I think the ability to customize can still be dropped since there shouldn't be a need to keep that, and we can update the docs for anyone that would want that.

@georglauterbach
Copy link
Member Author

Given that Postfix will continue to provide DHE cipher suite support via the OpenSSL 3.0 fallback they have (which seems to be Postfix specific), and Dovecot only works by ensuring ssl_cipher_list excludes the DHE cipher suites, we could just retain configuration for DHE support in Dovecot?

Sounds good 👍🏼

I think the ability to customize can still be dropped since there shouldn't be a need to keep that, and we can update the docs for anyone that would want that.

Agreed 👍🏼

I will be tackler some smaller issues that are still to be done before we have a more thorough version of #4536. If you can tackle this PR, I'd be very grateful.

@polarathene
Copy link
Member

polarathene commented Sep 9, 2025

If you can tackle this PR, I'd be very grateful.

Yes no worries, I'll take care of it tomorrow if I can spare the time 👍

UPDATE: Will be a bit longer as I need to take some time to recover from an injury 😅


NOTE: Latest push is still WIP.

- Better document cipher suite support.
- Custom DH params revised.
- Additional note about impact of disabling DH params and how to exclude DHE cipher suites.
@github-actions
Copy link
Contributor

Documentation preview for this PR is ready! 🎉

Built with commit: 8461468

@georglauterbach
Copy link
Member Author

georglauterbach commented Nov 14, 2025

@polarathene I'd like to work on the Debian 13 changes again. If you cannot pick this up, I can give it a try. Just tell me what you'd like to see implemented.

@georglauterbach georglauterbach moved this to Implementation Phase in DMS Features & Tasks Nov 14, 2025
@polarathene
Copy link
Member

Unfortunately past me didn't leave a checklist when I got interrupted by an injury, so what I intended to tackle on the docs front is unclear (I lost any local work associated to this PR when my system crashed again).

I did make a mention about the test failure at least, we need to exclude the DHE cipher defaults from Dovecot, otherwise even without a configured FFDHE params file it will still accept negotiating these cipher suites which will fail. The alternative is to keep DHE params, which may be useful for legacy IMAP/POP3 clients, but I did update the docs for users that would require that support.

I'll give this a glance over soon so the PR can unblock you.

@georglauterbach
Copy link
Member Author

I'll have some days off that I'd like to dedicate to DMS soon. @polarathene can we get this PR ready for review and merge it to unblock me? :)

@polarathene
Copy link
Member

can we get this PR ready for review and merge it to unblock me? :)

I can try to squeeze in some time for this over the next few days. Juggling quite a bit atm.

Just to be clear I don't believe this PR should be blocking you? IIRC we were looking at dropping DH params which this PR does focus on but Dovecot 2.4 was fine to keep DH params present.

Was there something else concerning as a blocker?

@georglauterbach
Copy link
Member Author

Just to be clear I don't believe this PR should be blocking you? IIRC we were looking at dropping DH params which this PR does focus on but Dovecot 2.4 was fine to keep DH params present.

Was there something else concerning as a blocker?

Sorry for the late response; I was way busier than I thought I'd be. I was under the impression this PR was blocking the Debian 13 PR. Never mind me then, I'll tend to it in the next days.

PS: I wish you a happy new year @casperklein @polarathene! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/configuration (file) area/documentation area/security kind/update Update an existing feature, configuration file or the documentation service/dovecot service/postfix stale-bot/ignore Indicates that this issue / PR shall not be closed by our stale-checking CI

Projects

Status: Implementation Phase

Development

Successfully merging this pull request may close these issues.

update: drop support for DHE params

3 participants