I got permission from the authors to share this paper with security-group. The work has also been publicly disclosed: https://news.ycombinator.com/item?id=5364807 http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html ----- Forwarded Message ----- From: "Kenny Paterson" <Kenny.Paterson@rhul.ac.uk> To: "Brian Smith" <bsmith@mozilla.com> Cc: "D. J. Bernstein" <djb@cr.yp.to>, "Jacob Schuldt" <Jacob.Schuldt@rhul.ac.uk>, "Bertram Poettering" <Bertram.Poettering@rhul.ac.uk>, "Nadhem Alfardan (2009)" <Nadhem.Alfardan.2009@live.rhul.ac.uk>, gerv@mozilla.com, "Kenny Paterson" <Kenny.Paterson@rhul.ac.uk> Sent: Tuesday, March 12, 2013 4:03:15 PM Subject: Re: Security of RC4 in TLS Hi Brian, Thanks for getting back to us and for the positive feedback on the paper. Given very recent events, I think you may as well share the paper with your Mozilla security group. The ideas are very much now in the public domain, and anyone who has a good understanding of crypto can pretty much reverse-engineer everything from what's already out there. As you say, you can't just switch off RC4 in Firefox right away. Something like 3%-5% of websites ONLY accept RC4 ciphersuites, for example. The medium-term solution is for everyone to switch to TLS 1.2 and its AEAD ciphersuites (AES-GCM for example). In the very short term, there's various hacks you can get your browser to do if the server insists on using RC4 - adding random numbers of bytes to initial requests; fragmenting the first GET request into single byte TLS messages so that the "weak" RC4 bytes are mostly consumed in encrypting the MAC field; etc. However, this is a solution that at best is going to last a few weeks, as we expect the attacks to get better and eventually to be able to recover plaintext from anywhere in the session. Then you would need to start doing things like limiting the number of times any cookie can be sent before it is expired. Happy to discuss all of this more with you and the Mozilla team.

At https://news.ycombinator.com/item?id=5365601, Adam Langley wrote: > CBC at the moment I think. There's still the possibility of clients > without record splitting, there's timing issues in AES itself, there's > lots of possibilities for bad server padding implementations. > > I have TLS 1.2 and AES-GCM working in NSS on my desktop, but we > don't currently have the NSS reviewer time to get it landed. We also > have to deal with the issue that an active attacker can trigger a > version downgrade somehow. (I don't love AES-GCM either, but it's > the nearest port in this storm.) > > In the mean time, I'll probably tweak RC4 in NSS to send one byte > records at the beginning of the connection and thus burn off the > first 256 bytes of keystream by encrypting MACs. That still leaves > a handful of bytes vulnerable, but half of them will be "GET ". > > But I doubt that's fully sufficient so AES-GCM is the medium term > goal.

As noted in HN, doing 1/1/1/.../n-11 record splitting at the start of the TLS connection will burn off the first 256 keystream bytes. The compat issues are likely to be similar to 1/n-1 record splitting, which isn't perfect, but hopefully 1/n-1 record splitting caused much of it to be cleaned up. However, the first 256 bytes are only part of the story. AES-GCM is the most obvious solution, but we also need to fix the downgrade issue. I don't believe that a SCSV to prevent downgrades is viable because our metics suggest 0.1% of connections from Chrome to Google are getting downgraded - likely by broken middleware. Just using the GCM ciphersuite values down into SSLv3 might work. Extra points if we can make it mean ECDHE with P-256 in SSLv3 where the ECC extensions have been removed.

