[gnutls-devel] [Telepathy] mcabber GnuTLS related problem

Simon McVittie simon.mcvittie at collabora.co.uk
Fri Aug 30 15:34:32 CEST 2013


On 29/08/13 20:33, Niels Ole Salscheider wrote:
>>> This is with the default priority strings:

For testing/debugging, you can set WOCKY_GNUTLS_OPTIONS="NORMAL" (or
whatever) in telepathy-gabble's environment to override these priority
strings. telepathy-gabble is an "activated" D-Bus service, so altering
its environment might involve replacing the binary with a wrapper script
that sets environment variables and execs the original binary.

>>> "NORMAL:-COMP-NULL:+COMP-DEFLATE:+COMP-NULL"
...
>> In general there is no reason to use compression with TLS. It
>> can only cause harm (including reveal of plaintext).

XMPP is a fairly verbose protocol (XML, with namespaces used for
extensibility). I'm led to believe that XMPP + deflate is much more
bandwidth-efficient.

If the GNUTLS team's considered opinion is "using deflate is now too
dangerous, and the bandwidth reduction isn't worth it" then we can get
rid of that bit, and point anyone who complains to that explanation.

What priority string would the GNUTLS team recommend for XMPP traffic?
(If the answer is "don't call gnutls_priority_set_direct() by default at
all", that'll be a little more code, but we can do that.)

Do you consider calling gnutls_priority_set_direct() to be a bad idea in
general?

>>> "NONE:+VERS-TLS-ALL:+SIGN-ALL:+MAC-ALL:+CTYPE-ALL:+RSA:+COMP-DEFLATE:+COMP
>>> -
>>> NULL:+ARCFOUR-128:+ARCFOUR-40:+AES-128-CBC:+AES-256-CBC:+3DES-CBC:+DES-CBC
>>> :
>>> +RC2-40:+CAMELLIA-256-CBC:+CAMELLIA-128-CBC"
>>
>> That is a pretty dangerous priority string. While modern versions of gnutls
>> would not negotiate DES, RC4-40 or RC2, having them in the priority string
>> reveals something fishy.

That's not the normal configuration. It's intended to be enabled in
bandwidth-constrained environments by ./configure
--enable-prefer-stream-ciphers, documented as "prefer stream ciphers
over block ciphers to save bandwidth (at the possible expense of
security". I believe it may have been implemented for OLPC, in which
they initially deployed clear-text XMPP, then switched on TLS solely for
the bandwidth-reduction of getting compression as a side-effect (their
experimental mesh networking didn't cope well with uncompressed XMPP).

I believe the trailing cipher configurations were copied from the cipher
specs used by then-current GNUTLS, but I could be wrong.

If the GNUTLS team consider this to be dangerous, we could delete that
option altogether, and tell anyone who really wants it to set
$WOCKY_GNUTLS_OPTIONS at their own risk...

    S




More information about the Gnutls-devel mailing list