chore: Drop support for deprecated TLS versions

[polarathene]

Description

As per the relevant deprecation notice (since July), TLS 1.0 and 1.1 have finally been deprecated by RFC 8896 (Mar 2021).

Support has been dropped from DMS. TLS 1.2 is the new minimum version supported.

Closes #2679

---

Removes support of the following cipher suites:

• ECDHE-ECDSA-AES128-SHA
• ECDHE-RSA-AES128-SHA
• ECDHE-ECDSA-AES256-SHA
• ECDHE-RSA-AES256-SHA
• DHE-RSA-AES128-SHA
• DHE-RSA-AES256-SHA

Impact:

• There are no more supported cipher suites from TLS 1.0 or 1.1 after this.
• Raising the minimum version of TLS supported is now 1.2, we can also remove the workaround to lower the OpenSSL security level (was required for Dovecot with TLS_LEVEL=intermediate).
• Postfix main.cf adds an additional exclude pattern (SHA1) to prevent these cipher suites from being offered on port 25 (uses Postfix medium cipher list minus excluded cipher suites). This was required as the cipher suites are still part of TLS 1.2, but are no longer being supported due to the MAC being SHA1 (see cipher suite links for more details).
• These changes should be acceptable. TLS 1.2 has been around since 2008 - and from my own research since contributing to this project in 2020, should be broadly available with mail servers now. Users that require these removed cipher suites should be niche if any, and may add them back via user-patches.sh.

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) - Potentially, risk should be low.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• 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

[georglauterbach]

LGTM 👍🏼

[casperklein]

For those who are interested, here is a bash one-liner to check mail.log, if TLSv1 / TLSv1.1 is still used:

while read line; do dig -x $line +short; done < <(grep -aP 'TLSv1(\.1)? ' mail.log | grep -Po '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | sort | uniq)

or to check all mail logs, including gziped ones:

while read line; do dig -x $line +short; done < <(zgrep -aP 'TLSv1(\.1)? ' mail.log* | grep -Po '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' | sort | uniq)

This gives an output like this:

internet.nl.
pancake.scanf.shodan.io.
gravy.scanf.shodan.io.
biscuit.scanf.shodan.io.
eggs.scanf.shodan.io.
waffles.scanf.shodan.io.
green.census.shodan.io.
bacon.scanf.shodan.io.

Shodan & Internet.nl are internet scanner and can be ignored.

[polarathene]

@miles170 I see that you're reverting the changes from this PR while rebasing to new releases with a commit reference adding the noise above.

I'd rather hear about your need for that so we're better aware of it and can support the functionality without you needing to carry the patch.

• I can see that your last rebase was prior to our Debian 12 upgrade (so rebased to the last published/tagged release of DMS). The next rebase you do will be with OpenSSL 3.0 and I think the config change for security level will differ slightly, probably need to set level 0.
• Are you still only needing to support TLS 1.2 with the ciphers you're adding back? Is there one you need in particular? These should still be available without enabling TLS 1.0/1.1, just double checking since you did explicitly enable those again.

Our "intermediate" security level I don't think I've altered like the "modern" level when I did an audit due to reviewer concerns at the time. I have considered dropping the "intermediate" level in future but I'm still open towards replacing it with a "legacy" security level for those preferring broader compatibility over what is considered secure (the dropped ciphers from this PR have some security concerns, but mostly regarding CBC prior to TLS 1.2).

[miles170]

@miles170 I see that you're reverting the changes from this PR while rebasing to new releases with a commit reference adding the noise above.

I'd rather hear about your need for that so we're better aware of it and can support the functionality without you needing to carry the patch.

• I can see that your last rebase was prior to our Debian 12 upgrade (so rebased to the last published/tagged release of DMS). The next rebase you do will be with OpenSSL 3.0 and I think the config change for security level will differ slightly, probably need to set level 0.
• Are you still only needing to support TLS 1.2 with the ciphers you're adding back? Is there one you need in particular? These should still be available without enabling TLS 1.0/1.1, just double checking since you did explicitly enable those again.

Our "intermediate" security level I don't think I've altered like the "modern" level when I did an audit due to reviewer concerns at the time. I have considered dropping the "intermediate" level in future but I'm still open towards replacing it with a "legacy" security level for those preferring broader compatibility over what is considered secure (the dropped ciphers from this PR have some security concerns, but mostly regarding CBC prior to TLS 1.2).

Sorry for the noise. I'm currently facing an issue where some of our legacy Windows 7 systems are unable to use TLSv1.2 and can only use TLSv1 (we cannot update the Microsoft-provided packages).

[polarathene]

Sorry for the noise.

No worries, was just concerned about the why :)

