On Wed, Oct 14, 2015 at 2:55 AM, Ben Boeckel <[email protected]> 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 _______________________________________________ Gnutls-help mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnutls-help
