[gnutls-help] Reliable algorithm string

[Nikos Mavrogiannopoulos]

On Thu, Oct 15, 2015 at 2:09 PM, Ben Boeckel <mathstuf at gmail.com> wrote:
> On Thu, Oct 15, 2015 at 13:34:12 +0200, Nikos Mavrogiannopoulos wrote:
>>  That's a correct observation in general, but to the point, I think it
>> is better to go with the defaults. In that particular example you are
>> referring to ARCFOUR-40, but this was never enabled by default in the
>> normal level. Thus there is no need to remove it.
> 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?

>     https://wiki.mozilla.org/Security/Server_Side_TLS
> This is as close as I've been able to come. As for the removals, I only
> added them if they caused issues with Intermediate as determined by:


>
>     https://github.com/jvehent/cipherscan
> so whatever version my server was running had ARCFOUR-40 somewhere which
> needed to be excluded; it may have been an old GnuTLS or had a bug; it's
> a FreeBSD 9 machine with GnuTLS from ports.

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.

> At a *minimum* %SERVER_PRECEDENCE should really be set for servers;
> there's no reason that when GnuTLS gets upgraded to prefer better
> algorithms, clients can just force it to back down again.

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

>> The fact is that all the applications that decide to set some
>> "reasonable" defaults and not rely on gnutls', end up not working, or
>> providing insecure defaults after several years, because they don't
>> actively maintain those defaults. For example an application that set
> In my cases, all I'd ever be doing is removing algorithms, so how would
> the sercurity degrade over time (assuming GnuTLS is suitably upgraded
> over that time)?

It wouldn't. Your settings were carefully written.

>> defaults in 2009 and never touched them again now cannot talk to most
>> servers because it was explicitly enabling RC4 (due to some attack on
>> cbc at the time), and only enabling SSL 3.0 and TLS 1.0. So my
>> recommendation is to use gnutls_set_default_priorities() and let the
>> version of gnutls you have pick the best, and possibly allow the user
>> to override the defaults by reading some custom string via command
>> line of config file.
> Well, even if the application can't set defaults and it should be the
> user, now *I* can't set defaults reliably because of underlying version
> changes; the ball just gets moved around with this policy.

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

>> This is tricky to do in a straightforward way. If I disable failure
>> when an unknown algorithm is disabled, I introduce the risk to not
>> disable an algorithm due to a typo (e.g, "NORMAL:-EAS-128-CBC"). If
>> despite my recommendation you'd like to pursue custom settings, what
>> could be done without introducing new API is the following. Postpone
>> failure for parsing error when disabling an unknown algorithm, set
>> everything that can be set with the given priority string and fail at
>> the function exit. That way the caller could ignore parsing errors if
>> needed. What do you think?
> That would be suitable I think. Certainly better than falling back to
> the default profile.

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

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

regards,
Nikos