I'm currently facing an issue where some of our legacy Windows 7 systems are unable to use TLSv1.2 and can only use TLSv1

Good to know thanks 👍

So to confirm this is for internal systems you manage where you're more concerned about connections to DMS on ports that are enforcing a secure connection, not third-party inbound/outbound traffic on port 25?

Just trying to understand the remaining scenarios where reducing the security of TLS is still necessary.

• If we no longer offer a intermediate catered cipher list and you're still able to establish connections to DMS by a similar legacy opt-in feature, would that be ok?
• I don't think TLS 1.0/1.1 had much left that was considered secure beyond the semi-ok cipher suites dropped in this PR so I assume that's an acceptable tradeoff for you.

[miles170]

So to confirm this is for internal systems you manage where you're more concerned about connections to DMS on ports that are enforcing a secure connection, not third-party inbound/outbound traffic on port 25?

Yes, and legacy internal systems need to communicate with ports 587 and 993 via TLSv1.

If we no longer offer a intermediate catered cipher list and you're still able to establish connections to DMS by a similar legacy opt-in feature, would that be ok?

The legacy opt-in feature is okay, thank you.

I don't think TLS 1.0/1.1 had much left that was considered secure beyond the semi-ok cipher suites dropped in this PR so I assume that's an acceptable tradeoff for you.

This tradeoff is very reasonable and acceptable, but it is not clear whether the semi-ok cipher suites can be used on Windows 7.

[polarathene]

Yes, and legacy internal systems need to communicate with ports 587 and 993 via TLSv1.
The legacy opt-in feature is okay, thank you.

Great!

This tradeoff is very reasonable and acceptable, but it is not clear whether the semi-ok cipher suites can be used on Windows 7.

Oh you're fine! 👍

The "semi-ok" cipher suites I was referring to are listed at the top of this PR and part of what you reverted. With our intermediate cipher list and smtpd_tls_exclude_ciphers I think they were the only ones that may have been available for TLS 1.0/1.1 to connect with.

They should still be available if the other maintainers approve of the proposal. If anything, less secure ciphers may become available which would be the tradeoff, but as it's internal traffic only connecting this that shouldn't be an issue.

Alternative workaround - user-patches.sh

EDIT: While the below two examples should work, I realize that due to our change detection service (check-for-changes.sh), any config changes that trigger the TLS settings to be applied again (certificates renewed), or the relay host config if enabled would undo the changes from the below approach 😩 (on the bright-side, it helps towards getting support back into DMS 👍 )

This should be equivalent to the patch you're carrying, but for our user-patches.sh:

#!/bin/bash

function _enable_tls_v1() {
    local POSTFIX_CONFIG_MAIN='/etc/postfix/main.cf'
    local DOVECOT_CONFIG_SSL='/etc/dovecot/conf.d/10-ssl.conf'

    local TLS_CIPHERS_ALLOW='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-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA'
    local TLS_PROTOCOL_IGNORE='!SSLv2,!SSLv3'
    local TLS_PROTOCOL_MINIMUM='TLSv1'

    # Postfix configuration
    sed -i -r \
        -e "s|^(smtpd?_tls_mandatory_protocols =).*|\1 ${TLS_PROTOCOL_IGNORE}|" \
        -e "s|^(smtpd?_tls_protocols =).*|\1 ${TLS_PROTOCOL_IGNORE}|" \
        -e "s|^(tls_high_cipherlist =).*|\1 ${TLS_CIPHERS_ALLOW}|" \
        "${POSTFIX_CONFIG_MAIN}"

    # Dovecot configuration
    sed -i -r \
        -e "s|^(ssl_min_protocol =).*|\1 ${TLS_PROTOCOL_MINIMUM}|" \
        -e "s|^(ssl_cipher_list =).*|\1 ${TLS_CIPHERS_ALLOW}|" \
        "${DOVECOT_CONFIG_SSL}"

    # Lowers the minimum acceptable TLS version connection to `TLSv1` (from Debian upstream `TLSv1.2`)
    # Lowers Security Level to `1` (from Debian upstream `2`, openssl release defaults to `1`)
    # https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_security_level.html
    # https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1
    # https://dovecot.org/pipermail/dovecot/2020-October/120225.html
    # WARNING: This applies to all processes that use openssl and respect these settings.
    sedfile -i -r \
        -e 's|^(MinProtocol).*|\1 = TLSv1|' \
        -e 's|^(CipherString).*|\1 = DEFAULT@SECLEVEL=1|' \
        /usr/lib/ssl/openssl.cnf
}

