Forcing Dovecot 2.3.4.1 to use TLSv1.2

Question

Since the new Debian Buster update, I have some issue with TLSv1.3.

Issue: my iOS mail client could not connect to my mail server (12.2) and I do not want to upgrade right now, so I try to find a way to disable TLSv1.3 with dovecot.

The current versions are: OpenSSL 1.1.1c and Dovecot 2.3.4.1

In Dovecot 2.3 the SSL settings are changed from ssl_protocols to ssl_min_protocol.

# Minimum SSL protocol version to use. Potentially recognized values are SSLv3,
# TLSv1, TLSv1.1, and TLSv1.2, depending on the OpenSSL version used.

But I would like to force Dovecot to use TLSv1.2 instead of using a minumum SSL protocol, because Dovecot will try before the highest SSL protocol available first (TLSv1.3). If I set TLSv1.3 it will not use TLSv1.2.

So, anyone known how to force Dovecot 2.3.4.1 to use TLSv1.2?

Solution 1

Not a complete answer, but maybe part of a solution:

1. I tried the solution suggested by @joffrey, but could not get it to work. Enabling or disabling TLSv1.3 ciphersuites in ssl_cipher_list seems to be completely ignored by Dovecot 2.3.4.1. The ssl_prefer_server_ciphers does not have any effect on TLSv1.3 either. No matter what Dovecot settings I tried, I was unable to prevent a client from negotiating TLSv1.3 and choosing any TLSv1.3 ciphersuite it wanted.

This is probably related to the introduction in OpenSSL 1.1.1 of a new method for selecting TLSv1.3 ciphersuites, in addition to the already existing method for selecting ciphers for TLSv1.2 and below. The OpenSSL developers were aware of the inconvenience this would cause, but said it was unavoidable, see https://github.com/openssl/openssl/pull/5392. Dovecot commit 8f6f04eb seems to lay the groundwork for a new Dovecot option probably to be named ssl_ciphersuites as a front-end to the new OpenSSL method for TLSv1.3, also in addition to the existing ssl_cipher_list for TLSv1.2 and below. This commit was first included in Dovecot 2.3.9, but that version has not been packaged for Debian yet. Also, I do not see the option mentioned in the Dovecot NEWS or online documentation, so maybe they are not finished yet.

2. Alternatively, I found that adding MaxProtocol = TLSv1.2 to /etc/ssl/openssl.cnf works (warning: this will change the behaviour of many other programs using OpenSSL as well!):

[system_default_sect]
MinProtocol = TLSv1.2
MaxProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

This immediately prevents Dovecot 2.3.4.1 from negotiating TLSv1.3. No need to even restart it. But, as warned above, this solution also affects other applications, not just Dovecot, so is of limited use.

In an attempt to target the settings to Dovecot exclusively, I tried setting an environment variable to point to a specific config file:

# OPENSSL_CONF=/etc/ssl/openssl-max-tlsv12.cnf dovecot -F

But that did not have any effect on Dovecot. I checked that the variable was visible in the environment and that it worked for other OpenSSL applications. However, I suspect that the OpenSSL library itself does not look at environment variables and that it is considered the responsibility of the calling program (Dovecot) to somehow pass the content of the variable to the library. I doubt that Dovecot does this, because I do not see any use of the OpenSSL CONF library in the Dovecot source code. I also could not get a dovecot application section in the OpenSSL config file to work, nor did I find any Dovecot options for setting an OpenSSL config file location or the application section name to be used from the OpenSSL config file. Perhaps someone else knows how to target OpenSSL settings to a specific program instead of system-wide?

3. Finally, you could always try to edit source code, of course. For the current Debian dovecot package, you could start by duplicating this line, change SSL_CTX_set_min_proto_version to SSL_CTX_set_max_proto_version and then recompile. I did not really want to go that far myself. You might as well just start using upstream directly instead of the distribution package then.

Solution 2

I have not tried or reproduced but you could try to set the ssl_min_protol to TLSv1.2 and define ssl_cipher_list to not include any specific TLS1.3 ciphers.

Solution 3

First, you have to locate the 10-ssl.conf file (usually in /etc/dovecot/conf.d/).

Edit and go to line that contains ssl_protocols (mine is line 52). In that line you can also deny protocols. You can try

ssl_protocols = TLSv1.2 !TLSv1.3

Comments

[Joffrey]

The ssl_protocols configuration parameter was removed in 2.3 (wiki2.dovecot.org/Upgrading/2.3)

[ochbob]

That's what I used with previous Dovecot version, but the latest do not use anymore this variable, now it's ssl_min_protocol =

[ochbob]

I will try this, thank you, but I do not know what should be my ssl_cipher_list ? Right know, it's the default one: ssl_cipher_list = ALL:!kRSA:!SRP:!kDHd:!DSS:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!‌​MD5:!PSK:!RC4:!ADH:!‌​LOW@STRENGTH

[Joffrey]

You could search the internet for a cipher list which does not contain the 'ALL' group, and does not contain ciphers which are in the TLSv1.3 cipher list. This is kind of tricky because all examples would recommend using TLSv1.3. I'm not giving a specific example because I would not like to be responsible for configuring your security. A list of ciphers should be chosen with care and responsibility of maintaining a proper list with 'un-broken' ciphers over time is paramount to a good security policy.

[borekon]

Sorry, didn't noticed i'm using an earlier version of dovecot

[ochbob]

Will try to found out the solution with cypher list.

[David C. Rankin]

Good question and answer -- which pointed me in the right direction. There was another change approximately 10/1/21 in updates to openssl 1.1.1.l-1 and dovecot 2.3.16-1 that killed the ability of older iPhone mail from connecting to the mail server. I don't know whether dovecot improved the ssl_min_protocol option in 10-ssl.conf, but adding ssl_min_protocol = TLSv1 and using all other default values allowed connection again. This solved my "SSL_accept() failed: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol" error.