bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits


From: Ted Zlatanov
Subject: bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits
Date: Mon, 07 Oct 2013 18:27:58 -0400
User-agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)

On Sun, 11 Aug 2013 22:03:46 +0200 Lars Magne Ingebrigtsen <address@hidden> 
wrote: 

LMI> Tassilo Horn <address@hidden> writes:
>> When TLS support landed and Gnus used it, I frequently had messages like
>> "the Diffie-Hellman prime has been lowered to XXX bits" for XXX being
>> 256(?) or something like that.  Then I've set

LMI> The fix here is to make that warning go away.  But we're moving to a new
LMI> version of gnutls, so nobody has taken the time to twiddle with warning
LMI> from the old version of the gnutls library.

See bug#14774 for some info on the warning; I think this is a legitimate
warning.

>> Would it be possible to have a new variable
>> `gnutls-preferred-prime-bits' which is tried first for every connection?
>> If the server doesn't want to, you'd get a warning and the number of
>> bits would be lowered, but never below `gnutls-min-prime-bits' which
>> would still be the hard limit where you get an error.

LMI> gnutls will try to use as high a number of bits as the server supports,
LMI> I think?  So the variables are fine as they are -- they will give you
LMI> all the security that the server says that it can provide.

LMI> So the warning is kinda semi-bogus.  Or at least ... premature.

It's complicated and depends on the specific TLS priority string on the
client and the server's preferences; e.g. ECC seems to negotiate in a
completely different way.  I asked on the gnutls-devel mailing list and
there's just no good answer AFAICT.

Ted





reply via email to

[Prev in Thread] Current Thread [Next in Thread]