Alternative script

If we ignore the TLS cipher suite:

• It should be as simple as switching to the default Postfix medium list instead of our custom list for high (that we configured mandatory to use which is for a encrypt security level on ports 587/465 and any configured relay host).
• Likewise disabling the configured Dovecot customized cipher list to use it's default. Assuming these are still relaxed enough to be compatible with TLS 1.0/1.1.

#!/bin/bash

function _enable_tls_v1() {
    # Postfix configuration (main.cf)
    # - From DMS v14 (Postfix 3.6) you could swap `!SSLv2,!SSLv3` for `>=TLSv1`
    # - `smtp_` for outbound connections (25), `smtpd_` for inbound (25),
    # - `mandatory` applies to authenticated ports (587,465)
    postconf 'smtp_tls_protocols = !SSLv2,!SSLv3'
    postconf 'smtp_tls_mandatory_protocols = !SSLv2,!SSLv3'
    postconf 'smtpd_tls_protocols = !SSLv2,!SSLv3'
    postconf 'smtpd_tls_mandatory_protocols = !SSLv2,!SSLv3'
    # NOTE: DMS does not appear to set the equivalent for `smtp_` if a relay host is configured
    postconf 'smtpd_tls_mandatory_ciphers = medium'

    # Remove all excluded ciphers (doesn't apply to outbound connections, DMS does not configure that):
    # https://github.com/docker-mailserver/docker-mailserver/blob/a815bf5ab44388baecb597a0b83f71872a2d34bc/target/postfix/main.cf#L47
    postconf -X smtpd_tls_exclude_ciphers

    # Dovecot configuration
    # Use default Dovecot setting for ssl_cipher_list by commenting the line out:
    # https://doc.dovecot.org/configuration_manual/dovecot_ssl_configuration/#ssl-security-settings
    sed -i -r \
        -e "s|^(ssl_min_protocol =).*|\1 TLSv1|" \
        -e "s|^(ssl_cipher_list =).*|#\1|" \
        /etc/dovecot/conf.d/10-ssl.conf

    # Lowers the minimum acceptable TLS version connection to `TLSv1` (from Debian upstream `TLSv1.2`)
    # DMS v14 (OpenSSL 3.0) may require `DEFAULT@SECLEVEL=0`
    sed -i -r \
        -e 's|^(MinProtocol).*|\1 = TLSv1|' \
        -e 's|^(CipherString).*|\1 = DEFAULT@SECLEVEL=1|' \
        /usr/lib/ssl/openssl.cnf
}

Instead of the sed call for Postfix, used postconf command, if you still want DMS to keep TLS 1.2+ for outbound connections (if they're not going to those Windows systems) you can remove the smtp_ lines and just keep the smtpd_ ones. Likewise if you want to keep the prior smtpd_tls_exclude_ciphers we had without the added SHA1, just adjust the line to assign the previous value like the earlier postconf lines show.

[georglauterbach]

Mhh, this is a difficult one. I absolutely understand the issue at hand, but I am also not a fan of bending software to such "edge cases". Whether it actually is "edge" I am not sure. If the implementation is not too big and easily maintainable, then I see no issue; otherwise, I'd prefer user-patches.sh.

[polarathene]

If the implementation is not too big and easily maintainable

It mostly would just replace / deprecate TLS_LEVEL=intermediate. With the bonus that we don't carry that cipher list anymore. No rush, I'll give it some thought next month perhaps.