o prefer the latest version of TLS (TLS 1.2)
o disable support for the older and less secure SSL standard
(SSLv2 and SSLv3)
o provide configuration options to require channel encryption for
client-to-server and server-to-server connections
o provide configuration options to prefer or require cipher
suites that enable forward secrecy
We should do that.
For interop with defective corporate XMPP servers, we should probably offer a boolean allow-ssl3 parameter, and perhaps a allow-ssl2 parameter too. They can be off by default, hopefully.
I hope we won't need an allow-tls1.2 parameter (on by default) for interop with servers that choke on that... but perhaps we will.
We'll eventually need allow-tls1.1 and allow-tls1.0 parameters, probably. While we're adding things we might as well complete the set!
Relatedly: Nikos Mavrogiannopoulos at GNUTLS thinks our GNUTLS preference string is suspicious in general:
> I'd suggest to use the uncompressed protocol by default
> and allowing an option for the user to enable TLS compression
> (in the case benefits outweigh the risks).
> I'd suggest to use the default "NORMAL" or "NORMAL:%COMPAT"
> option, and allow alternatives by user options. The normal
> priority string will always contain conservative security
> options suitable for generic usage (and will be updated as
> security threats change). By using a custom priority string
> you take the responsibility of such updates.
(In reply to comment #0)
> o prefer the latest version of TLS (TLS 1.2)
GNUTLS' "NORMAL" configuration does that, according to the documentation.
It's not clear to me how much NORMAL hurts interop vs. NORMAL:%COMPAT.
> o disable support for the older and less secure SSL standard
> (SSLv2 and SSLv3)
GNUTLS' "NORMAL" configuration disables SSLv2 but not SSLv3.
If we want to disable SSLv3, we'd use NORMAL:%LATEST_RECORD_VERSION:-VERS-SSL3.0 or something like that.
> o provide configuration options to prefer or require cipher
> suites that enable forward secrecy
GNUTLS' "NORMAL" configuration prefers PFS, according to the documentation.
Disabling non-PFS altogether doesn't seem to be possible, at least in gnutls26 as shipped in Debian: there's no KX-ALL. We could say
(i.e. disable all current key exchange mechanisms except DHE-*) but then if a new non-PFS algorithm is added, we still lose...
In GNUTLS 3, you can say "PFS" instead of "NORMAL" to require PFS, but we'd have to check whether Bgu #45275 is a fixed GNUTLS bug, or still extant as a Wocky or GNUTLS bug.
Created attachment 88756 [details] [review]
[wocky] Use GNUTLS and OpenSSL defaults for cipher/algorithm choice
We're not TLS experts, so we shouldn't be second-guessing the
libraries. In particular, RC4 and TLS stream compression seem to
be rather discredited, and the ENABLE_PREFER_STREAM_CIPHERS
option seems like a potential recipe for disaster.
If a distributor wants to alter the cipher preferences, they can
either patch their OpenSSL/GNUTLS library, patch their Wocky
library, or propose a patch to add configure options that set
the DEFAULT_TLS_OPTIONS or cipher list directly.
Here's a starting point for this: leave the configuration up to the experts.
(In reply to comment #4)
> [wocky] Use GNUTLS and OpenSSL defaults for cipher/algorithm choice
Any thoughts about this? It doesn't close this bug, but seems like a step forward.
-- GitLab Migration Automatic Message --
This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-gabble/issues/269.