[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.


> 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.


More information about the Gnutls-help mailing list