0

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.

  • Your 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 tell s_client to do -starttls imap. – dave_thompson_085 Nov 6 '20 at 3:13
  • @dave_thompson_085 I never said I was good at this... :-) I added the output with the -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:48
  • TLS_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? But TLS_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
  • @SteffenUllrich Right, so that's why I'm asking the question here. I have no clue what I'm doing and it still doesn't work. I've been trying all sorts of solutions I've found on the Internet, but many are contradictory and none of the one I've found work properly... – Alexis Wilke Nov 6 '20 at 7:26
  • @AlexisWilke: Try using an explicit TLS1_2 here instead of TLS1. Or try to use SSLv23. (which might include everything). Or try to omit the options completely in the hope that there are sane defaults then. Or try to use a better documented mail server like dovecot. – Steffen Ullrich Nov 6 '20 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.