Closed Bug 1183650 Opened 9 years ago Closed 9 years ago

SSL/TLS connection fails for some servers (POP3 and IMAP) - regression in Thunderbird 38.1.0

Categories

(MailNews Core :: Security, defect)

Product:
MailNews Core
Component:
Security
Platform:
Unspecified
Windows
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 1184488

People

(Reporter: dima, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

connection logging - auth method 0x1000 with tb 38.0.1
36.98 KB, text/plain
Details
connection logging - auth method 0x4 with tb 38.1.0 - login failed entirely
7.62 KB, text/plain
Details 
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:39.0) Gecko/20100101 Firefox/39.0
Build ID: 20150630154324

Steps to reproduce:

After upgrading Thunderbird from 38.0.1 to 38.1.0, I am unable to receive messages using SSL/TLS connection from my @desktopfay.com email address. How to reproduce:

- Select "Tools | Account settings" menu command;
- Click "Account Actions" button and select "Add Mail Account...";
- Enter any name and test@desktopfay.com email address (leave password empty) and click Continue;
- Click "Manual config" button;
- for Incoming select POP3; Server name garibaldi.liquidweb.com; port 995; SSL/TLS; Authentication: Normal password;
- Click "Re-test" button.


Actual results:

Thunderbird 38.1.0 says "Thunderbird failed to find the settings for your email account", and the "Done" button is disabled.


Expected results:

Thunderbird 38.0.1 says "The following settings were found by probing the given server", and the "Done" button is enabled;
OS: Unspecified → Windows
Additional comments:

The POP3/IMAP server is garibaldi.liquidweb.com which became incompatible with TB 38.1.0 (in 38.0.1 everything works fine); Please test newer Thunderbird with this server if possible. Liqidweb.com is a hosting company.

Not only SSL/TLS stopped working in TB 38.1.0 with this server; STARTTLS also fails. The only working option is insecure connection and plaintext password.

SMTP works fine, only POP3/IMAP is affected.
I had this problem with our SMTP server but not the IMAP server. Our IMAP server is running openssl-1.0.1e-30 but our SMTP server was running openssl-0.9.8e-36.

I moved the SMTP server to a CentOS 6.x server with openssl-1.0.1e-30. Thunderbird 38.1.0 now is working.  The root problem is that Thunderbird 38.1.0 does not work with some older openssl libraries. Do not know if that was intentional.
38.1.0 stopped connecting to our old exim 4.80 with SSL
since i can't easily upgrade the mail servers SSL i need a workaround

Loglevel 5 gives only
0[1111140]: SMTP Connecting to: mail.domain.com

Message says
"Sending fo the message failed.
The message could not be sent using Outgoing server (SMTP) mail.domain.com for an unknown reason. Please verify that your Outgoing server (SMTP) settings are correct and try again."
Setup:

Thunderbird version used:
   38.1.0 on Win7Pro64 (SP1, all updated)

Trying to read from an IMAP Server:
   courier-imap-ssl 4.15-1.6 (Debian 8.1 amd64)

The user account is manually configured to have security STARTTLS, password PLAIN.


Problem:

TB hangs indefinately while trying to coontact the IMAP server. Status bar says "Checking mail server capabilities ..." (message does not go away, no mail is retrieved, no other dialogs are shown).

This problem does not occur with the previous version 38.0.1.

Further information:

Generated imap:5 protocol logs of 38.1.0 and previous version 38.0.1

