140013 2014-12-31 08:36:27 -0800 [SOUP] Disable insecure TLS version negotiation 2015-02-10 11:55:35 -0800 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) PC Linux RESOLVED WONTFIX P2 Normal --- 1 mcatanzaro mcatanzaro cgarcia danw mcatanzaro oldest_to_newest 1058248 0 mcatanzaro 2014-12-31 08:36:27 -0800 Currenly, libsoup performs insecure TLS version fallback, as do major web browsers. This is performed to preserve compatibility with broken servers. Firefox recently removed this behavior [1], so we should as well. This probably requires changes in libsoup. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1084025 1058411 1 danw 2015-01-02 06:43:19 -0800 (In reply to comment #0) > This probably requires changes in libsoup. libsoup essentially only implements this behavior for WebKitGTK/EFL's benefit, so if WebKit isn't going to use it then it might as well just be removed/disabled-by-default at the libsoup level. Note also that disabling fallback means we would no longer work with %LATEST_RECORD_VERSION-intolerant sites as well. (I guess an alternate possibility would be to have a fallback mode that is more/differently compatible, but not less secure. Eg, ensure %COMPAT and not %LATEST_RECORD_VERSION, and maybe add %NO_EXTENSIONS, but don't change the set of offered TLS versions.) 1058416 2 mcatanzaro 2015-01-02 08:08:09 -0800 (In reply to comment #1) > (In reply to comment #0) > > This probably requires changes in libsoup. > > libsoup essentially only implements this behavior for WebKitGTK/EFL's > benefit, so if WebKit isn't going to use it then it might as well just be > removed/disabled-by-default at the libsoup level. There's also value in maintaining a whitelist of broken hosts for which to perform insecure fallback. If Mozilla makes one, and if we're lucky enough to have compatibility issues with the same set of sites (ha...), then we'll want to use theirs. > Note also that disabling fallback means we would no longer work with > %LATEST_RECORD_VERSION-intolerant sites as well. (I guess an alternate > possibility would be to have a fallback mode that is more/differently > compatible, but not less secure. Eg, ensure %COMPAT and not > %LATEST_RECORD_VERSION, and maybe add %NO_EXTENSIONS, but don't change the > set of offered TLS versions.) There are so many possibilities here, the best I can say without further research (i.e. actually crawling a ton of sites) is that our goal should be to only break sites that are already broken in a major browser, and that it looks like Firefox is going to be the one to start breaking sites. 1061008 3 mcatanzaro 2015-01-13 17:25:03 -0800 We also need to chat (perhaps with Nikos) about how this will interact with the new Fedora crypto policy. My reading of the policy is that using anything except the default priority string is prohibited unless configured by the user. If that's right, it's not really flexible enough for us. 1068108 4 mcatanzaro 2015-02-10 11:55:35 -0800 Mozilla has opted to go for a whitelist, so I think we'll be stuck doing a fallback attempt forever. That's not a big deal. I do want new API so that we can display the connection as insecure if fallback (or a host of other issues that weaken the security of the connection) kicks in, but we can track that in another bug.