One of my customer just upgraded Thunderbird to version 78 and now he can't receive emails because it thinks that the IMAP connection is not TLS 1.2... but when I check with tools on the Internet, it tells me that it is v1.2.
What can I do to make it work again?
Here are some of the imapd-ssl settings:
IMAP_TLS_REQUIRED=1
TLS_PROTOCOL="TLS1_1:TLS1"
TLS_PRIORITY="SECURE128:+SECURE192:-VERS-ALL:+VERS-TLS1.2"
TLS_STARTTLS_PROTOCOL=TLS1
TLS_CIPHER_LIST=HIGH:MEDIUM:!ADH:!MD5:!aNULL:!eNULL:!LOW:!EXP:!RC4
Anything blatantly wrong in these settings?
Note that I've seen this post: Thunderbird 78 won't connect to Exchange-backed IMAP account but I'm not interested in a hack. I want the server to use TLS 1.2 at least.
I now tested with openssl and here is the output:
openssl s_client -connect mail.example.com:143 -tls1_2
CONNECTED(00000003)
140310946449048:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:362:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1604626110
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
It clearly shows that version 1.2 is supported. I'm not too sure what the peer/client certificate messages mean. Could that be the culprit?
Output update with correct openssl
command
As pointed out by @ the test above is incorrect, I need to have openssl send a STARTTLS
message otherwise it doesn't start the encryption. I'd like to know why does it say TLS 1.2 above, though...
$ openssl s_client -connect mail.example.com:143 -starttls imap
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = *.example.com
verify return:1
---
Certificate chain
0 s:/CN=*.example.com
i:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
1 s:/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
...snip...
-----END CERTIFICATE-----
subject=/CN=*.example.com
issuer=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
---
No client certificate CA names sent
---
SSL handshake has read 3307 bytes and written 617 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : AES256-SHA
Session-ID: B2...FA
Session-ID-ctx:
Master-Key: FB...AB
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 7200 (seconds)
TLS session ticket:
0000 - a9 ... 6f ...}.,.........o
0010 - 17 ... 2f .....&..YX.M.8n/
0020 - a9 ... 7f ......Q....Y..*.
0030 - c9 ... a9 .!'f>06Q...z../.
0040 - ff ... 1f .SZ...Z...;X....
0050 - 94 ... f0 .Se[.+...@.Cy...
0060 - c9 ... 44 ..@...gXz.z.gzVD
0070 - b3 ... 3d .......`.'.....=
0080 - a2 ... bf ..=2.Z....^.):..
0090 - 64 ... 42 d.>B....&.+.!..B
Start Time: 1604637492
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
. OK CAPABILITY completed
Now that looks a lot better... except for the fact that it says TLSv1. So the setup is incorrect since I'd like it to say TLSv1.2 instead.
Resolution
After many attempts, I was not able to get TLS v1.2 to work with courier. This is strange since it just sets up OpenSSL, so I'm not too sure why it would prevent that version, somehow. But whatever the settings, it never went over TLS v1.
So as suggested in a comment I just switched to dovecot which even has a Migration script specific to courier. That worked. Thunderbird reload all the emails once, but it's working as expected now and I did not lose any of my folders.
s_client
test absolutely does not "clearly show[] that version 1.2 is supported". For STARTTLS on 143 (as opposed to implicit TLS on 993) you need to tells_client
to do-starttls imap
. – dave_thompson_085 Nov 6 '20 at 3:13-starttls
option and sure enough it comes back with TLSv1. Would removing some additional ciphers allow for the encryption TLSv1.2? – Alexis Wilke Nov 6 '20 at 4:48TLS_PROTOCOL="TLS1_1:TLS1"
- isn't this clearly restricting the protocol to TLS 1.1 and TLS 1.0. But this is probably for imaps, i.e. port 993? ButTLS_STARTTLS_PROTOCOL=TLS1
looks even worse, i.e. restricting imap+STARTTLS (port 143) to TLS 1.0. Unfortunately clear documentation for courier-imap seems to be lacking. – Steffen Ullrich Nov 6 '20 at 6:01