Bug 140013 - [SOUP] Disable insecure TLS version negotiation
Summary: [SOUP] Disable insecure TLS version negotiation
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Michael Catanzaro
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-31 08:36 PST by Michael Catanzaro
Modified: 2015-02-10 11:55 PST (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Catanzaro 2014-12-31 08:36:27 PST
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
Comment 1 Dan Winship 2015-01-02 06:43:19 PST
(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.)
Comment 2 Michael Catanzaro 2015-01-02 08:08:09 PST
(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.
Comment 3 Michael Catanzaro 2015-01-13 17:25:03 PST
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.
Comment 4 Michael Catanzaro 2015-02-10 11:55:35 PST
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.