[Top][All Lists]

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

Re: Tuning GnuTLS

From: Ted Zlatanov
Subject: Re: Tuning GnuTLS
Date: Wed, 28 Sep 2011 12:32:56 -0500
User-agent: Gnus/5.110018 (No Gnus v0.18) Emacs/24.0.90 (gnu/linux)

On Mon, 18 Jul 2011 05:23:16 +0200 Lars Magne Ingebrigtsen <address@hidden> 

LMI> We should strive to make TLS connections as painless as possible, and
LMI> involving as little user intervention as possible, while preserving a
LMI> reasonable level of security.

LMI> So far, two failure points have been identified:

LMI> 1) Some servers sends a prime with fewer bits than the accepted default.
LMI> I think the right thing to do here is to just default
LMI> `gnutls-min-prime-bits' to a lower number than the default GnuTLS
LMI> number.  I don't know what that number should be, but I think people who
LMI> want better bits than that can adjust this number upwards.

LMI> 2) Servers presenting broken, er, certificates with certain algorithms.
LMI> If negotiation with DHE-RSA has failed, then negotiation without that
LMI> algorithm should be attempted.  But is it possible to fall back to
LMI> plain-text?  I don't really know how that works.  But if that's
LMI> possible, the fall-back should obviously stop before it gets that far.

LMI> After a priority has been established, I then think that the priority
LMI> for this specific server/port pair should be saved via Customize, so
LMI> that the next connection can be done faster automatically, without the
LMI> need for all this negotiation.

Could you ask on the GnuTLS dev list?  Both of these are possible AFAICT
but perhaps they have suggestions for the implementation specifics.


reply via email to

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