|Summary:||prefer PFS cipher suites and TLS 1.2; optionally disable SSLv3, SSLv2|
|Product:||Telepathy||Reporter:||Simon McVittie <smcv>|
|Component:||gabble||Assignee:||Telepathy bugs list <telepathy-bugs>|
|Status:||NEW ---||QA Contact:||Telepathy bugs list <telepathy-bugs>|
|Priority:||medium||CC:||guillaume.desmottes, sjoerd, vulcain, xclaesse|
|i915 platform:||i915 features:|
|Attachments:||[wocky] Use GNUTLS and OpenSSL defaults for cipher/algorithm choice|
Description Simon McVittie 2013-11-06 13:53:16 UTC
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!
Comment 1 Simon McVittie 2013-11-06 13:58:19 UTC
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.
Comment 2 Simon McVittie 2013-11-06 14:09:54 UTC
(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...
Comment 3 Simon McVittie 2013-11-06 14:15:00 UTC
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.
Comment 4 Simon McVittie 2013-11-06 14:27:57 UTC
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.