https://github.com/stpeter/manifesto/blob/master/manifesto.txt says: 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: http://lists.gnutls.org/pipermail/gnutls-devel/2013-August/006440.html http://lists.gnutls.org/pipermail/gnutls-devel/2013-August/006437.html and writes: > 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 NORMAL:-RSA:-SRP:-SRP-RSA:-SRP-DSS:-PSK:-ANON-DH:-RSA-EXPORT (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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.