[gnutls-help] Reliable algorithm string

[Ben Boeckel]

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):

    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.

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.

> 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)?

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

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

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.

--Ben