[SOUP] Disable insecure TLS version negotiation

• Component: WebKit2
• Status: RESOLVED WONTFIX

[Michael Catanzaro]

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

[Dan Winship]

(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.)

[Michael Catanzaro]

(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.

[Michael Catanzaro]

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.

[Michael Catanzaro]

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.