Closed Bug 1029179 Opened 10 years ago Closed 9 years ago

Add TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: hkario, Unassigned)

References

Details

Attachments

(2 files, 1 obsolete file)

MozReview Request: Bug 1029179 - Add TLS_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers r?ekr r?keeler
58 bytes, text/x-review-board-request
ekr
: review+
Details
Make nonEC-AESGCM cipher suites fallback-only
14.45 KB, patch
Details | Diff | Splinter Review
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 (Beta/Release) Build ID: 20140611075517 Steps to reproduce: If I disable RC4 ciphers in Firefox, I'm unable to watch videos on YouTube any more. Many website owners still configure their servers to use RC4 above any other ciphers, even if their servers support TLS1.1 and later. This results in negotiating insecure cipher suite when a more secure option is possible. Because of that I want to disable RC4 ciphers. Unfortunately, the side effect is that videos on youtube stop workig. Actual results: YouTube servers support only two ciphers: https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-uxaxovg-5goz.googlevideo.com TLS_RSA_WITH_RC4_128_SHA (0x5) TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c) The first one is insecure, the second one is unsupported by Firefox (but not by NSS). Disabling the insecure cipher in Firefox (security.ssl3.rsa_rc4_128_sha) makes the videos fail to load. Expected results: Firefox should at least allow the option to manually enable the TLS_RSA_WITH_AES_128_GCM_SHA256 cipher suite. Or enable it by default.
According to bug 880543 NSS 3.15.2 supports TLS_RSA_WITH_AES_128_GCM_SHA256. Though it might not be enabled on the Gecko side (see similar bug 916226).
Component: Untriaged → Security: PSM
OS: Linux → All
Product: Firefox → Core
Hardware: x86_64 → All
Patch that adds the UI to enable uncommon AES-GCM and SHA256 ciphers. Doesn't change the ciphers offered by default. The new ciphers are added on positions that should be most consistent with logic in https://briansmith.org/browser-ciphersuites-01.html Allows to watch videos on secure youtube with RC4 disabled, as well as visiting the https://www.cs.auckland.ac.nz/~pgut001/ page.
Attachment #8447631 - Flags: review?(brian)
Thanks for the bug report and thanks for the patch. We had a very long public discussion about which cipher suites to support in Firefox. See https://groups.google.com/forum/#!topic/mozilla.dev.tech.crypto/gFfKw3EOffo and other threads on that mailing list. The pros/cons of adding the RSA-AES-GCM and non-ECC DHE-RSA-AES-GCM cipher suites were discussed at length. Mozilla has been working on deprecating RSA key exchange in various ways. In the IETF, we've successfully lobbied for RSA cipher suites to be removed from the TLS 1.3 draft, for example. Also, partially by refusing to implement the non-ECDHE RSA-AES-GCM cipher suites, we've persuaded multiple server software and server hardware makers to implement (and/or accelerate their implementation, and/or backport) the ECDHE-RSA-AES-GCM cipher suites. Therefore, I still think the long-term positive effects of us refusing to implement any more RSA key exchange cipher suites outweigh the temporary benefits of implementing the RSA-AES-GCM cipher suites. All the same applies to the HMAC-SHA256-based cipher suites. The HMAC-SHA256 cipher suites have a very poor performance:security tradeoff. Also, AFAICT there is no reason to be concerned about the security of HMAC-SHA1 in the way that TLS uses it, even though we are concerned about the security of SHA1 in general. People are doing good work to provide alternatives that have better performance AND better security. In the specific case of YouTube: YouTube just recently added AES-GCM support. I would be very surprised if they didn't add ECDHE support soon. Lets give them some time to deploy ECDHE-RSA in a way they feel comfortable with. I will also reach out to some people who are likely familiar with what is going on there, but I probably won't be able to report back. It is tempting to add prefs, and I appreciate the effort to write the patches to do that. But, we generally only add prefs (in this module, at least) as a temporary way to disable brand-new features, or as a last resort. I don't think we're at the point where we need to consider last resorts. I really appreciate the good bug report. I recommend you subscribe to the dev-tech-crypto mailing list if you want to participate more in the development of TLS-related stuff in Firefox: https://lists.mozilla.org/listinfo/dev-tech-crypto.
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Comment on attachment 8447631 [details] [diff] [review] bz1029179-add-SHA256-and-GCM-ciphers.patch Review of attachment 8447631 [details] [diff] [review]: ----------------------------------------------------------------- I appreciate you taking time to write this patch. I did look at the patch and the patch looks correct for what it tries to do. But, as I said above, I don't think we should add these cipher suites. However, if you're interested in writing other TLS-related patches for Firefox, I'd love to have your help; please email me (brian@briansmith.org).
Attachment #8447631 - Flags: review?(brian) → feedback+
The reason I wrote this patch is so that we can go forward with removing RC4 from list of supported ciphers, and IMHO, the faster we do this, the better. I completely agree that the current set of ciphers Firefox offers, provides the best mix of secure and fast ciphers. That's why I left those new ciphers disabled by default. Problem is, that some administrators don't think the same. Google is just one example of such behaviour. I'm already subscribed to dev-tech-crypto, I'll continue the discussion there.
(In reply to Brian Smith (:briansmith, was :bsmith; NEEDINFO? for response) from comment #3) > In the specific case of YouTube: YouTube just recently added AES-GCM > support. I would be very surprised if they didn't add ECDHE support soon. > Lets give them some time to deploy ECDHE-RSA in a way they feel comfortable > with. I will also reach out to some people who are likely familiar with what > is going on there, but I probably won't be able to report back. Letting the web compatibility team know about this. What is best a new bug?
Flags: needinfo?(kdubost)
@kevin, If it indeed interop issues in between different browsers, it might be worth contacting them. In this case the best course of actions would be to open a bug in "Tech Evangelism :: Desktop" and to describe the issue and how to solve it.
Flags: needinfo?(kdubost)
Wow, is firefox just a mobile browser? With security performance isnt a primary consideration. Only compatibility and security is. A modern pc can use that cipher with no real problems, so it seems firefox has refused to provide a secure method of viewing youtube videos for political reasons? Who is Brian Smith, is he someone who makes decisions about firefox policy?
PC, yes it can handle it just fine (server side is different matter), but the intent is to make the client hello look identical both for the PC as well as the mobile version. See https://briansmith.org/browser-ciphersuites-01.html for details.
Given how badly busted RC4 is, I think that we should be reconsidering this bug. The performance of GCM is pretty good, and it doesn't rely on HMAC-SHA-256 as you might mistakenly imply from Brian's comment (I appreciate that the comments regarding performance were intended to be general). I do think that the patch needs to limit what it enables, possibly to this one suite. Yes, Youtube is special enough to justify special treatment. I know someone over there. I'll try to find out whether a forward-secrecy capable suite is likely.
Blocks: 1088915
(In reply to Martin Thomson [:mt] from comment #10) > I'll try to find out whether a forward-secrecy > capable suite is likely. I was under the impression their desire was to switch to ChaCha20+Poly1305 at some point. (bug 917571 for NSS support)
(In reply to Dave Garrett from comment #11) > I was under the impression their desire was to switch to ChaCha20+Poly1305 > at some point. (bug 917571 for NSS support) Record protection is orthogonal to key exchange.
(In reply to Martin Thomson [:mt] from comment #12) > (In reply to Dave Garrett from comment #11) > > I was under the impression their desire was to switch to ChaCha20+Poly1305 > > at some point. (bug 917571 for NSS support) > > Record protection is orthogonal to key exchange. What I mean is their goal seems to be to switch to TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 / TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, which are to be implemented in that bug. They seem to want to switch to that rather than improving their AES usage to add PFS.
Youtube now supports TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_RC4_128_SHA so we can CLOSE this bug. https://www.ssllabs.com/ssltest/analyze.html?d=r16---sn-5hnezn7r.googlevideo.com
This bug is already closed as INVALID.
Maybe it should be RESOLVED WORKSFORME, since the issue was fixed though not in the way originally suggested.
(In reply to mail from comment #14) > Youtube now supports > > TLS_RSA_WITH_RC4_128_SHA > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_ECDHE_RSA_WITH_RC4_128_SHA > Please note that the information from Google security folks is that these other suites are only enabled on *some* nodes. If you are in other locations, you might see the more limited set of suites.
This bug seems to really be about watching YouTube with RC4 ciphers disabled, so summary could be updated to "YouTube videos fail to load if RC4 ciphers are disabled"
(In reply to Martin Thomson [:mt] from comment #17) > Please note that the information from Google security folks is that these > other suites are only enabled on *some* nodes. If you are in other > locations, you might see the more limited set of suites. The comment was "And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's already enabled in some locations." as of 21th October. Indeed it was not enabled in Japan. But it's available now. So it's my understanding that the support has been extended wider locations within the last few days. Unless Google makes an additional comment, we have no reliable way to determine if other suites are enabled on all locations.
I didn't find a web-compat bug filed on this. FWIW, as of FF34 I'm having users re-enable SSLv3 to work with sites that only have TLS_RSA_ enabled (and user prefs effectively stay for the life of the profile). I recognize that Mozilla is trying to play hardball and back the sysadmins into a corner on this, but users are caught in the crossfire due to a lack of planning, strategy, and communication. I get why we don't want TLS_RSA_ for the long term, but SSLv3 isn't a better solution than TLS 1.2 with TLS_RSA_. Yeah, people who follow the .crypto newsgroup were probably aware of this .... for everybody else who has to deal with change processes, the easiest thing for users who can't manage about:config to do is switch to Chrome. Blech. I see the claim above that this bug is only about YouTube but the submitted patch does not reflect that claim. The resolution ought to be WONTFIX if Mozilla is really going to dig its heels in on this. It's worth noting that changes don't have to be permanent, and temporary changes can enable real progress if they reflect the needs of a rapidly-changing outside world.
(In reply to Bill McGonigle from comment #21) > I didn't find a web-compat bug filed on this. FWIW, as of FF34 I'm having > users re-enable SSLv3 to work with sites that only have TLS_RSA_ enabled > (and user prefs effectively stay for the life of the profile). I can't imagine servers enabling only TLS_RSA_WITH_AES_128_GCM_SHA256 for TLSv1.2 and enabling all other TLS_RSA_* cipher suites only for SSLv3. What cipher suites will be enabled for TLSv1 and v1.1? Please provide the URL of the server. Probably SSLv3 is irrelevant. Firefox 34+ will display an inappropriate message when the handshake failed with the server (bug 1113780). But I can't conclude without the URL. > I recognize > that Mozilla is trying to play hardball and back the sysadmins into a corner > on this, but users are caught in the crossfire due to a lack of planning, > strategy, and communication. We can't communicate with the site owner without the URL. > for > everybody else who has to deal with change processes, the easiest thing for > users who can't manage about:config to do is switch to Chrome. Blech. Chrome 40 will also disable SSLv3 (But, again, I'm not sure SSLv3 is really involved here without the URL).
Re-opening this and adding the DH flavor for completeness. We have some anecdotal reports of compat issues with some significant sites, in light of the impending RC4 deprecation. To the points raised in Comment 3: * Deprecating RSA key exchange is important, but not as much as getting rid of RC4. * More than 70% of TLS transactions today are using TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (http://mzl.la/1Suj6di), so worries about SHA-256 performance seem empirically unfounded. * We already have prefs for all the ciphersuites, and they've come in handy (e.g., for turning off RC4). The just-posted patch simply trims down Hubert's patch to the two suites in the title.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INVALID → ---
Summary: Add TLS_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers → Add TLS_RSA_WITH_AES_128_GCM_SHA256 and TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers
Attachment #8447631 - Attachment is obsolete: true
Comment on attachment 8703468 [details] MozReview Request: Bug 1029179 - Add TLS_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers r?ekr r?keeler https://reviewboard.mozilla.org/r/29363/#review26127 I would remove all the gratuitous whitespace changes. Note: order in this file has no impact on cipher order. ::: netwerk/base/security-prefs.js:31 (Diff revision 1) > pref("security.ssl3.rsa_aes_128_sha", true); > pref("security.ssl3.rsa_aes_256_sha", true); > pref("security.ssl3.rsa_des_ede3_sha", true); > -pref("security.ssl3.rsa_rc4_128_sha", true); > pref("security.ssl3.rsa_rc4_128_md5", true); > +pref("security.ssl3.rsa_rc4_128_sha", true); > > pref("security.default_personal_cert", "Ask Every Time"); > pref("security.remember_cert_checkbox_default_setting", true); Why did you move rc4_128_sha?
Attachment #8703468 - Flags: review?(ekr)
Note that the original MS14-066 patch added these ciphers, but they were unusable on the IIS server side (I think SChannel simply aborted the connection) and MS has to later issue a patch to disable the ciphers.
Comment on attachment 8703468 [details] MozReview Request: Bug 1029179 - Add TLS_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers r?ekr r?keeler Review request updated; see interdiff: https://reviewboard.mozilla.org/r/29363/diff/1-2/
Attachment #8703468 - Flags: review?(ekr)
https://reviewboard.mozilla.org/r/29363/#review26127 Sorry, artifact of editor config. Should be fixed now. > Why did you move rc4_128_sha? I did an alphabetical sort on the last 5 entries on the list. Should be fixed now.
Comment on attachment 8703468 [details] MozReview Request: Bug 1029179 - Add TLS_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers r?ekr r?keeler https://reviewboard.mozilla.org/r/29363/#review26131 This LGTM, though not sure why you are putting GCM first in the prefs and last in the telemetry
Attachment #8703468 - Flags: review?(ekr) → review+
(In reply to Yuhong Bao from comment #26) > Note that the original MS14-066 patch added these ciphers, but they were > unusable on the IIS server side (I think SChannel simply aborted the > connection) and MS has to later issue a patch to disable the ciphers. Yeah, adding DHE_RSA+AES_GCM would increase TLS intolerance issue. Chrome had to add DHE_RSA+AES_GCM as a fallback cipher suite (like RC4) because of this problem. https://code.google.com/p/chromium/issues/detail?id=538690#c4
(In reply to Richard Barnes [:rbarnes] from comment #24) > Re-opening this and adding the DH flavor for completeness. If the DH flavor is being added only for the completeness, I advice not to add it.
(In reply to Masatoshi Kimura [:emk] from comment #30) > (In reply to Yuhong Bao from comment #26) > > Note that the original MS14-066 patch added these ciphers, but they were > > unusable on the IIS server side (I think SChannel simply aborted the > > connection) and MS has to later issue a patch to disable the ciphers. > > Yeah, adding DHE_RSA+AES_GCM would increase TLS intolerance issue. Chrome > had to add DHE_RSA+AES_GCM as a fallback cipher suite (like RC4) because of > this problem. > https://code.google.com/p/chromium/issues/detail?id=538690#c4 The plain RSA GCM cipher suite would have the same problem BTW.
(In reply to Richard Barnes [:rbarnes] from comment #24) > Re-opening this and adding the DH flavor for completeness. We have some > anecdotal reports of compat issues with some significant sites, in light of > the impending RC4 deprecation. Not a fan of relying on anecdotal reports for changes like this. Is there any telemetry or specific servers that show this would improve things? Also, completeness is not really desired in this realm, so separate justification for each would be nice. (comment 0 is long since obsolete) If one or both can be shown to help, ok, but just resurrecting this old bug without further info doesn't seem that great.
Version: 30 Branch → Trunk
I am fine with not adding DHE_RSA, but I think it's a reasonable assumption that we should be matching Chrome's behavior here, provided there's some evidence that there are sites which would have broken here.
https://reviewboard.mozilla.org/r/29363/#review26131 Because we want it pref'ed over CBC in TLS, but we don't want to disturb the telemetry bin values for existing things.
(In reply to Dave Garrett from comment #33) > (In reply to Richard Barnes [:rbarnes] from comment #24) > > Re-opening this and adding the DH flavor for completeness. We have some > > anecdotal reports of compat issues with some significant sites, in light of > > the impending RC4 deprecation. > > Not a fan of relying on anecdotal reports for changes like this. Is there > any telemetry or specific servers that show this would improve things? The one that was pointed out to me was <https://www.gerber.com/>. That seemed significant enough to me to be worth the change. Telemetry is of course useless for this sort of thing, because we can't collect specific hosts. > Also, completeness is not really desired in this realm, I disagree with you here. In this domain, incompleteness == inscrutable failure, so we should offer the most complete set of ciphers that meet our security standards.
https://reviewboard.mozilla.org/r/29363/#review26131 But changing the prefs doesn't have any impact here. It's NSS's internal priority list that matters, and there GCM already comes first.
(In reply to Richard Barnes [:rbarnes] from comment #36) > The one that was pointed out to me was <https://www.gerber.com/>. That > seemed significant enough to me to be worth the change. gerber.com has an Alexa ranking of 103,909. This is not a very popular or important site. They will fix themselves once they realize they will stop working. More important sites than them have done so. > Telemetry is of > course useless for this sort of thing, because we can't collect specific > hosts. That doesn't make telemetry useless for this at all. In addition, Mozilla has a tool that can be easily run that will tell you about TLS compatibility issues for top sites, made by mwobensmith. > > Also, completeness is not really desired in this realm, > > I disagree with you here. In this domain, incompleteness == inscrutable > failure, so we should offer the most complete set of ciphers that meet our > security standards. I wish your security standards weren't so low. Regardless, Chrome is dropping the TLS_DHE_* cipher suites. They've already announced it on their mailing list. Although we don't have hard numbers, I had a lot of private correspondence from site owners and others indicating that Firefox's refusal to implement these two cipher suites is what tipped the balance in getting the TLS_ECDHE_* variants deployed. It would be sad to cave on this point after two years. gerber.com will fix itself. Their site admins seem to be relatively in the know, based on their Netcraft report. So, this should be RESOLVED INVALID again.
(In reply to Richard Barnes [:rbarnes] from comment #24) > [...] To the points raised in Comment 3: > > [...] > > * More than 70% of TLS transactions today are using > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 or > TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (http://mzl.la/1Suj6di), so worries > about SHA-256 performance seem empirically unfounded. Just to clarify Brian's point in comment 3: he was talking about HMAC-SHA256-based cipher suites. AES_128_GCM_SHA256 cipher suites don't use HMAC-SHA256 for message authentication. The _SHA256 in AES_128_GCM_SHA256 refers to the PRF hash function, which is SHA256 by default in TLS 1.2. (Martin also pointed out this potential misunderstanding in comment 10.)
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #38) > (In reply to Richard Barnes [:rbarnes] from comment #36) > > The one that was pointed out to me was <https://www.gerber.com/>. That > > seemed significant enough to me to be worth the change. > > gerber.com has an Alexa ranking of 103,909. This is not a very popular or > important site. They will fix themselves once they realize they will stop > working. More important sites than them have done so. > > > Telemetry is of > > course useless for this sort of thing, because we can't collect specific > > hosts. > > That doesn't make telemetry useless for this at all. In addition, Mozilla > has a tool that can be easily run that will tell you about TLS compatibility > issues for top sites, made by mwobensmith. > > > > Also, completeness is not really desired in this realm, > > > > I disagree with you here. In this domain, incompleteness == inscrutable > > failure, so we should offer the most complete set of ciphers that meet our > > security standards. > > I wish your security standards weren't so low. Are you forgetting that we still support TLS_RSA_WITH_AES_128_CBC_SHA? Empirically, the minimum bar is still below RSA with AES-GCM. > Regardless, Chrome is dropping the TLS_DHE_* cipher suites. They've already > announced it on their mailing list. Great. Having prefs for these means that we can turn them off when we're ready. In the meantime, we can ease some of the pain of disabling RC4. > Although we don't have hard numbers, I had a lot of private correspondence > from site owners and others indicating that Firefox's refusal to implement > these two cipher suites is what tipped the balance in getting the > TLS_ECDHE_* variants deployed. It would be sad to cave on this point after > two years. The way I would read this is: We've had the impact we wanted. Now we can enable these ciphers temporarily to help people through the RC4 transition.
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #39) > Here's the Chrome intent to deprecate: > https://groups.google.com/a/chromium.org/d/msg/security-dev/dYyhKHPnrI0/ > pNxx8vTKBAAJ This appears to be an intent to deprecate DHE. I suggest we take these issues separately and start by enabling TLS_RSA_WITH_AES_128_GCM_SHA256
(In reply to Richard Barnes [:rbarnes] from comment #36) > The one that was pointed out to me was <https://www.gerber.com/>. This appears to be a poorly-configured akamai host: https://www.ssllabs.com/ssltest/analyze.html?d=gerber.com It might be more effective to reach out to them (akamai and/or gerber) directly. As we've seen with RC4, it can be difficult to remove cipher suites once they're supported. That said, we have a number of RSA key-exchange cipher suites, and deprecating them is going to be a lot of work anyway; adding one more would presumably make the situation worse, but not by much. Here's what I would like to see: * us reaching out to akamai and asking what the deal is with that server configuration * a build with just TLS_RSA_WITH_AES_128_GCM_SHA256 enabled so :mwobensmith can run tlscanary and see if that fixes a significant number of the remaining hosts that fail as a result of RC4 being disabled * investigate the potential compatibility issue noted in comment 26 (in particular, this isn't clear to me - what is the issue? Is there a known host that exhibits this behavior?) At that point we can make a decision as to whether or not it would be beneficial to go ahead with this.
Flags: needinfo?(yuhongbao_386)
Comment on attachment 8703468 [details] MozReview Request: Bug 1029179 - Add TLS_RSA_WITH_AES_128_GCM_SHA256 suite to offered ciphers r?ekr r?keeler https://reviewboard.mozilla.org/r/29363/#review26229 See coment 43. Do you have contacts at akamai?
Attachment #8703468 - Flags: review?(dkeeler)
The connection abort by SChannel is I think after the ServerHello showing the affected RSA/DHE_RSA GCM cipher suite.
Flags: needinfo?(yuhongbao_386)
But since Firefox doesn't use SChannel as a client, that wouldn't be a concern here, right?
(In reply to David Keeler [:keeler] (use needinfo?) from comment #46) > But since Firefox doesn't use SChannel as a client, that wouldn't be a > concern here, right? I am talking about the server side.
I see - so the concern is we'll advertise those cipher suites as a client and the server will just hang? Do we have any idea how wide-spread this is? Also, what does Chrome do? The link in comment 30 appears to be about deprecating DHE and doesn't even mention the RSA variant.
Chrome would originally just do TLS 1.1 fallback.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #48) > I see - so the concern is we'll advertise those cipher suites as a client > and the server will just hang? Do we have any idea how wide-spread this is? > Also, what does Chrome do? See https://code.google.com/p/chromium/issues/detail?id=536200#c3. > The link in comment 30 appears to be about deprecating DHE and doesn't even mention the RSA variant. Yes, it was mentioned because the current patch in this bug also adds the TLS_DHE_* variant. Mozilla already has a separate bug for the TLS_DHE_* variant in bug 1084554.
See also bug 1084554 comment 14. Enabling either or both of these cipher suites without also doing other things that would re-introduce fallback attacks is likely to cause significant compatibility issues in itself.
(In reply to David Keeler [:keeler] (use needinfo?) from comment #43) > Here's what I would like to see: > > * us reaching out to akamai and asking what the deal is with that server > configuration Already done, as of this morning. > * a build with just TLS_RSA_WITH_AES_128_GCM_SHA256 enabled so :mwobensmith > can run tlscanary and see if that fixes a significant number of the > remaining hosts that fail as a result of RC4 being disabled I've emailed Matt to see if this is possible. > * investigate the potential compatibility issue noted in comment 26 (in > particular, this isn't clear to me - what is the issue? Is there a known > host that exhibits this behavior?) If Matt's scans come back indicating that we should proceed, and nobody comes forward with specific steps to reproduce, I'm inclined to proceed.
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #51) > See also bug 1084554 comment 14. Enabling either or both of these cipher > suites without also doing other things that would re-introduce fallback > attacks is likely to cause significant compatibility issues in itself. I think the number of IIS servers affected is getting smaller every day though and there is an easy fix sysadmins can apply to these servers.
I tested 495 RC4-only or TLS intolerant servers with or without DHE_RSA_AES_GCM and RSA_AES_GCM. 7 of 495 servers. The list of the servers is derived from the former IntolerantFallbackList.inc. I'm still maintaining this list locally. 7 of 495 servers work with DHE_RSA_AES_GCM and RSA_AES_GCM. All of 7 servers work only with RSA_AES_GCM. Additional cipher suites didn't break servers in the list. So I guess we don't have to enable DHE_RSA_AES_GCM and broken IIS servers are negligible. Here's the 7 servers: 1800registry.com www.akmembers.com www.alphashirt.com www.redcaptour.com www.remotepc.net www.riverguide.go.kr www.wetax.go.kr
On the public web at least. There may be internal intranet sites affected by this. It is pretty simple for sysadmins to fix these servers though.
I ran a compatibility test on over 200k top secure sites. However, I believe I misunderstood my instructions and tested only the effects of this patch vs without, instead of this patch vs its effect on reducing RC4 breakage. I will run another pass for the latter shortly. Regardless, turning on these prefs breaks half a dozen sites. a) security.ssl3.dhe_rsa_aes_128_gcm_sha256=true b) security.ssl3.rsa_aes_128_gcm_sha256=true Sites broken with this patch: https://www.lankahost.net/ (a,b) https://www.rcga.org/ (a,b) https://www.shearings.com/ (a,b) https://moj.telekom.mk/ (a,b) https://hirotaka.org/ (b) https://www.hongkongpost.hk/ (a,b) [1] [1] This site routes to multiple IP addresses, as well as a redirect to a .com domain. Hence, results will vary.
Apply this on top of rbarnes' patch. This will fix comment #56 problem.
Another test has been run to determine the impact of this rbarnes' patch on RC4 breakage. Keep in mind that this breakage can surface other types of TLS errors due to various server configs. Therefore, I’m including numbers that show total site breakage as well as the specific error “ssl_error_no_cypher_overlap". There were 211096 sites tested in this run. The test config “true/true” is equivalent to the defaults of this patch. The config “false/false” should be equivalent to what we have in Nightly right now. In summary, the test config of “false/true” seemed to alleviate the most breakage. Prefs: a) security.ssl3.dhe_rsa_aes_128_gcm_sha256 b) security.ssl3.rsa_aes_128_gcm_sha256 [1] All RC4 breakage [2] ssl_error_no_cypher_overlap raw number of broken sites in parentheses true/true .1535% (324) [1] .0985% (208) [2] false/false .162% (342) [1] .1023% (216) [2] false/true .1483% (313) [1] .0904% (191) [2] true/false .1629% (344) [1] .1061% (224) [2]
Keeler and I discussed, and our feeling was that the improvements are too marginal here (especially given that RC4 is already off) to be worth the risk of turning this on. Thanks to everyone for the discussion.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → WONTFIX
I know this has been discussed at length and this is WONTFIXed, but you're running into issues right now and in the near future not offering RSA-AES-GCM and/or RSA-AES-SHA256, so I suggest you reconsider this at this point. We're having a repeat here because of 3DES. A few forces at work here: - Quite a few server operators are (mistakingly) under the impression that SHA1 is no longer secure for HMAC use because a collision was found. As such, these operators have started disabling cipher suites that use SHA1. - This currently still works by having Firefox fall back to 3DES which is generally kept enabled for the time being. This is weaker than these connections should be (112-bit, known weaknesses) because there is no other overlap. - The lack of overlap is often caused by slow-moving IT infrastructure in financial institutions; quite a few run old IIS versions or similar that don't offer ECC or proper support for DHE. - When 3DES is officially advised against and becomes disabled (because of eg. SWEET32), Firefox won't be able to connect to these servers any longer since there won't be a cipher overlap. - Other browsers (Safari, IE, Chrome) support these RSA-AES(-GCM)-SHA256/384 suites currently, only Firefox does not. It may be "more expensive", but end users would rather have more expensive encryption than weak encryption or no connection at all.
I'm afraid people cannot distinguish between HMAC-SHA1 and plain SHA-1 :(
I would also like to see: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) The reason being that those are the only AEAD ciphers with FS supported by Windows Server 2008 R2 and Windows Server 2012(r2): https://msdn.microsoft.com/en-us/library/windows/desktop/mt767780(v=vs.85).aspx https://msdn.microsoft.com/nl-nl/library/windows/desktop/mt767781(v=vs.85).aspx Furthermore with the advent of KB3174644, Windows server administrators can configure a DH-key size of up to 4096-bit eliminating the threat of weak DH-keys: https://technet.microsoft.com/en-us/library/security/3174644.aspx Firefox supporting (0x9f) and (0x9e) would better secure users visiting Server 2008R2 or 2012R2 based web-applications.
It will not improve the security much because they don't support DHE > 1024bit either.
(In reply to Masatoshi Kimura [:emk] from comment #66) > It will not improve the security much because they don't support DHE > > 1024bit either. You´re incorrect, 2008 R2 and 2012(R2) support up to 4096-bit DHE this is configurable since september 2016: https://technet.microsoft.com/en-us/library/security/3174644.aspx : "Administrators can change the size of the modulus by adding the registry key value in the following procedure. If the key value is absent, the default of the modulus remains 1024 bit. The following example sets the modulus size to 2048 bit. Valid key values are decimal: 1024, 2048, 3072 and 4096."
We're running into the "no shared cipher" situation when we disable TLSv1.0 and TLSv1.1 on our product (for Common Criteria certification). On our REST API port, I had to disable ECDHE because one of the clients using the API has a bug that would cause a "bad point" error in the underlying OpenSSL 1.0.2j. We already have some funky GUI code that supports multiple certificate acceptances because we access 443 and our API port from our JS application (Bug 700387). There apparently is no workaround for this, so we'll have to throw in the towel, and declare Firefox disallowed in CC mode for our product. All of the other browsers work fine.
(In reply to Kent Peacock from comment #68) ... > application (Bug 700387). There apparently is no workaround for this, so For posterity, I suspect this was intended to be bug 700837.
Oops, yes it's 700837.
(In reply to Kent Peacock from comment #68) > We're running into the "no shared cipher" situation when we disable TLSv1.0 > and TLSv1.1 on our product (for Common Criteria certification). On our REST > API port, I had to disable ECDHE because one of the clients using the API > has a bug that would cause a "bad point" error in the underlying OpenSSL > 1.0.2j. We already have some funky GUI code that supports multiple > certificate acceptances because we access 443 and our API port from our JS > application (Bug 700387). There apparently is no workaround for this, so > we'll have to throw in the towel, and declare Firefox disallowed in CC mode > for our product. All of the other browsers work fine. exactly which part of Common Criteria disallows AES-CBC when used in TLS or SHA-1 HMAC?
Good point. However, what I see with OpenSSL (1.0.2j) when I add !TLSv1:!TLSv1.1 to the ciphers spec is that this: Supported Server Cipher(s): Preferred TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA Accepted TLSv1.2 256 bits AES256-GCM-SHA384 Accepted TLSv1.2 256 bits AES256-SHA256 Accepted TLSv1.2 256 bits AES256-SHA Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA Accepted TLSv1.2 128 bits AES128-GCM-SHA256 Accepted TLSv1.2 128 bits AES128-SHA256 Accepted TLSv1.2 128 bits AES128-SHA Preferred TLSv1.1 256 bits DHE-RSA-AES256-SHA Accepted TLSv1.1 256 bits AES256-SHA Accepted TLSv1.1 128 bits DHE-RSA-AES128-SHA Accepted TLSv1.1 128 bits AES128-SHA Preferred TLSv1.0 256 bits DHE-RSA-AES256-SHA Accepted TLSv1.0 256 bits AES256-SHA Accepted TLSv1.0 128 bits DHE-RSA-AES128-SHA Accepted TLSv1.0 128 bits AES128-SHA changes to this: Supported Server Cipher(s): Preferred TLSv1.2 256 bits DHE-RSA-AES256-GCM-SHA384 Accepted TLSv1.2 256 bits DHE-RSA-AES256-SHA256 Accepted TLSv1.2 256 bits AES256-GCM-SHA384 Accepted TLSv1.2 256 bits AES256-SHA256 Accepted TLSv1.2 128 bits DHE-RSA-AES128-GCM-SHA256 Accepted TLSv1.2 128 bits DHE-RSA-AES128-SHA256 Accepted TLSv1.2 128 bits AES128-GCM-SHA256 Accepted TLSv1.2 128 bits AES128-SHA256 It appears that OpenSSL 1.0.2j only enables SHA2 hashes for TLSv1.2.
Adding !TLS1 to the cipher suite disables _ciphers_ that were defined in TLSv1.0 or defined for use with TLSv1.0 and later. It does _not_ disable TLSv1.0 or TLSv1.1 protocol. TLSv1.2, TLSv1, SSLv3, SSLv2 TLS v1.2, TLS v1.0, SSL v3.0 or SSL v2.0 cipher suites respectively. Note: there are no ciphersuites specific to TLS v1.1. https://www.openssl.org/docs/man1.0.2/apps/ciphers.html Since TLSv1.2 is a superset of TLS 1.0 and TLS 1.1, you can use TLSv1.0 ciphers in TLSv1.2 (and you then depend only on SHA-1 for HMAC, which is allowed in FIPS and Common Criteria without any limitations) The enabled protocols are set using a different API; SSL_CTX_set_options() with SSL_OP_NO_TLSv1 and SSL_OP_NO_TLSv1_1: https://www.openssl.org/docs/man1.0.2/ssl/SSL_CTX_set_options.html
Good point. I used the ciphers list because it was there and easy to just add the !TLSv1... to optionally disable TLSv1/1.1. I did find a place where I was already calling SSL_CTX_set_options() to disable SSLv2 and SSLv3. I added another conditional call for TLSv1/11, and now FF works. Thanks!
Blocks: 1628878
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: