[gnutls-help] Reliable algorithm string

Ben Boeckel mathstuf at gmail.com
Thu Oct 15 19:39:17 CEST 2015


On Thu, Oct 15, 2015 at 17:49:41 +0200, Nikos Mavrogiannopoulos wrote:
> On Thu, Oct 15, 2015 at 2:09 PM, Ben Boeckel <mathstuf at gmail.com> wrote:
> > First of all, I'm interested in the server-side of things more than the
> > client side. Clients should usually be set up for compatibility since
> > it's a zoo out there. Specialized applications should probably set up
> > higher barriers to use. So my goal is to ensure applications can match
> > the Intermediate profile here (best would be Modern, but I've found that
> > GnuTLS doesn't accept specific enough exclusions to exclude an
> > Intermediate algorithm or two and still have Modern with more than 2 or
> > 3 algorithms):
> 
> I am not sure I follow, could you give an example?

For example, I run a taskwarrior sync server which uses client certs and
such to secure the connection; there is no need to support any old
algorithms to include support for systems too much older than the first
release of the sync server.

> That is more likely to be an issue in the tool that checks
> capabilities . GnuTLS never negotiated export ciphers by default. They
> had to be enabled separately even at first release that supported
> them, and were removed in 2013.

Hmm. Maybe I had removed them before trying the rest; it's been 9 months
or so.

> Correct. My argumentation would be, to have it so that the server
> prefers the ciphers it has optimized hardware for (e.g., AESNI).

Sure; I prefer security, but I also run my own hardware which doesn't
have to deal with an absurd number of connections per second as well.

> It wouldn't. Your settings were carefully written.

My settings are synced across a range of devices of varying software
ages (Fedora 21 up to Rawhide). Maintaining patches on top of the base
is possible, but not the most fun thing to do :) .

> Indeed, but a config file or a command line argument doesn't require a
> software release to be fixed.

True.

> Or maybe it is easier to simply ignore algorithms that existed in the
> past. That's a bit cleaner and allows backwards compatibility.

This would be good as well :) .

> > Actually, even whle replying, it occurred to be that it would be even
> > better if GnuTLS could provide MOZILLA_OLD, MOZILLA_INTERMEDIATE, and
> > MOZILLA_MODERN profiles (to replace NORMAL). Then applications wouldn't
> > need to maintain an exclusion list with a bunch of algorithms anyways.
> 
> That's not a bad idea to have. Feel free to open an issue at the issue
> tracker for that.

Will do.

> I am a bit sceptical of it though, because it will
> introduce quite some maintenance burden both for gnutls and
> applications. Also I don't know whether mozilla will keep up with
> these settings. Gnutls' default settings used to be much better than
> the ones used by mozilla browser for quite long time, and it may be
> better to catch up on the normal level rather than introduce new
> strings.

The page is updated rarely. I expect one for the SHA stuff in the not
too distant future, but since the general strategy is to remove old
algorithms, any new algorithms shouldn't be excluded accidentally.

--Ben



More information about the Gnutls-help mailing list