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.