[gnutls-help] Reliable algorithm string

[Nikos Mavrogiannopoulos]

On Wed, Oct 14, 2015 at 2:55 AM, Ben Boeckel <mathstuf at gmail.com> wrote:
> Hi,
>
> For a couple projects (right now task[1] and eventd[2]), I'm trying to
> get them to use a protocol string to enforce better encryption (or,
> rather, disable known-bad encryption). The problem is that the string to
> control this is a really bad API stability point. If an algorithm that
> is excluded by the string is removed in GnuTLS, the whole string is
> considered invalid. For example:
>     %SERVER_PRECEDENCE:NORMAL:-VERS-SSL3.0:-VERS-TLS1.0:-3DES-CBC:-ARCFOUR-128:-ARCFOUR-40:-MD5
> will fail on newer GnuTLS versions (at least 3.4.5) because ARCFOUR
> support has (apparently?) been removed. But it needs to be there to turn
> it off on older GnuTLS versions.

Hello Ben,
 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.

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

> Is there a way to construct such a string to be compatible across a wide
> range of GnuTLS versions?

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?

regards,
Nikos