GNU bug report logs - #11267
24.0.95; gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough).

Previous Next

Package: emacs;

Reported by: "Roland Winkler" <winkler <at> gnu.org>

Date: Tue, 17 Apr 2012 21:16:02 UTC

Severity: normal

Found in version 24.0.95

Fixed in version 24.4

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Nikos Mavrogiannopoulos <n.mavrogiannopoulos <at> gmail.com>, Roland Winkler <winkler <at> gnu.org>, 15057 <at> debbugs.gnu.org, 16253 <at> debbugs.gnu.org, 11267 <at> debbugs.gnu.org, Tassilo Horn <tsdh <at> gnu.org>
Subject: bug#11267: bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits, bug#11267: 24.0.95; gnutls.c: [0] (Emacs) fatal error: The Diffie-Hellman prime sent by the server is not acceptable (not long enough)
Date: Wed, 12 Feb 2014 12:11:41 -0500
(I love how mangled the subject line became)

On Tue, 11 Feb 2014 20:30:58 -0800 Lars Ingebrigtsen <larsi <at> gnus.org> wrote: 

LI> Ted Zlatanov <tzz <at> lifelogs.com> writes:
>> I'm sure we can come up with more helpful messaging.  Does it have
>> to fit in 78 chars?  Can we use buttons?  If so, it could be like this,
>> going over 78 but not too much:
>> 
>> !! remote host X requires lower security [OK once] [OK always] [Cancel] [?]

LI> Yeah, that would be nice.  And, remember, somebody (ahem) also has to
LI> write code to handle invalid certificates.  It could be done the
LI> same way.

Yes, it's a similar UI.  After 24.4.  Is that available as a debbugs
tag, "target-version=24.5" or something?

LI> And if the user types "OK always" for this (and for invalid
LI> certificates), it should be stored using the customize functions.

Right.  I feel Customize is the right place to put certificate
exceptions.  The user can set their custom.el file to be
GnuPG-encrypted if they are concerned.

>> If we provide that simple UI, plus some help messaging, I think we can
>> disable DHE by default.  Based on Nikos' explanation, it seems to be the
>> best way forward.

LI> But why would we disable DHE?  Prefer ECDHE over DHE, certainly, but I
LI> don't understand disabling...

Nikos advocates (and I agree) that it's prudent to add
"!DHE-RSA:!DHE-DSS" to the default priority string.  We can make it easy
for the user to remove that exclusion or make a specific exception as
we've discussed.

Ted




This bug report was last modified 11 years and 153 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.