In version 38.0.1

   try to log in
   IMAP auth: server caps 0x4c3325, pref 0x1006, failed 0x0, avail caps 0x1004
   (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
     LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
   trying auth method 0x1000
   got new password
   IMAP: trying auth method 0x1000
   PLAIN auth

In Version 38.1.0

   try to log in
   IMAP auth: server caps 0x4c2325, pref 0x1006, failed 0x0, avail caps 0x4
   (GSSAPI = 0x1000000, CRAM = 0x20000, NTLM = 0x100000, MSN = 0x200000, PLAIN = 0x1000,
     LOGIN = 0x2, old-style IMAP login = 0x4, auth external IMAP login = 0x20000000, OAUTH2 = 0x800000000)
   trying auth method 0x4
   login failed entirely

Analysis:

Only if STARTTLS security is enabled, Version 38.1.0 attempts "old style IMAP login" (which fails) despite the account is explicitly configured to use "PLAIN".

I am available for inquiries for further information.
Similar issues are reported in bug 1184488. For now, I will leave this current bug independent, interpreting it as the specific issue "The root problem is that Thunderbird 38.1.0 does not work with some older openssl libraries." I don't yet know if bug 1184488 is that same issue or not.

I suspect that the answer to "Do not know if that was intentional." is yes, and that the core Mozilla code did some security upgrades that prevent older, less secure version of software from working. So I suppose what we really need are details on the types of certificates being used on these older implementations.
Status: UNCONFIRMED → NEW
Component: Untriaged → Security
Ever confirmed: true
Product: Thunderbird → MailNews Core
Looking at the log excerpt from comment 4, lines are missing that are critical to understanding what is happening. Please post an entire log, either here or privately to rkent@caspia.com  If you must modify it, please be explicit about what you have changed (deleted lines, sanitized URLs, etc.).
(In reply to Kent James (:rkent) from comment #5)
> Similar issues are reported in bug 1184488. For now, I will leave this
> current bug independent, interpreting it as the specific issue "The root
> problem is that Thunderbird 38.1.0 does not work with some older openssl
> libraries." I don't yet know if bug 1184488 is that same issue or not.
> 
> I suspect that the answer to "Do not know if that was intentional." is yes,
> and that the core Mozilla code did some security upgrades that prevent
> older, less secure version of software from working. So I suppose what we
> really need are details on the types of certificates being used on these
> older implementations.

The problem for us was not the SSL certificate used.  We did not change the certificate to make it work. We upgraded the openssl libraries. There are more than 1000 users in our site. Thunderbird automatic upgrade is enabled.  The automatic upgrading to 38.1.0 caused big problem since no on could send emails.
I received a detailed protocol log from tilt (comment 4). His issue is the same as bug 1184488, namely that the server capabilities are not being re-acquired after the security is setup.

This current bug is a mix of SMTP and IMAP issues. For now, if your issue is IMAP please go to bug 1184488. I'll leave this bug open for possible unrelated issue on SMTP and POP3 until I know more.
Acknowledged, I will follow bug 1184488 instead. Thank you for looking into this.
Depends on: 1184488
I strongly suggest that this bug is the same issue as bug 1184488, please see my detailed comments in bug 1184488 comment 7.

I will dup this bug to that one when I get some confirmations that the DHE key length issue is also affected SMTP and POP3, but since it is a low-level SSL issue I would expect that SMTP and POP3 would act the same.

The likely resolution of this is WONTFIX and you need to update the certificates to use 1023 bits or stronger.
nope, i'm using a certificate with a 4k SHA-256 key ^^
(In reply to Kent James (:rkent) from comment #10)
> I strongly suggest that this bug is the same issue as bug 1184488, please
> see my detailed comments in bug 1184488 comment 7.
> 
> I will dup this bug to that one when I get some confirmations that the DHE
> key length issue is also affected SMTP and POP3, but since it is a low-level
> SSL issue I would expect that SMTP and POP3 would act the same.
> 
> The likely resolution of this is WONTFIX and you need to update the
> certificates to use 1023 bits or stronger.

We are using a certificate with 2048 bit SHA-256 key but all our 1000+ users could not send emails out before we upgraded the SMTP server with newer openssl libraries. A stronger certificate is necessary but not sufficient. There are more reasons than just a weak certificate why 38.1.0 is not working with some SMTP/IMAP servers.
Hello Kent, 
I ve got the same problem. When updating from TB 38.0.1 to 38.1.0, it's e.g. not possible to create a new account, because TB is not able to check mail server capabilities. And when trying to send an email with an alredy configured mail account, TB cant put the email into the sent folder. Probably because it doesnt know the capabilities of mailserver. I m using a private Mailserver (Debian/Jessie, Postfix, Courier, MySQL, Spamassassin) with a self signed certificate. Here is my test result with openssl:


root@ubuntu14:~# openssl s_client -starttls smtp -connect mail.mydomain.de:25
CONNECTED(00000003)
depth=1 C = DE, ST = NRW, O = Private CA, OU = Administration, CN = www.mydomain.de, emailAddress = info@mydomain.de
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
 0 s:/C=DE/ST=NRW/L=Duesseldorf/O=Private/OU=Administration/CN=mail.mydomain.de/emailAddress=info@mydomain.de
   i:/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
 1 s:/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
   i:/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIEFDCCAvygAwIBAgIJAJ7xmuAqbP2LMA0GCSqGSIb3DQEBCwUAMIGAMQswCQYD
VQQGEwJERTEMMAoGA1UECAwDTlJXMRMwEQYDVQQKDApQcml2YXRlIENBMRcwFQYD
[...]
zbTfTpLnzxLu/x4szOpK9AeVjNDPo0h6kNcHBmIQtOmY8yH9AE2hS93p94GSU4n8
0KsW29Gv90pKp69l82wylBy1zU+IFcFvrqgrWdkUpxanlAodzme152OVpmoDJH/f
VRRmHeKa3mcg1THlHzyca/ipV6gKo2Eebs4lyMsZdQ0SoHJsSX2K6w==
-----END CERTIFICATE-----
subject=/C=DE/ST=NRW/L=Duesseldorf/O=Private/OU=Administration/CN=mail.mydomain.de/emailAddress=info@mydomain.de
issuer=/C=DE/ST=NRW/O=Private CA/OU=Administration/CN=www.mydomain.de/emailAddress=info@mydomain.de
---
No client certificate CA names sent
---
SSL handshake has read 2953 bytes and written 456 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: 06508E248801EABADDF063582C1B99166BD1E0F4A12F4D3BD361E97CB753ADFA
    Session-ID-ctx: 
    Master-Key: D16B8F2ED9CE[...]3327BDF2B5
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 7200 (seconds)
    TLS session ticket:
    0000 - 78 50 ec 69 de 89 a6 33-06 7e 44 3e 98 79 1b 0c   xP.i...3.~D>.y..
    [...]
    0090 - a2 97 ca 79 35 e6 9e 9f-52 89 ae 0b 97 45 f9 8a   ...y5...R....E..

    Start Time: 1437198690
    Timeout   : 300 (sec)
    Verify return code: 19 (self signed certificate in certificate chain)
---
250 DSN
EHLO test
250-mail.mydomain.de
250-PIPELINING
250-SIZE 10240000
250-VRFY
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
DONE
Keywords: regression
no problems with tb 38.0.1
When switching STARTTLS to SLS/TLS in connection settings of tb 38.1.0, I see the following error in maillog of my mailserver (Debian/Jessie, Postfix, Courier)

imapd-ssl: couriertls: accept: error:14094417:SSL routines:SSL3_READ_BYTES:sslv3 alert illegal parameter

I ve reinstalled TB 38.0.1 - no error.
Another info. I ve got two mailservers and the older mailserver is accepting TB 38.1.0!

### Mailserver 1 ####
Debian / Squeeze 
OpenSSL 0.9.8o 01 Jun 2010
courier-imap	4.8.0-3
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1


#### Mailserver 2 #####
Debian / Jessie
OpenSSL 1.0.1k 8 Jan 2015
courier-imap	4.15-1.6
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2


It seems that my older mailserver 1 still can handle the "old-style IMAP-Login" used in TB 38.1.0. 

Are there any infos I could give you to help fixing the problem?
Thuderbird 38.1.0. 

I used these settings (to false) in Thunderbird and now it work correctly.

https://support.mozilla.org/en-US/questions/1067995

"Note that users with the current and older Firefox releases can toggle these prefs to false on the about:config page to disable the cipher suites that are involved with the Logjam vulnerability.

    security.ssl3.dhe_rsa_aes_128_sha
    security.ssl3.dhe_rsa_aes_256_sha "
can confirm that workaround, that does the trick for me :-)
Yes! This workaround works for me too.

I was puzzled where to find the "about:config" page in Thunderbird, and only could find it after some googling. It is at Tools -> Options -> Advanced -> General -> Config Editor (button).
Sorry, 
Thunderbird 38.1.0 has the same issue of Firefox 39, so, I had copied the text from an another thread. 
I just wanted to refer the settings and not to the configuration page
In any case ... yes, it is in Tool -> Option -> Advanced - ... etc
Just as an aside, I had a long conversation with an Apple Mail.app developer at OSCON this weekend, and they are also struggling with the fallout from fixing Logjam. That is, making email secure from Logjam requires rejecting certain configurations, which is generating a ton of support requests.

We agreed what should have been done, for them and us, is to detect the failed DHE and then automatically try the fallback (see comment 10 and the equivalent comment 18) but this option was not made straightforward in the core code that implemented this fix. I doubt if we could get such a change through in time to help with the response to this.
(In reply to Dmitry G. Kozhinov from comment #20)
> Yes! This workaround works for me too.
> 
> I was puzzled where to find the "about:config" page in Thunderbird, and only
> could find it after some googling. It is at Tools -> Options -> Advanced ->
> General -> Config Editor (button).

Thanks for that although in my version it is Options -> Options -> Advanced ->
> General -> Config Editor (button). (38.1.0)
And I can't seem to find other code(s) that have been mentioned. 
Could it be that certain downloads are only providing partial code?
Disabling Cipher security.ssl3.dhe_rsa_aes_128_sha / security.ssl3.dhe_rsa_aes_256_sha in Firefox is not a solution! Today I updated my Ubuntu Desktop and I got the new version Thunderbird 31.8.0. Now I cant read my emails anymore in Ubuntu. It s the same problem as with TB 38.1.0 in windows. The client can't read the capabilities of my newer mailserver. In windows I just reinstalled TB 38.0.1 and deactivated the update function. In Ubuntu it s not that easy to get an older release because of the package management. So I decided to install evolution and it works. 

New thunderbird _can't_ handle a imap server with this
tbarth@ubuntu14:~$ openssl s_client -starttls imap -connect mail.newermailserver.de:143
[...]
SSL handshake has read 2266 bytes and written 479 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : DHE-RSA-AES256-GCM-SHA384
[...]

Cant handle means, that there is no login request. I only see a tcp/ip connection in the mail.log of mailserver.

And new thunderbird _can_ handle this imap server
tbarth@ubuntu14:~$ openssl s_client -starttls imap -connect mail.oldermailserver.de:143
[...]
SSL handshake has read 1551 bytes and written 519 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES256-SHA
[...]
Please check the size of the DH parameters on the server.  If those are 768 bits, new Mozilla programs will silently fail rather than reporting a meaningful error.  Telling people to use stronger certificates as some people have done in these bugs is misleading and unhelpful, as the problem is not the certificate but the ephemeral DH parameters on the server.

Note that on some/many servers, the DH parameters and/or their length are not configurable without recompilation.
> Please check the size of the DH parameters on the server.
Client-side users typically have no control on servers...

> If those are 768 bits, new Mozilla programs will silently fail rather than reporting a meaningful error.
This certainly should be fixed by Mozilla.
I found a solution to my problem. I had to increase the Diffie Hellman Parameter for Courier, because the standard  size is still 768 bit created with mkdhparams on a newer debian system.

mv /etc/courier/dhparams.pem  /etc/courier/dhparams.pem.backup
openssl dhparam -out /etc/courier/dhparams.pem 2048
make permission right of file dhparams.pem same as the old one
restart imap-ssl/pop3-ssl

In the future debian offers a patch, so that mkdhparams will create dhparameters with higher bit size.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787579

Now Thunderbird 38.1.0 can read the mailservers capabilities again. Even Windows Live Mail 2012 is working now, it always closed the connection with an unexpected ssl shutdown.
Your issue would be bug 1184488 then.
Using openssl 1.0.2d (9 Jul 2015) and this command:

openssl s_client -starttls imap -crlf -connect garibaldi.liquidweb.com:143 | grep "Server Temp Key"

I can see:

Server Temp Key: DH, 768 bits

So this is the Logjam issue, and we're using bug 1184488 for this.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
I've just re-loaded 36.0 and all fixed.
Not helpful as far as 38.1.0 but it has solved my issues. All emails have downloaded correctly and are accessible.
I too _was_ affected by this bug on Ubuntu 15.04.  I could read IMAP email but was unable to send - both of which were working on Ubuntu 14.04.2 LTS.

After downgrading Thunderbird from 31.8.0 to 31.6.0, I can now send email.  I've placed a hold on future Thunderbird updates until this is resolved as e-mail has to work!

To see available packages for Ubuntu, simply run:

$ apt-cache policy thunderbird | awk '/Version table/,/^$/'
  Version table:
 *** 1:31.8.0+build1-0ubuntu0.15.04.1 0
        500 http://mirror.internode.on.net/pub/ubuntu/ubuntu/ vivid-updates/main amd64 Packages
        500 http://mirror.internode.on.net/pub/ubuntu/ubuntu/ vivid-security/main amd64 Packages
     1:31.6.0+build1-0ubuntu1 0
        500 http://mirror.internode.on.net/pub/ubuntu/ubuntu/ vivid/main amd64 Packages
        100 /var/lib/dpkg/status

From above, I was able to download to version 31.6.0 by simply running:

$ sudo apt-get install thunderbird=31.6.0+build1-0ubuntu1

ak.
Forgot to mention that disabling the 4 DHE related parameters as stated in bug 1184488 comment #7 (https://bugzilla.mozilla.org/show_bug.cgi?id=1184488#c7) did not resolve my issue.

My mail server is Ubuntu 14.04.2 LTS running Sendmail 8.14 as the MTA and Dovecot 2.2.9 as my IMAP/POP3 server.

When using Thunderbird 31.8.0, Sendmail returns error:
Aug  1 14:11:33 mail sm-mta[23768]: STARTTLS=server: 23768:error:1409442F:SSL routines:SSL3_READ_BYTES:tlsv1 alert insufficient security:s3_pkt.c:1262:SSL alert number 71

ak.
You might be hitting a bug introduced in NSS which incorrectly calculates server key size. You will have to display server public key to see if this is the case.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1211403


(In reply to akmozilla from comment #33)
> Forgot to mention that disabling the 4 DHE related parameters as stated in
> bug 1184488 comment #7
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1184488#c7) did not resolve my
> issue.
> 
> My mail server is Ubuntu 14.04.2 LTS running Sendmail 8.14 as the MTA and
> Dovecot 2.2.9 as my IMAP/POP3 server.
> 
> When using Thunderbird 31.8.0, Sendmail returns error:
> Aug  1 14:11:33 mail sm-mta[23768]: STARTTLS=server:
> 23768:error:1409442F:SSL routines:SSL3_READ_BYTES:tlsv1 alert insufficient
> security:s3_pkt.c:1262:SSL alert number 71
> 
> ak.
You need to log in before you can comment on or make changes to this bug.