(In reply to Adam Langley from comment #2) > As noted in HN, doing 1/1/1/.../n-11 record splitting at the start of the > TLS connection will burn off the first 256 keystream bytes. The compat > issues are likely to be similar to 1/n-1 record splitting, which isn't > perfect, but hopefully 1/n-1 record splitting caused much of it to be > cleaned up. That sounds plausible but also I can see compatibility being a real concern. The difference between this and BEAST is that this attack, as far as we know, works best (only) at the very start of the encrypted stream. That may leave the door open to mitigations at the application layer that were considered too unreliable for BEAST. This attack seems to require a lot of carefully-constructed requests. From this, can we assume that the attacker already knows the target URL? For SPDY, is there a place where we can just stuff ~220 bytes of non-secret junk that the other side can effectively ignore before we start sending anything useful? (Both, from the server and from the client.) If not, we should consider requiring non-RC4 cipher suites for SPDY. The pain of doing that would be very temporary, compared to the HTTP-over-TLS case, as SPDY users are early adopters and have had to jump through significant hoops to use SPDY in the first place. In a HTTP-over-TLS server (not SPDY), there is a certain amount of metadata in each request that is fixed. For example, here is a request from Firefox Nightly: GET / HTTP/1.1 Host: a User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130312 Firefox/22.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://www.drudgereport.com/ Connection: keep-alive That is already over 300 bytes, and that's not including the 32 bytes from the TLS Finished message. So, in Gecko, if we feel confident that the attacker already knows the request URI and the request host, it is possible that we could simply ensure that all secret text (HTTP auth, cookies, any request body bytes, and any application-set headers) occur at the end of the header block. And/or, we could pad the header block with random data in an extra header as necessary, like this: GET / HTTP/1.1 Host: a P: 2r3--#Q)(#)(*JF6&rg45G$$g2.... (as long as necessary) User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20130312 Firefox/22.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: http://www.drudgereport.com/ Connection: keep-alive Note that I assume that some sick, horrible servers will break if the Host header isn't the first header. But, if we don't want to make that assumption then we could put the random padding header before the host header. However, even with such application-specific hacks in place, it would still be good to have a general-purpose, on-by-default, mitigation like the 1/1/1/... splitting in NSS for applications that do not go through this extraordinary effort. > However, the first 256 bytes are only part of the story. I agree. > AES-GCM is the most > obvious solution, but we also need to fix the downgrade issue. I don't > believe that a SCSV to prevent downgrades is viable because our metics > suggest 0.1% of connections from Chrome to Google are getting downgraded - > likely by broken middleware. Just using the GCM ciphersuite values down into > SSLv3 might work. Extra points if we can make it mean ECDHE with P-256 in > SSLv3 where the ECC extensions have been removed. First of all, didn't Google remove the ECC support for SSLv3 (i.e. making NSS require TLS 1.0 for ECC) for some other reason very recently? What was the reason? Secondly, from the server's perspective the worry of downgrade is much worse than from the browser's side, right? Because, most of the known attacks that make servers worry about CBC mode are avoided as long as the client implements reasonable defenses, right? And, we do. That said, this insecure downgrade issue is old and tired by now. Maybe it is our (browser makers') responsibility to help rip off this band-aid and stop pandering to the intolerant servers in the first place. Still, this seems like a distinctly separate issue to me.

(In reply to Brian Smith (:bsmith) from comment #3) > > First of all, didn't Google remove the ECC support for SSLv3 (i.e. making > NSS require TLS 1.0 for ECC) for some other reason very recently? What was > the reason? I removed the ECC support for SSLv3 only for the NSS_ECC_MORE_THAN_SUITE_B=1 build. In the "not more than Suite B" ECC build, ECC is already disabled for SSLv3. The reason is that without TLS extensions, we cannot specify which curves are supported. Although the NSS_ECC_MORE_THAN_SUITE_B=1 supports all the curves specified for TLS/SSL today, that assumption won't hold as soon as a new curve is specified for TLS/SSL. This is why I eliminated that difference between the NSS_ECC_MORE_THAN_SUITE_B=1 build and the "not more than Suite B" ECC build.

(In reply to Wan-Teh Chang from comment #4) > (In reply to Brian Smith (:bsmith) from comment #3) > > First of all, didn't Google remove the ECC support for SSLv3 (i.e. making > > NSS require TLS 1.0 for ECC) for some other reason very recently? What was > > the reason? > > I removed the ECC support for SSLv3 only for the NSS_ECC_MORE_THAN_SUITE_B=1 > build. In the "not more than Suite B" ECC build, ECC is already disabled > for SSLv3. The reason is that without TLS extensions, we cannot specify > which curves are supported. Thanks for the clarification Wan-Teh. Also, thinking more about this, I see why the version downgrade issue is now more related to this than I previously thought. First, there is some confusion/disagreement about whether AES-based cipher suites are allowed in SSLv3 at all. Secondly, I imagine that it will eventually become prudent to first try an TLS handshake without any RC4 cipher suites enabled, and then try again if that handshake fails. I guess it is *this* potential for cipher suite downgrade, not version downgrade, that Adam was referring to in his comments about avoiding the downgrade issue.

(In reply to Brian Smith (:bsmith) from comment #5) > I imagine that it will eventually become prudent to > first try an TLS handshake without any RC4 cipher suites enabled, and then > try again if that handshake fails. I guess it is *this* potential for cipher > suite downgrade, not version downgrade, that Adam was referring to in his > comments about avoiding the downgrade issue. In that case we could have a hardcoded list of the most important hosts (like google, paypal) that support TLS_AES (or any other suite different from RC4). Determination can be automated as HSTS preload list has been.

(In reply to Honza Bambas (:mayhemer) from comment #6) > In that case we could have a hardcoded list of the most important hosts > (like google, paypal) that support TLS_AES (or any other suite different > from RC4). Determination can be automated as HSTS preload list has been. Keep in mind that this is an NSS bug, not a Gecko/Firefox bug. But, yes, a product could do something like that. Ideally, though, we could offer users of NSS's libssl some guidelines that help them avoid the downgrade issue, if we cannot find a solution to it within NSS.

(In reply to Adam Langley from comment #2) > As noted in HN, doing 1/1/1/.../n-11 record splitting at the start of the > TLS connection will burn off the first 256 keystream bytes. I wrote a proof of concept for Adam's idea at https://codereview.chromium.org/12417005/ . Please take a look. I enhanced Brian's 1/n-1 record splitting code to be able to split the application data into any number of 1/1/1/.../n-k records. Currently k=15 (numRecords=16). I repurpose the existing ss->opt.cbcRandomIV option to also control record splitting for RC4 cipher suites. I will rename the option "enableRecordSplitting". If record splitting becomes a common workaround, we should improve ssl_SecureRecv() to return all the received records at once, rather than one record at a time. I remeber I wrote a patch to do that while testing Brian's 1/n-1 record splitting patch, but I can't find that patch.

Here's another paper (or at least part of it) that was just released. http://home.hiroshima-u.ac.jp/ohigashi/rc4/

I dont really see the purpose of fixing the RC4 implementation here. Rejecting the first 256 bytes is not going to solve any problem. You can re-cover > 258 bytes using 2^34 ciphertexts. So its just a question of time, until better methods are found.

Lowering the priority of RC4_128 cipher suites in our ClientHello won't make a difference to servers that support any 256-bit cipher suite or servers that ignore the cipher suite order in ClientHello. So this patch is more of a symbolic action to show we are concerned about the security of RC4 cipher suites. In this patch I only made the most conservative change, still listing RC4_128 cipher suites in the original 128-bit groups. An alternative would be to form a new group of all the RC4_128 cipher suites and list that group after all the other 128-bit groups.

This is the patch I described in comment 8.

Now that Mozilla is going to WONTFIX this, any chance of making this bug public?

(In reply to Huzaifa Sidhpurwala from comment #13) > Now that Mozilla is going to WONTFIX this, any chance of making this bug > public? Is the paper public yet?

Not the paper, but a lot of discussion related to it is: http://www.isg.rhul.ac.uk/tls/ http://blog.cryptographyengineering.com/2013/03/attack-of-week-rc4-is-kind-of-broken-in.html http://cr.yp.to/talks/2013.03.12/slides.pdf http://nakedsecurity.sophos.com/2013/03/16/has-https-finally-been-cracked/ http://www.theregister.co.uk/2013/03/15/tls_broken/ https://bugzilla.redhat.com/show_bug.cgi?id=921947 http://marc.info/?t=136333793200001&r=1&w=2

(In reply to Huzaifa Sidhpurwala from comment #13) > Now that Mozilla is going to WONTFIX this, any chance of making this bug > public? Yours is the first mention of "wontfix" in a bug that has gained two patches in the past few days.

I am fine with opening this bug up. My comments in security-group were a little over-simplified and mostly to set expectations based on conversation in last week's NSS meeting. It isn't that we're not going to do anything (WONTFIX), its that we're not planning to provide a generic "NSS fixes it automatically" solution in the same way that we did for other recent issues.

I don't believe that we are allowed to publish Kenny's draft paper yet - at least not without asking first.

(In reply to Adam Langley from comment #18) > I don't believe that we are allowed to publish Kenny's draft paper yet - at > least not without asking first. Prior to making my comment, I set the paper's attachment flags to "private" so that it won't be public even if the bug is.

Brian should we remove the patch review requests to reflect that a different approach will be taken?

Comment on attachment 727779 [details] [diff] [review] List RC4_128 cipher suites after AES_128 cipher suites r+ rrelyea

Looks like the paper was released today (http://www.isg.rhul.ac.uk/tls/). Some discussion at https://news.ycombinator.com/item?id=6008486. Mozilla is notably absent from http://www.isg.rhul.ac.uk/tls/#Patches.

The implementation of AES-GCM and TLS 1.2 (as noted in the Google Chrome) patches are being done through NSS, and thus (largely) apply to Firefox as well, mod PSM/netwerk layer. Chrome has not yet enabled AES-GCM, so the progress is not substantial over Firefox.

(In reply to Ryan Sleevi from comment #23) > The implementation of AES-GCM and TLS 1.2 (as noted in the Google Chrome) > patches are being done through NSS, and thus (largely) apply to Firefox as > well, mod PSM/netwerk layer. > > Chrome has not yet enabled AES-GCM, so the progress is not substantial over > Firefox. We should let them know that what out plans our i think, so that its updated on their page.

I updated the patch to the current NSS trunk and checked it in. https://hg.mozilla.org/projects/nss/rev/9f313e08bd43

Closed the bug. Not sure if the resolution should be "FIXED" or "WONTFIX". We have implemented TLS 1.2 and AES-GCM cipher suites, and dropped the priority of RC4 cipher suites relative to AES cipher suites. But we didn't come up with any effective countermeasure for RC4 cipher suites.

FxOS will need to pull in the updated NSS to fix this issue.

:bajaj Given that this has both the core and crypto flags set, I wanted to make sure you team was able to see this.

Comment on attachment 727989 [details] [diff] [review] Split RC4-encrypted records. Ultimately we decided not to do this record splitting, so canceling review request.

Can someone tell me if there is a reason why this issue, fixed in NSS 3.15.3, doesn't have a CVE assigned? I'm writing an advisory for the NSS update in the current release and want to reference bugs/CVEs that we addressed with the NSS update.

The vulnerability described here is known as CVE-2013-2566 (see link in comment 22). Reordering the cipher suites is more of a mitigation than a fix but I guess we can use that reference as a handle.

This is fixed by bug 935959 on most affected branches, right?

I believe so. Not on ESR-17 though (now EOL)

Matt, is this something that needs verification? Looks like it went out in two releases now without testing.

Anthony: no. Marking [qa-].