Closed Bug 1084554 Opened 12 years ago Closed 10 years ago

Implement TLS 1.2 DHE AES-GCM cipher suites

Categories

(Core :: Security: PSM, defect)

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

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1029179

People

(Reporter: post+mozilla, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.2.0 Build ID: 20141015014004 Steps to reproduce: Visit https://webmail.uni-saarland.de/ Actual results: I got "Error code: ssl_error_no_cypher_overlap". Expected results: The connection should have worked. The server supports the following ciphers via TLS 1.2: DHE-RSA-AES256-GCM-SHA384 (high, 256 bits, FS) DHE-RSA-AES256-SHA256 (high, 256 bits, FS) AES256-GCM-SHA384 (high, 256 bits, no FS) AES256-SHA256 (high, 256 bits, no FS) DHE-RSA-AES128-GCM-SHA256 (high, 128 bits, FS) DHE-RSA-AES128-SHA256 (high, 128 bits, FS) AES128-GCM-SHA256 (high, 128 bits, no FS) AES128-SHA256 (high, 128 bits, no FS) I understand that Firefox does not add support for TLS 1.2 ciphers with non-ephermal key exchange, to help spread forward secrecy. However, there are four perfectly fine ephermal cipher suites supported by the server, two of them even with GCM. Why does Firefox not support any of these?
Reproduces for me in current Nightly.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I should add that above server redirects to <https://idp.uni-saarland.de/>, and that's the one offering so few ciphers - in case you want to point some tools at it.
At the time we made the cipher suite changes last year (which you seem to be familiar with), we decided not to add any new DHE cipher suites because most servers are only using 1024-bit DHE parameters and we don't have a way in TLS yet of negotiating the size of the DHE key. Also, we decided not to add any HMAC-SHA2-based cipher suites because they are so inefficient and don't offer any significant security advantage over the HMAC-SHA1-based cipher suites. (Note that HMAC-SHA1 is much stronger than plain SHA1.) Over to PSM. I recommend RESOLVED INVALID.
Component: Security → Security: PSM
OS: Linux → All
Hardware: x86_64 → All
Yes it did - probably they got complaints from lots of Firefox users ;-)
(In reply to Brian Smith (:briansmith, :bsmith, use NEEDINFO?) from comment #3) > Also, we decided not to add > any HMAC-SHA2-based cipher suites because they are so inefficient and don't > offer any significant security advantage over the HMAC-SHA1-based cipher > suites. (Note that HMAC-SHA1 is much stronger than plain SHA1.) In the wake of POODLE, some admins are disabling the SSLv3 ciphers and thinking that will disable the SSLv3 protocol. As a result, I've seen servers that end up only supporting ciphers like AES256-GCM-SHA384. It'd be nice if Firefox could connect to such hosts. Ross
Please post an example of such servers.
Oh bug 1109859? I suggest you to fix the server configuration.
My pound reverse proxy would be an example. It supports the following ciphers: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 Google Chrome works fine with TLS 1.2. Safari works fine on the site. Even freaking IE works fine with TLS 1.2 on the site. These are both PC and mobile versions of these browsers. Firefox dies a horrible death giving this error indicating that SSLv3 is enabled, when it is explicitly disabled. I'm not buying the "fix the server configuration" when other current browsers are not having the issue outside of Firefox. I'm not sure how Firefox is "detecting" SSLv3, but it obviously isn't exactly right.
(In reply to DubStep from comment #9) > My pound reverse proxy would be an example. It supports the following > ciphers: > > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 > TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 > TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 > TLS_RSA_WITH_AES_128_GCM_SHA256 > TLS_RSA_WITH_AES_256_GCM_SHA384 > TLS_RSA_WITH_AES_128_CBC_SHA256 > TLS_RSA_WITH_AES_256_CBC_SHA256 According to [1] and [2], pound Pound2.7e supports TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 when linked to OpenSSL 1.0+. We've intentionally avoided implementing the TLS_DHE_* variants of the AES-GCM cipher suites due to real-world security, compatibility, and performance problems with the TLS_DHE_* variants. [1] http://www.apsis.ch/pound/pound_list/archive/2014/2014-12/1418201925000 [2] http://comments.gmane.org/gmane.comp.web.pound.general/7487
Summary: Implement TLS 1.2 DHE AES cipher suits → Implement TLS 1.2 DHE AES-GCM cipher suites
(In reply to DubStep from comment #9) > I'm not sure how > Firefox is "detecting" SSLv3, but it obviously isn't exactly right. The wrong error message issue is tracked by bug 1113780.
Oh, so it uses some other ciphers, right...I see that now in your previous post. The error message is what threw me off. I've been running down the wrong path the entire time. Yay! Anyways, the real fix was not disabling SSLv3 ciphers in pound, which apparently kills everything BUT TLS 1.2 and even some of those, but disabling *just* the SSLv3 protocol and leaving the !SSLv3 cipher command out of it. Found that info here: http://comments.gmane.org/gmane.comp.web.pound.general/7487 Also, the cipher list there gave me better results (Full Forward Secrecy) than the ones on the Mozilla server side TLS page, so another bonus.
see also bug 1126830
Note that there are compatibility issues with enabling TLS_DHE_* and TLS_RSA_* variants of the AES-GCM cipher suites. See: https://support.microsoft.com/en-us/kb/2992611 https://code.google.com/p/chromium/issues/detail?id=433406 https://code.google.com/p/chromium/issues/detail?id=434093 https://code.google.com/p/chromium/issues/detail?id=472333 I think at this point we should just resolve this as WONTFIX. Any objections?
> We've intentionally avoided implementing the TLS_DHE_* > variants of the AES-GCM cipher suites due to real-world > security, compatibility, and performance problems with > the TLS_DHE_* variants. So what you're saying here is, if you want the most secure ciphers (AEAD), you have to take ECDHE, whether you trust the NIST curves or not (I don't believe theres much room in the TLS spec currently for anything other than a couple of NIST curves). So the security is arguably ruined. > we decided not to add any new DHE cipher suites because > most servers are only using 1024-bit DHE parameters So when we're asking for new ciphers because the browser doesn't connect to server with a certain configuration (reasonably secure, I might add), > I suggest you to fix the server configuration. is fine, but not fine to adopt the same attitude for "these servers run with bad dhparams". Fundamentally, DHE* is part of TLS1.2 spec. So are SHA2-based ciphers but we have this, > Also, we decided not to add any HMAC-SHA2-based cipher suites because > they are so inefficient and don't offer any significant security advantage > over the HMAC-SHA1-based cipher suites. the end result of which is that one cannot connect to a server using TLS1.2 and 256 bits AEAD cipher. I don't see how this should be resolved invalid without at the very least adding support for ECDHE with AES256GCM and SHA384.
@yaxxie: some people may prefer to stay with ECC-free cipher suites (or at least free from NSA Suite B curves), so IMO we should keep things like DHE-RSA-AES256-GCM-SHA384. We should disable support for weak DH parameters, though. Reasonable minimum is 2048 bits, but I understand support for 1024 bits dhparam might be needed for some time for compatibility reasons. As of SHA-1 - it shouldn't be used for crypto, because collisions can be generated for moderate amount of money: https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html I know that collision resistance is not critical in case of HMAC, but any organization being serious about crypto should simply ban SHA-1 as it happened years ago with MD5. If Mozilla wants to be ready for that it should add support for HMAC-SHA-256 and HMAC-SHA-384.
@Michal 100% with you on both, need both DHE and SHA2, I was just pointing out some of the things in this thread that have been used for arguing against either of those, and that if they REALLY don't want DHE then at the very least include SHA2 with the ECDHE suites. Sadly enough I see that the response to logjam has been to disable DHE suites entirely, rather than rejecting 512bit params, so I am not sure what we can hope for here really.
(In reply to yaxxie from comment #17) > Sadly enough I see that the response to logjam has been to disable DHE > suites entirely, rather than rejecting 512bit params, so I am not sure what > we can hope for here really. According to <https://www.ssllabs.com/ssltest/viewMyClient.html>, my Firefox (Iceweasel 39 on Debian) still offers "TLS_DHE_RSA_WITH_AES_128_CBC_SHA" and "TLS_DHE_RSA_WITH_AES_256_CBC_SHA". So I wonder what exactly you are referring to?
Ralf: look at first actions against Logjam: https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/ disabling DHE instead of blocking weak dhparam. It looked more like attempts to discredit DHE and push everyone into ECC. And I am not so sure if that's best way to protect our privacy, especially with multiple TLS clients supporting only NSA Suite B curves.
Right, before FF implemented the parameter checking, some people disabled DHE manually in an understandable effort to protect against logjam. I doubt that many did though, most users won't have any idea - and the *default* (and official Mozilla stanza, as far as I can tell) is still to support DHE. The authors of the plugin *could now* ship an update that re-enabled DHE on FF39+... but that's getting even more off-topic for this bug.
@Ralf I appear to have been mistaken, I believed I saw somewhere that the DHE suits were made to false preference by default. In any case I don't believe it changes the main thrust of my point, where it appears within this bug that people seem to want to resist having DHE/SHA2 suites for some reason or another. I just don't see how it is acceptable to tell server admins "your config is too strong, weaken it" in response to a request for more ciphers (and ciphers that one might trust more), when the motivation for not including some of those ciphers is because other server admins have them in weak configs. A cryptosystem with low diveristy of primitives is a disaster waiting to happen, and this is where firefox appears to be at, essentially by refusing to have SHA2 on the basis of performance, and DHE because some server admins are bad at it. NSS itself supports the suites in question, is that correct?
I'll risk to reopen this issue, but HTTP/2 appeared with its list of blacklisted cipher suites. Here is a server configuration that I encountered: Cipher suites preferred: >ECDHE-RSA-AES256-GCM-SHA384 >DHE-RSA-AES256-GCM-SHA384 >ECDHE-RSA-AES128-GCM-SHA256 >DHE-RSA-AES128-GCM-SHA256 >ECDHE-RSA-AES256-SHA384 >ECDHE-RSA-AES256-SHA >DHE-RSA-AES256-SHA256 >DHE-RSA-AES256-SHA >ECDHE-RSA-AES128-SHA256 >ECDHE-RSA-AES128-SHA >DHE-RSA-AES128-SHA256 >DHE-RSA-AES128-SHA The only supported elliptic curve is a Brainpool one (someone that does not like NIST curves like @yaxxie said), making only DHE-AES-CBC suites available with Firefox. However these suites are blacklisted by Firefox using HTTP/2, according to https://tools.ietf.org/html/rfc7540#appendix-A SSL Labs result: https://www.ssllabs.com/ssltest/analyze.html?d=graph.antoineducret.eu&s=2a01%3ae34%3aef4f%3a7d20%3a0%3a0%3a0%3a12&hideResults=on&latest The only way to access this website with Firefox is to disable HTTP/2 support, and I don't think this is the right way to do this.
(In reply to JdL from comment #22) > The only supported elliptic curve is a Brainpool one (someone that does not > like NIST curves like @yaxxie said), making only DHE-AES-CBC suites > available with Firefox. It violates the HTTP/2 spec. https://tools.ietf.org/html/rfc7540#section-9.2.2 > The black list includes the cipher suite that TLS 1.2 makes > mandatory, which means that TLS 1.2 deployments could have non- > intersecting sets of permitted cipher suites. To avoid this problem > causing TLS handshake failures, deployments of HTTP/2 that use TLS > 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] > with the P-256 elliptic curve [FIPS186].
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE

Can we revisit this? Just today I couldn't get to https://unicode.org because there was no cipher overlap with Firefox (I have disabled TLS pre-1.2, and additionally all CBC ciphers), and I was a bit confused, only to learn that there's no support for AES in GCM mode with DHE key exchange.

https://www.ssllabs.com/ssltest/analyze.html?d=unicode.org

The only future-proof secure configuration there is TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 / TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, which Firefox refuses to support for some reason. NSS already has all the primitives required, and even if you don't want to bother with all the new suits, at least consider GCM variants.

Sure, I can re-enable CBC ciphers, but why do you force users to use less secure solutions?

You need to log in before you can comment on or make changes to this bug.