[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 <larsi@gnus.org>
wrote:
LMI> Tassilo Horn <tsdh@gnu.org> 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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#15057: 24.3.50; TLS error with reasonably high gnutls-min-prime-bits,
Ted Zlatanov <=