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 :
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
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
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
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
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:
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
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
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
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
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
11 matches
Mail list logo
