Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
Package: libnss3 Followup-For: Bug #787505 I was bitten by this also. My imapd server was a rather dull courier-imap-ssl server, and the DH key length was left as is since its installation (probably etch). My config file was mostly untouched, and no warning came. I followed the procedure here : http://apple.stackexchange.com/questions/206448/imap-account-stopped-working-after-upgrade-to-ios-9-problem-with-cacert-certif?answertab=active#tab-top and it worked fine. -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (950, 'stable'), (200, 'unstable'), (80, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system)
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On 23/06/15 01:27, Daniel Kahn Gillmor wrote: If there is some perverse reason that we need a public IMAP server using terrible DH parameters, i can probably set one up, but i'm not inclined to encourage this sort of situation. Me neither. Given that the rejection of DH keys below 1023 bits is the intended behaviour specified by upstream, and given that we have one workaround that users can apply (setting security.ssl3.*dhe* to false) and one server fix that admins can apply (using a stronger DH temp key), please consider closing this bug as wontfix. This bug report remains as Google-fodder to document the cause, workaround, and server fix. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On Mon 2015-06-22 01:52:32 -0400, Ben Caradoc-Davies wrote: On 21/06/15 11:33, Ben Caradoc-Davies wrote: The best solution is still for all servers to use strong keys (world peace, anyone?). My IMAPS service provider just responded to my request and upgraded to a strong DH temp key. Perhaps world peace is still possible! :-) Three cheers for world peace! This sort of change is exactly the change that we want to see happen :) $ openssl s_client -connect ub007lcs04.cbr.the-server.net.au:993 [...] Server Temp Key: DH, 2048 bits [...] This also means that I no longer have a weak temp key to test against. I consider that a good thing :) If there is some perverse reason that we need a public IMAP server using terrible DH parameters, i can probably set one up, but i'm not inclined to encourage this sort of situation. Mike, let me know if you want such a beast to test things against. --dkg signature.asc Description: PGP signature
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On 21/06/15 11:33, Ben Caradoc-Davies wrote: The best solution is still for all servers to use strong keys (world peace, anyone?). My IMAPS service provider just responded to my request and upgraded to a strong DH temp key. Perhaps world peace is still possible! :-) $ openssl s_client -connect ub007lcs04.cbr.the-server.net.au:993 [...] Server Temp Key: DH, 2048 bits [...] This also means that I no longer have a weak temp key to test against. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On Tue, Jun 02, 2015 at 10:45:25PM +1200, Ben Caradoc-Davies wrote: Package: libnss3 Version: 2:3.19-1 Severity: normal Dear Maintainer, since upgrade to NSS 3.19.1, icedove refuses to connect to an IMAPS server with a Server Temp Key: DH, 768 bits. Workaround is to downgrade to NSS 3.19 or change icedove connection to unencrypted IMAP. To protect against logjam attacks, NSS 3.19.1 refuses to connect to servers with a finite field algorithm key strength less than 1023 bits: https://developer.mozilla.org/en- US/docs/Mozilla/Projects/NSS/NSS_3.19.1_release_notes This behaviour breaks icedove on Debian clients that need to connect to IMAPS servers with weak server temp keys. Note that these are clients which have no control over configuration of remote servers. Workaround is to downgrade to NSS 3.19 or change icedove connection to unencrypted IMAP. Can you check with 3.19.2-1? Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On 21/06/15 09:48, Mike Hommey wrote: Can you check with 3.19.2-1? Mike, I can confirm that this bug is still present in 3.19.2-1 (amd64 from incoming). Tested using icedove as before, against the same server, which still has a 768 bit DH temp key for IMAPS. Error log in icedove reports: Timestamp: 21/06/15 11:01:42 Error: An error occurred during a connection to [hostname elided]:993. SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key) Current workaround is to disable DHE (and weak ciphers) by setting all security.ssl3.* preferences to false except security.ssl3.rsa_aes_256_sha which is set to true. With this setting, IMAPS immediately starts to work. The NSS 3.19.2 release notes state that the minimum key strength requirements will now only affect the minimum keystrengths used in SSL/TLS, and a quick look in the code (sslimpl.h + ssl3con.c) confirms that the test is still applied, so this release is not expected the fix the failure: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19.2_release_notes A better solution may be for NSS to detect a weak DH temp key and renegotiate with a non-DHE cipher. This would improve the user experience, although with silent loss of forward secrecy. The best solution is still for all servers to use strong keys (world peace, anyone?). Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
My current workaround is to disable DHE forward security in icedove about:config by setting security.ssl3.*.dhe* to false. (I also set security.ssl3.rsa* to false except security.ssl3.rsa_aes_256_sha which should be the strongest survivor.) With DHE disabled, I am able to connect to the server over IMAPS with libnss3 3.19.1-2 as the weak DH temp key is not used. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On 03/06/15 01:35, Daniel Kahn Gillmor wrote: This sounds like a feature, not a bug, because it means that users are now aware that their secure imap connections are probably not what they expect. Agreed, but the consequences for Debian end-users are that they may be forced to stop using a not-as-strong-as-it-could-be 768 bit DH key (*not* as weak as a 512 bit break-with-$75-ofAmazon-EC2 DH key). Instead Debian end-users have to switch to unencrypted IMAP. How does this improve security and protect users? In my view, a warning would be more appropriate, at least as a transitional measure. Most users would have no idea why their IMAP suddenly stopped working. At the least there should have been a warning issued when the Debian library was upgraded. Even better, icedove should detect the condition, offer a dire warning, and allow the user to give their informed consent to the situation, as is done for broken certs. In my view, the actions of the Mozilla NSS team were high-handed and inappropriate for a patch version release. Are these IMAP servers in the wild? Could you point me to them? Sure, buried in the original bug report: $ openssl s_client -connect ub007lcs04.cbr.the-server.net.au:993 I have notified the responsible hosting provider that they should upgrade their Courier IMAP DH key to 2048 bits. Given the state of their certificate chain (even their self-signed certificates are expired) I am not optimistic. Kind regards, -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
Just FYI: I hit the same error with my mailserver running Debian's courier-mta: icedove could suddenly no longer send mail using SMTP+STARTTLS. Turns out the (Debian) default for the generated Courier DH key is 768 bits. I filed #787579 to change this default. Regards, -- Mourad DC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
Package: libnss3 Version: 2:3.19-1 Severity: normal Dear Maintainer, since upgrade to NSS 3.19.1, icedove refuses to connect to an IMAPS server with a Server Temp Key: DH, 768 bits. Workaround is to downgrade to NSS 3.19 or change icedove connection to unencrypted IMAP. To protect against logjam attacks, NSS 3.19.1 refuses to connect to servers with a finite field algorithm key strength less than 1023 bits: https://developer.mozilla.org/en- US/docs/Mozilla/Projects/NSS/NSS_3.19.1_release_notes This behaviour breaks icedove on Debian clients that need to connect to IMAPS servers with weak server temp keys. Note that these are clients which have no control over configuration of remote servers. Workaround is to downgrade to NSS 3.19 or change icedove connection to unencrypted IMAP. Kind regards, Ben. Upgrade that caused the failure: libnss3-1d:amd64 (3.19-1, 3.19.1-2), libnss3:amd64 (3.19-1, 3.19.1-2) icedove error console: Error: An error occurred during a connection to mail.example.org:993. SSL received a weak ephemeral Diffie-Hellman key in Server Key Exchange handshake message. (Error code: ssl_error_weak_server_ephemeral_dh_key) Affected server openssl s_client session showing server temp key (note: icedove manual exception added for broken certs): $ openssl s_client -connect ub007lcs04.cbr.the-server.net.au:993 CONNECTED(0003) depth=0 C = US, ST = NY, L = New York, O = Courier Mail Server, OU = Automatically-generated IMAP SSL key, CN = localhost, emailAddress = postmas...@example.com verify error:num=18:self signed certificate verify return:1 depth=0 C = US, ST = NY, L = New York, O = Courier Mail Server, OU = Automatically-generated IMAP SSL key, CN = localhost, emailAddress = postmas...@example.com verify error:num=10:certificate has expired notAfter=Nov 18 06:02:36 2014 GMT verify return:1 depth=0 C = US, ST = NY, L = New York, O = Courier Mail Server, OU = Automatically-generated IMAP SSL key, CN = localhost, emailAddress = postmas...@example.com notAfter=Nov 18 06:02:36 2014 GMT verify return:1 --- Certificate chain 0 s:/C=US/ST=NY/L=New York/O=Courier Mail Server/OU=Automatically-generated IMAP SSL key/CN=localhost/emailAddress=postmas...@example.com i:/C=US/ST=NY/L=New York/O=Courier Mail Server/OU=Automatically-generated IMAP SSL key/CN=localhost/emailAddress=postmas...@example.com --- Server certificate -BEGIN CERTIFICATE- MIIC/zCCAmigAwIBAgIJAJh1IPFs6+cSMA0GCSqGSIb3DQEBBQUAMIG1MQswCQYD VQQGEwJVUzELMAkGA1UECBMCTlkxETAPBgNVBAcTCE5ldyBZb3JrMRwwGgYDVQQK ExNDb3VyaWVyIE1haWwgU2VydmVyMS0wKwYDVQQLEyRBdXRvbWF0aWNhbGx5LWdl bmVyYXRlZCBJTUFQIFNTTCBrZXkxEjAQBgNVBAMTCWxvY2FsaG9zdDElMCMGCSqG SIb3DQEJARYWcG9zdG1hc3RlckBleGFtcGxlLmNvbTAeFw0xMzExMTgwNjAyMzZa Fw0xNDExMTgwNjAyMzZaMIG1MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTlkxETAP BgNVBAcTCE5ldyBZb3JrMRwwGgYDVQQKExNDb3VyaWVyIE1haWwgU2VydmVyMS0w KwYDVQQLEyRBdXRvbWF0aWNhbGx5LWdlbmVyYXRlZCBJTUFQIFNTTCBrZXkxEjAQ BgNVBAMTCWxvY2FsaG9zdDElMCMGCSqGSIb3DQEJARYWcG9zdG1hc3RlckBleGFt cGxlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAwy9JZbZkl3t8HZX3 mKipZZ45Ol4CJJHrdrOMmWXNXk3dAClrs5yJiPmMOA2s9ruexp0aYBKb056m5HfX LUVumnkLSLYUOrhpSYaM/qI4w6rU7X02pHjBynX7kubaTNiPD5OTtp3+C+ZYURdd BsK9iuW8dfkzG0jFtJBMRSR6B1MCAwEAAaMVMBMwEQYJYIZIAYb4QgEBBAQDAgZA MA0GCSqGSIb3DQEBBQUAA4GBAJ3jKR/R6Ferrg+DT2rnPQyu/ahsElnVRj2VtWCy D/AIOSg8T98CfDWUjnZxe5LOaNB4X0VKVh2sEwZYMViCgtPM9v5jXgREsHUUNEaT Wn1ZF17BS3gx70PoLtob6C9yEhERzw3OAIDXVHVBSADK+imSxyxENHv+hUiEoNJw Xz81 -END CERTIFICATE- subject=/C=US/ST=NY/L=New York/O=Courier Mail Server/OU=Automatically-generated IMAP SSL key/CN=localhost/emailAddress=postmas...@example.com issuer=/C=US/ST=NY/L=New York/O=Courier Mail Server/OU=Automatically-generated IMAP SSL key/CN=localhost/emailAddress=postmas...@example.com --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 768 bits --- SSL handshake has read 1424 bytes and written 503 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384 Server public key is 1024 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher: DHE-RSA-AES256-GCM-SHA384 Session-ID: 1458FA1DBEEA2D465D47D3E2B49ED7DAE09C625E5CE84CCFFC4B0C29FFC9A7F7 Session-ID-ctx: Master-Key: 3880E699567D8B9A2D59BB2809A4D97AA2F88264543B130C47B245BE292D3AE2873D002C06F2155EE5C1A9FA5E7D77AA Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: - a4 50 46 e6 9e ce 75 4d-33 7e 60 af 50 21 bf 50 .PF...uM3~`.P!.P 0010 - 62 07 ac f1 1d 55 f0 7a-d2 ce 24 1b 81 06 f1 dc bU.z..$. 0020 - d3 f4 99 4d 6c 9a 78 36-87 a2 a5 0c 86 48 0c 91 ...Ml.x6.H.. 0030 - 0f e6 c2 8f 02 ae 4e d8-14 0a a7 e3 18 17 15 e7 ..N. 0040 - fa 67 22 65 7f 5c 53 97-8e a1 c4 05 2a 56 d1 2f .ge.\S.*V./ 0050 - 03 b4 e2 78 1b d7 94 60-13 48 71 32 3e
Bug#787505: libnss3: NSS 3.19.1 breaks icedove IMAPS to server with DH 786 temp key
On Tue 2015-06-02 06:45:25 -0400, Ben Caradoc-Davies wrote: since upgrade to NSS 3.19.1, icedove refuses to connect to an IMAPS server with a Server Temp Key: DH, 768 bits. Workaround is to downgrade to NSS 3.19 or change icedove connection to unencrypted IMAP. To protect against logjam attacks, NSS 3.19.1 refuses to connect to servers with a finite field algorithm key strength less than 1023 bits: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.19.1_release_notes This behaviour breaks icedove on Debian clients that need to connect to IMAPS servers with weak server temp keys. Note that these are clients which have no control over configuration of remote servers. Workaround is to downgrade to NSS 3.19 or change icedove connection to unencrypted IMAP. This sounds like a feature, not a bug, because it means that users are now aware that their secure imap connections are probably not what they expect. Are these IMAP servers in the wild? Could you point me to them? --dkg -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
