Bug 140014 – [SOUP] Disable RC4

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Michael Catanzaro]

It's past time to disable all ciphersuites that use RC4, which is no longer considered secure [1]. Instead, we should refuse to connect if the server only supports RC4.

This can be expected to break ~1.5% of the top 1,000,000 web sites [2], so we should only push this change once a major browser does so first [3] [4].

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-prohibiting-rc4/
[2] https://jve.linuxwall.info/blog/index.php?post/TLS_Survey
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=999544
[4] https://code.google.com/p/chromium/issues/detail?id=375342

[Michael Catanzaro]

Created attachment 243843 [details]
Patch

[Michael Catanzaro]

Comment on attachment 243843 [details]
Patch

Not sure how this worked, since I failed to change the priority string in the network process. (But I'm pretty sure I had the network process enabled when I tested it. Hm....)

[Dan Winship]

Comment on attachment 243843 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=243843&action=review

> Source/WebKit2/ChangeLog:8
> +        Disallow the RC4 ciphersuite when performing TLS negotiation, because it

"Disallow RC4-based ciphersuites".

[Michael Catanzaro]

(In reply to comment #2)
> (But I'm pretty sure I had the network process enabled
> when I tested it. Hm....)

I must have been wrong.

(In reply to comment #3)
> "Disallow RC4-based ciphersuites".

Thanks.

(In reply to comment #0)
> This can be expected to break ~1.5% of the top 1,000,000 web sites [2], so
> we should only push this change once a major browser does so first [3] [4].

I'm inclined to go ahead and push this to master now anyway, and never change it in 2.6.x. [1] lists some sites to check, including three that are broken after the proposed Firefox change. This change in WebKit breaks one of those three; the other two we already cannot display.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1114809

[Michael Catanzaro]

Created attachment 243997 [details]
Patch

[Michael Catanzaro]

Actually actually, this got disabled in gnutls master recently, coincidentally the same day I filed this bug. So let's not do anything.

[Michael Catanzaro]

GnuTLS is moving too slow and RFC 7465 has been proposed [1] so I want to move forward with this anyway. Carlos, can you commit this to 2.8 and master please? Not 2.6.

[1] http://www.rfc-editor.org/rfc/rfc7465.txt

[Carlos Garcia Campos]

(In reply to comment #7)
> GnuTLS is moving too slow and RFC 7465 has been proposed [1] so I want to
> move forward with this anyway. Carlos, can you commit this to 2.8 and master
> please? Not 2.6.
> 
> [1] http://www.rfc-editor.org/rfc/rfc7465.txt

Why not 2.6?

[Michael Catanzaro]

Because it will break sites that only offer RC4 (there's a "fun" discussion on this in the Firefox and Chrome bugs in the first post), so I prefer to delay it to the next major release, so that nobody has any reason not to upgrade from 2.6.x to 2.6.y, and servers has a little extra time to adjust. Besides, it will likely take at least a month (if we're lucky) for other browsers to follow along.

Now, there is a talk about RC4 at Black Hat Asia, which is one day after the GNOME 3.16 release, which will present a new attack on RC4 that may be bad enough to necessitate a backport regardless. It's an iffy call whether to backport or not; I don't really mind either way as long as it's fixed going forward.

[Michael Catanzaro]

FWIW Firefox is dropping RC4 for FF38 (to be released in late May) but they've added 650 sites that only offer RC4 to a whitelist (to be removed in the "near future" but who knows what that means). I think we can just break those sites; I expect when we dropped SSLv3 and accidentally stopped doing protocol version fallback we broke many more than that. If we want to do something like a whitelist we'd need to talk about new API in glib and libsoup (which would be nice to have regardless).

See:

https://developer.mozilla.org/en-US/Firefox/Releases/38/Site_Compatibility
http://mxr.mozilla.org/mozilla-aurora/source/security/manager/ssl/src/IntolerantFallbackList.inc

[Michael Catanzaro]

Actually that is a link to their voluntary protocol version fallback whitelist. Either their release notes have the wrong link, or they haven't added any RC4 sites to the whitelist yet.

[Carlos Garcia Campos]

I'm lost with all this, TBH. Dan, Sergio, Martin, Gustavo?

[Michael Catanzaro]

(In reply to comment #12)
> I'm lost with all this, TBH.

The issue is that an attacker can view the first 256 bytes of your connection (i.e. he has your session cookie -> he is you -> game over) using significant but practical computing power. And very many sites will always pick RC4 first even if the browser lists it as the lowest preference, because it is very fast (and they don't support newer fast algorithms like AES GCM mode), so we must stop offering it completely to avoid that. But a few servers still only support RC4 due to misconfiguration. And there is no way to fix this issue for most sites but not those "broken" sites: what Firefox was doing prior to this week was offering RC4 only in their fallback handshake, but that provides zero additional security against an active attacker since he will just block the initial handshake. (We could do that too to improve security against a *passive* attacker, but the real "benefit" of doing that would be to trick users into thinking the browser is secure on online TLS tests, so I don't support that. And the analogy is not perfect because Firefox actually does multiple fallback handshakes where as we do only one, but that doesn't matter.)

So it's the wonderful choice of security vs. compatibility. We will have to make this choice many more times in the future. My preference is normally to err towards compatibility when all our competing browsers are just as insecure as we are, but in this case I'm not sure that's advisable. There is also a fairly good chance that if we don't fix it now we will be in a scramble to fix it three weeks from today, due to the Black Hat talk I mentioned above, but we can always wait and see!

Note also that RC4 is disabled in GnuTLS 3.4, so the choice will soon be made for us unless we explicitly turn it on with the priority string, but it'll take a year or so for that to make its way into most distros.

[Michael Catanzaro]

Note that https://bugzilla.gnome.org/show_bug.cgi?id=745637 would give us the power to implement a whitelist. I don't really want to do that, but it might be the best point on the security/compatibility compromise range.

[WebKit Commit Bot]

Comment on attachment 243997 [details]
Patch

Clearing flags on attachment: 243997

Committed r181073: <http://trac.webkit.org/changeset/181073>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.