WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WONTFIX
Bug 140013
[SOUP] Disable insecure TLS version negotiation
https://bugs.webkit.org/show_bug.cgi?id=140013
Summary
[SOUP] Disable insecure TLS version negotiation
Michael Catanzaro
Reported
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
Attachments
Add attachment
proposed patch, testcase, etc.
Dan Winship
Comment 1
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.)
Michael Catanzaro
Comment 2
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.
Michael Catanzaro
Comment 3
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.
Michael Catanzaro
Comment 4
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.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug