Bug 1185708

(In reply to Jeroen from comment #0)
> Using curl on a clean vanilla Fedora 21 to retrieve a site hosted via the
> cloudflare https service gives an error:
> 
>     curl https://www.opencpu.org
>     >> curl: (35) Cannot communicate securely with peer: no common
> encryption algorithm(s).

This works if you explicitly enable the cipher-suite:

$ curl -4svo/dev/null --ciphers ecdhe_ecdsa_aes_128_gcm_sha_256 https://www.opencpu.org
* Rebuilt URL to: https://www.opencpu.org/
*   Trying 104.28.2.50...
* Connected to www.opencpu.org (104.28.2.50) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* Server certificate:
*       subject: CN=sni70697.cloudflaressl.com,OU=PositiveSSL Multi-Domain,OU=Domain Control Validated
*       start date: Oct 01 00:00:00 2014 GMT
*       expire date: Sep 30 23:59:59 2015 GMT
*       common name: sni70697.cloudflaressl.com
*       issuer: CN=COMODO ECC Domain Validation Secure Server CA 2,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
> GET / HTTP/1.1
> User-Agent: curl/7.40.0
> Host: www.opencpu.org
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: cloudflare-nginx
< Date: Mon, 26 Jan 2015 08:53:08 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: __cfduid=d94b5fbca792c1d604b3348e42b2e34e01422262388; expires=Tue, 26-Jan-16 08:53:08 GMT; path=/; domain=.opencpu.org; HttpOnly
< Last-Modified: Mon, 12 Jan 2015 21:07:56 GMT
< Expires: Mon, 26 Jan 2015 08:20:06 GMT
< Cache-Control: max-age=600
< Via: 1.1 varnish
< Age: 392
< X-Served-By: cache-fra1228-FRA
< X-Cache: HIT
< X-Cache-Hits: 1
< X-Timer: S1422262388.342638,VS0,VE0
< Vary: Accept-Encoding
< CF-RAY: 1aeb7a7684330595-PRG
<
{ [502 bytes data]
* Connection #0 to host www.opencpu.org left intact

> Also:
> 
>     curl https://www.cloudflare.org
>     >> curl: (51) Unable to communicate securely with peer: requested domain
> name does not match the server's certificate.

Same here, but the certificate does not apply to server's hostname, so you need to connect with --insecure:

$ curl -4svo/dev/null --ciphers ecdhe_rsa_aes_128_gcm_sha_256 https://www.cloudflare.org
* Rebuilt URL to: https://www.cloudflare.org/
*   Trying 198.41.215.163...
* Connected to www.cloudflare.org (198.41.215.163) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* Server certificate:
*       subject: OU=COMODO EV Multi-Domain SSL,OU=CloudFlare Security,O="CloudFlare, Inc.",STREET=665 Third Street,L=San Francisco,ST=CA,postalCode=94107,C=US,businessCategory=Private Organization,incorporationState=Delaware,incorporationCountry=US,serialNumber=4710875
*       start date: Jan 05 00:00:00 2015 GMT
*       expire date: Dec 31 23:59:59 2015 GMT
*       common name: (nil)
*       issuer: CN=COMODO Extended Validation Secure Server CA,O=COMODO CA Limited,L=Salford,ST=Greater Manchester,C=GB
* NSS error -12276 (SSL_ERROR_BAD_CERT_DOMAIN)
* Unable to communicate securely with peer: requested domain name does not match the server's certificate.

> This problem only appears on Fedora, not on Ubuntu or Mac running the same
> version of curl. The common factor with both of these sites is that they use
> ECC SSL certificates to secure their https connections, rather than the
> traditional RSA certificates used by most sites. These are currently very
> rare, but they are expected to increase in popularity in the future.
> 
> Both the versions of curl and NSS in use were built with ECC and therefore
> ought to support these certificates.

NSS simply does not enable the required cipher-suites by default.

> This also worries me:
> 
>     certutil -L
>     >> certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The
> certificate/key database is in an old, unsupported format.

The default database no longer works, so you need to use -d sql:/etc/pki/nssdb -- I guess the default database of certutil should also be changed at some point.

(In reply to Kamil Dudka from comment #1)
> Same here, but the certificate does not apply to server's hostname, so you
> need to connect with --insecure

I don't think this is entirely true; the certificate is valid for the domain (according to any browser).

(In reply to Jeroen from comment #2)
> (In reply to Kamil Dudka from comment #1)
> > Same here, but the certificate does not apply to server's hostname, so you
> > need to connect with --insecure
> 
> I don't think this is entirely true; the certificate is valid for the domain
> (according to any browser).

Firefox on my Fedora 21 box says:

www.cloudflare.org uses an invalid security certificate. The certificate is only valid for the following names: cloudflare.com, www.cloudflare.com (Error code: ssl_error_bad_cert_domain)

My bad, it is cloudflare.com instead of cloudflare.org; sorry about that. So it's just the cipher problem indeed.

Any progress on this? It makes really annoying to try and test my REST service running behind CloudFlare. Is there any way for me to manually add the needed ciphers to the acceptance list, or will a patch be necessary? Thanks.

Google appear to be pushing http admins to using ecdhe, aes, !sha1 via shaming techniques on the https green padlock dropdown.  Current Chrome (version 42) calls any connection not using the above cipher suite "obsolete".   Taking the bait and configuring the http server to use only the above 'AES+EECDH:!SHA1' causes problems with curl, yum and dnf.  With google pushing for ecdhe-only on http servers, the number of people effected by this nss behavior is going to rise  quickly.

The server does not implement TLS 1.2, the TLS_RSA_WITH_AES_128_CBC_SHA cipher suite is mandatory to implement (section 9 of RFC 5246) and curl advertises it.  I tried connecting with OpenSSL and only advertising this cipher suite, and the connection failed as well.

Now this is a rather legalistic view.  I agree that newer algorithms should be be available by default.  Rather than working around this in the NSS code (so that it requires updates each time NSS is enhanced), curl could switch to OpenSSL instead.

We have agreed with NSS maintainers that libcurl should not override the set of cipher-suites enabled by default:

https://github.com/bagder/curl/commit/b4f6cd46

... because, if there is a reason to enable a cipher-suite by default in libcurl, the reason usually applies to other libraries/applications linked against NSS, too.  So it is a good idea to maintain the set of enabled cipher-suites at a single place in the system.

I do not like the idea of switching libcurl back to OpenSSL.  We have put a lot of effort to make the NSS support in libcurl stable and feature-complete.  Red Hat is now the main contributor of the NSS support in upstream curl.  If we stop using it, the code will be slowly phased out.

The problem here is whether (and when) we should enable new security algorithms.  It is a political decision.  Clearly, the patch to enable them is trivial.  You just need to convince NSS maintainers that it is a good idea to do that.

The ciphersuites that should be added to the beginning of default list (in order) are:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

(In reply to Kamil Dudka from comment #8)
> 
> I do not like the idea of switching libcurl back to OpenSSL.  We have put a
> lot of effort to make the NSS support in libcurl stable and
> feature-complete.

For the record, it is NOT feature complete. It does not support application-based evaluation of the server's TLS cert in a curl client application, which is a very useful feature of libcurl that allows applications to override the broken/default assumptions of the CA trust model.

(In reply to Scott Cantor from comment #10)

Not something that NSS maintainers will help you with.  Anyway, I believe you are looking for CURLINFO_CERTINFO, which is supported since curl-7.34.0-1.fc21.

(In reply to Kamil Dudka from comment #11)

No, that option is not at all the same. It allows for evaluation of the certificate only after any data is already sent. That's closing the barn door after the proverbial horse has left.

My comment was made to correct a statement of fact in response to the very appropriate suggestion that libcurl should be based on OpenSSL and not NSS, or at the very least supplied in both forms as Debian does.

(In reply to Scott Cantor from comment #12)
> No, that option is not at all the same.

Same as what?

You did not tell us which part of libcurl API you were interested in.

The only option that allows pre-connection access to the credential is the CURLOPT_SSL_CTX_FUNCTION option.

CURLOPT_SSL_CTX_FUNCTION is clearly documented as option specific to a particular SSL library.  Even if we implemented this option in NSS-linked libcurl later on, the API/ABI would be totally incompatible.  Please avoid using the option in any code that is meant to be portable.

(In reply to Scott Cantor from comment #10)
> For the record, it is NOT feature complete. It does not support
> application-based evaluation of the server's TLS cert in a curl client
> application, which is a very useful feature of libcurl that allows
> applications to override the broken/default assumptions of the CA trust
> model.

As far as I know, this broken assumptions in CA trust model were present only in OpenSSL (bug 1166614) and GnuTLS (bug 1142137). They were NOT present in NSS. So using NSS with libcurl actually was a fix for this problem.

If you're referring to some other issue with chain building please point out the bug in question or file a new one.

The broken assumption I'm referring to is that commercial CAs are an appropriate source of trust for anything. My use cases rely on a different trust model that requires use of the CURLOPT_SSL_CTX_FUNCTION feature to implement TLS effectively.

There is no other option. Portability doesn't enter into it, functionality is the issue. libcurl + NSS doesn't have the required features.

This bug illustrates it's broken in other ways. It was a mistake to switch and the change should be reverted in a future version. That's all I really intended to say.

(In reply to Scott Cantor from comment #17)
> There is no other option.

There are many options.  If you properly explain your use case on an appropriate channel, you can get useful advice how to solve it.  Do not expect a solution to your problem on a completely unrelated NSS bug.

No, there aren't options, and I don't have a solution short of getting libcurl shipped again with OpenSSL support. I package it myself into /opt at the moment, and if that's useful to anybody with *this* bug, it's here:

https://build.opensuse.org/package/show/security:shibboleth/curl-openssl

The reason I commented here was because I ran into this particular bug myself, and then saw a claim that the NSS support for libcurl was feature complete, when it is in fact not.

The person who made the suggestion to reverse the libcurl change to correct this issue was entirely correct, and I'm just supporting that suggestion, although the compromise to satisfy everybody is to do what Debian did and ship both libcurl builds with different library names. Then everybody wins, at a cost of some work to maintain a parallel build.

I have looked into that, but it is non-trivial to modify the build to that degree and I haven't had the time to spend on it.

(In reply to Scott Cantor from comment #17)
> The broken assumption I'm referring to is that commercial CAs are an
> appropriate source of trust for anything.

nobody claims that CAs certify trustworthiness of certificate holder

they at most certify identity, and even that has many disclaimers attached

> My use cases rely on a different
> trust model

then please explain what it is

It doesn't really matter what it is (mine happens to be based on explicit key exchange through SAML metadata), what matters is that it's implemented by the application using libcurl. The only way to implement that is CURLOPT_SSL_CTX_FUNCTION. Without that option, or a new, functionally equivalent one, there is no way to override the use of PKIX inherent to these TLS libraries.

(I have a ton of other reasons for requiring OpenSSL so getting that feature out of the NSS-based library wouldn't be the end-all, but it makes it at least a possibility.)

(In reply to Scott Cantor from comment #21)
> It doesn't really matter what it is

It does matter as if the use case is common enough it may be worth implementing it in libcurl itself so that it works with all crypto backends.

> (mine happens to be based on explicit
> key exchange through SAML metadata),

and using self signed X.509 certificates with an application specific certificate database won't work for that why exactly?

> what matters is that it's implemented
> by the application using libcurl. The only way to implement that is
> CURLOPT_SSL_CTX_FUNCTION. Without that option, or a new, functionally
> equivalent one, there is no way to override the use of PKIX inherent to
> these TLS libraries.

you're assuming that NSS and libcurl is unchangeable, that is an incorrect assumption
 
> (I have a ton of other reasons for requiring OpenSSL so getting that feature
> out of the NSS-based library wouldn't be the end-all, but it makes it at
> least a possibility.)

Other people require cryptographic library with FIPS 140-2 certificate with Design Assurance on Level 2. Neither OpenSSL nor GnuTLS provide those. I'm quite sure that adding any missing functionality to NSS will be much easier than redesigning any of those other two libraries to match the requirements of Level 2 design.

So you need to provide a much more concrete arguments than an assurance that you have "ton of other reasons".

(In reply to Hubert Kario from comment #22)
> 
> It does matter as if the use case is common enough it may be worth
> implementing it in libcurl itself so that it works with all crypto backends.

It's not appropriate to be implemented in libcurl, it's not a generalized mechanism that would apply to anybody using an HTTP client. There are many such approaches. Trust doesn't belong in the client itself, in most cases, it's too contextual. The OpenSSL option was provided to allow it to be delegated, which is the best path to take.

> and using self signed X.509 certificates with an application specific
> certificate database won't work for that why exactly?

The information isn't that static (increasingly the model is going to look much more like DNS, which is BTW another use case here, things like DANE) and it isn't even a requirement that there be certificates at all, the public key is often the only relevant part of what the server is offering. It's a complex use case that doesn't reduce to a simple static pile of trust anchors.

> > what matters is that it's implemented
> > by the application using libcurl. The only way to implement that is
> > CURLOPT_SSL_CTX_FUNCTION. Without that option, or a new, functionally
> > equivalent one, there is no way to override the use of PKIX inherent to
> > these TLS libraries.
> 
> you're assuming that NSS and libcurl is unchangeable, that is an incorrect
> assumption

No, I didn't assume that, that's why I said "or a new, functionally equivalent [option]", but the feedback I've gotten over the years is that NSS is incapable of addressing the use case because it doesn't provide a hook for libcurl to do something similar to what it does with OpenSSL. I don't know whether that's true or not.

What I do know is that it's a lot more work involving a lot more people than simply shipping dual libraries would be.

> Other people require cryptographic library with FIPS 140-2 certificate with
> Design Assurance on Level 2. Neither OpenSSL nor GnuTLS provide those. I'm
> quite sure that adding any missing functionality to NSS will be much easier
> than redesigning any of those other two libraries to match the requirements
> of Level 2 design.

I'm sure, but shipping both avoids that work too. The FIPS issue, as much as I think it's a joke, is the biggest reason I didn't really raise a fuss years ago when this transition in RH6 took place. I knew there were business reasons that trumped "you just broke some people's applications".

> So you need to provide a much more concrete arguments than an assurance that
> you have "ton of other reasons".

No, what I meant was that even if libcurl on NSS supported the functionality, I would have other constraints that would take a while to work out to ever drop OpenSSL, but that's my problem/limitation to deal with. That's why as a tactical matter, shipping both is a better thing for me, but as a matter of strategy, I think supporting the equivalent of CURLOPT_SSL_CTX_FUNCTION would make the claim that the NSS version is feature complete a lot more accurate.

*** Bug 1248829 has been marked as a duplicate of this bug. ***

Is there (In reply to Daniel Miranda from comment #5)
> Any progress on this? It makes really annoying to try and test my REST
> service running behind CloudFlare. Is there any way for me to manually add
> the needed ciphers to the acceptance list, or will a patch be necessary?
> Thanks.

Is there any progress on this bug?  Is there a way to force it for libcurl?

Yes, there is progress. Enabling of ECC cipher-suites by default is currently under test by Red Hat. It's targeted for the next RHEL-7 y-stream release (RHEL-7.2) and we have submitted a subset of the patches upstream. I'll be bringing this to fedora once we have positive feedback from Red Hat QE. Hopefully, it won't take too long.

(In reply to Josh Cogliati from comment #25)
> Is there a way to force it for libcurl?

Please have a look at the --ciphers option of curl.  It takes a comma-separated list of cipher-suites to be enabled.  You can see the list of supported values directly in the code:

https://github.com/bagder/curl/blob/master/lib/vtls/nss.c#L163

... or in the documentation (referenced from curl man page):

https://git.fedorahosted.org/cgit/mod_nss.git/plain/docs/mod_nss.html#Directives

Testing on main architectures looks good, I think we can go forward with Fedora packages.

(In reply to Kamil Dudka from comment #27)
> (In reply to Josh Cogliati from comment #25)
> > Is there a way to force it for libcurl?
> 
> Please have a look at the --ciphers option of curl.  It takes a
> comma-separated list of cipher-suites to be enabled.  

Is there anyway to do this for libcurl?  The problem for me is that dnf calls libcurl directly instead of running the curl command?

(In reply to Josh Cogliati from comment #29)
> Is there anyway to do this for libcurl?  The problem for me is that dnf
> calls libcurl directly instead of running the curl command?

Sorry for the misleading answer!  An equivalent option also exists in libcurl API:

http://curl.haxx.se/libcurl/c/CURLOPT_SSL_CIPHER_LIST.html

... and is exposed by pycurl API as pycurl.SSL_CIPHER_LIST.  Both of them expect a string in the same format as the --ciphers option of curl.

(In reply to Josh Cogliati from comment #29)
> Is there anyway to do this for libcurl?  The problem for me is that dnf
> calls libcurl directly instead of running the curl command?

Please don't do this, from the documentation Kamil provides:

“
For NSS, valid examples of cipher lists include 'rsa_rc4_128_md5', ´rsa_aes_128_sha´, etc. With NSS you don't add/remove ciphers. If one uses this option then all known ciphers are disabled and only those passed in are enabled. 
”

This means that you would have to maintain the TLS policy inside dnf to large extent, and this is not the right place because as a result, we have to patch dnf in case any of the ciphers it selects turns bad.

This really has to be fixed in NSS.

(In reply to Florian Weimer from comment #31)
> This really has to be fixed in NSS.

I fully agree on this.  I did not mean to hard-wire any list of cipher-suites into dnf.  On the other hand, it would be good if dnf provided more options to configure TLS (at least the version of TLS) for accessing package repositories.  Users should be able to override the default settings if something goes wrong.

or to be able to move ahead of the curve: disable anything but TLS1.2 and anything but ECDHE with AESGCM

but that will likely be solved by bug 1157720

Created attachment 1073824 [details]
enable ecc cipher suites by default

Created attachment 1073826 [details]
Adds "-c v " to tstclient invocation for ocsp stapling tests and some SNI tests.

Created attachment 1073872 [details]
spec file changes rawhide - in patch format

Comment on attachment 1073824 [details]
enable ecc cipher suites by default

r+ rrelyea

Comment on attachment 1073826 [details]
Adds "-c v " to tstclient invocation for ocsp stapling tests and some SNI tests.

r+, though upstream lets just add it to all the SNI tests (even ones that don't include SNI requests).

Comment on attachment 1073872 [details]
spec file changes rawhide - in patch format

r+ rrelyea

Comment on attachment 1073824 [details]
enable ecc cipher suites by default

You've missed TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

Also, I don't think we want to enable TLS_ECDHE_ECDSA_WITH_RC4_128_SHA.

TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 is also unrelated to the bug

And we definitely don't want to enable TLS_ECDH_* by default

(In reply to Hubert Kario from comment #40)
> You've missed TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Yes, these are the most preferred ciphers.

> Also, I don't think we want to enable TLS_ECDHE_ECDSA_WITH_RC4_128_SHA.
No we don't.

> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 is also unrelated to the bug
Yes

> And we definitely don't want to enable TLS_ECDH_* by default
Agree, and comparing I see that's I didn't for RHEL-7.

Thank you.

Created attachment 1074081 [details]
enable ecc cipher suites by default - V2

Implements the review changes as requested in Comment 40.

Comment on attachment 1074081 [details]
enable ecc cipher suites by default - V2

r+

Should TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA and TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA actually be enabled by default?  (As in is that intentional to enable a triple DES cipher?)

it's no less secure than the 2048 bit RSA certificates that "everybody" is using, so it doesn't hurt

for most NSS servers it's also the only PFS ciphersuite they support (as DHE needs to be enabled manually and most applications don't have that knob just yet)

*** Bug 1267193 has been marked as a duplicate of this bug. ***

When is this bug going to be fixed in the main versions of the packages?

I have been getting the version from koji and they work beautifully for fixing the problem I encountered,
https://koji.fedoraproject.org/koji/packageinfo?packageID=248
but it would be nice if this was in the regular updates.

Thanks.

(In reply to Josh Cogliati from comment #47)
> When is this bug going to be fixed in the main versions of the packages?

I believe this is going to be fixed by the update of nss packages currently available in testing.  Elio, did you forget to reference this bug in Bodhi?

> I believe this is going to be fixed by the update of nss packages currently
> available in testing.  Elio, did you forget to reference this bug in Bodhi?

Yes, an urgent update to nss-3.20.0 driven by Firefox came up and absorbed all of my attention. I'll reference it in the nss-3.21.0 update that is coming soon  which has some it from upstream and part of it as a local patch. You can test it now with the nss-3.20.1 currently in testing.

This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

with nss-3.20.0-1.2.fc22.x86_64 it is partially fixed, following ciphers are advertised:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA


but following are still missing:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

(In reply to Hubert Kario from comment #51)
...
> 
> 
> but following are still missing:
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

I confirm that the reason they are missing is that they were not included in   attachment 1074081 [details] which I downloaded and grepped for them on it and

grep TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 ~/Downloads/enable-ecc-ciphers-by-default.patch
grep TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 ~/Downloads/enable-ecc-ciphers-by-default.patch
grep TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ~/Downloads/enable-ecc-ciphers-by-default.patch
grep TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ~/Downloads/enable-ecc-ciphers-by-default.patch

shows nothing. 

I should mention that since then I split the patch in two, one part matches what was approved upstream and the other what want not but we still want for fedora. 

I also checked with what we have on RHEL-7.2 and they are present there, only some enabled. 

There on nss/lib/ssl I see:
$ grep TLS_ECDHE_ECDSA_WITH_AES ssl3con.c | grep PR_ | grep "PR_TRUE, PR_FALSE"
 { TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, SSL_ALLOWED, PR_TRUE, PR_FALSE},
 { TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,    SSL_ALLOWED, PR_TRUE, PR_FALSE},
 { TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, SSL_ALLOWED, PR_TRUE, PR_FALSE},
 { TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,    SSL_ALLOWED, PR_TRUE, PR_FALSE},

$ grep TLS_ECDHE_ECDSA_WITH_AES ssl3con.c | grep PR_ | grep "PR_FALSE, PR_FALSE"
 { TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, SSL_ALLOWED, PR_FALSE, PR_FALSE},
 { TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, SSL_ALLOWED, PR_FALSE, PR_FALSE},

The ones with GCM are enabled by default but the CBC ones aren't. That's not surprising.

Currently I'm working on the rebase to nss-3.21 per Bug 1279912. As you can see in https://bugzilla.redhat.com/show_bug.cgi?id=1279912 this particlar rebase takes more work than the typical one for fedora updates and on top has other bug fixes along with it.

This bug will takes a bit of care as well so I propose completing its work after the rebase is done. Are you okay with this?

yes, as we talked about the RHEL - the CBC ciphers with SHA-256 and SHA-384 HMAC don't need to be enabled

but lack of GCM ciphers is suboptimal

that being said, 3.21 release has higher priority

(In reply to Elio Maldonado Batiz from comment #52)
> (In reply to Hubert Kario from comment #51)
> ...
> > 
> > 
> > but following are still missing:
> > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> 

Looking at this more carefully the reason they are missing is that they are the new _SHA384 ciphers to support TLS 1.2 PRF with SHA-384 as the hash function https://bugzilla.mozilla.org/show_bug.cgi?id=923089 and which is still under review upstream. We must wait for upstream to get this other ones in fedora. The original request to "enable ECC cipher-suites by default" was meant for existing cipher suites.

> (In reply to Elio Maldonado Batiz from comment #52)
> > (In reply to Hubert Kario from comment #51)
> > ...
> > > 
> > > 
> > > but following are still missing:
> > > TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
> > > TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> > > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> > > TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Moreover, on Fedora 23 I am missing:

AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
DHE-DSS-AES256-GCM-SHA384

I run across this bug while researching the error message "Could not initialize nss: The certificate/key database is in an old, unsupported format." that I got when I tried to compile a custom kernel.
I followed the directions given on: https://fedoraproject.org/wiki/Building_a_custom_kernel

Command line:
rpmbuild -bb --with baseonly --without debuginfo --target="$(uname -m)" kernel.spec

Kernel configuration included:
CONFIG_MODULE_SIG=y
CONFIG_MODULE_SIG_FORCE=y
CONFIG_MODULE_SIG_ALL=y
CONFIG_MODULE_SIG_SHA512=y
CONFIG_MODULE_SIG_HASH="sha512"

Last lines of rpmbuild output (sorry for the Italian localization):

+ dd if=/dev/zero of=/home/tecnico/rpmbuild/BUILDROOT/kernel-4.2.8-300.fabhaya0.fc23.x86_64/boot/initramfs-4.2.8-300.fabhaya0.fc23.x86_64.img bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 0.10387 s, 202 MB/s
+ '[' -f arch/x86_64/boot/zImage.stub ']'
+ '[' -x /usr/bin/pesign ']'
+ '[' x86_64 == x86_64 -o x86_64 == aarch64 ']'
+ '[' 0 -ge 7 -a -f /usr/bin/rpm-sign ']'
+ '[' -S /var/run/pesign/socket ']'
+ /usr/bin/pesign -c 'Red Hat Test Certificate' -i arch/x86/boot/bzImage -o vmlinuz.signed -s
Could not initialize nss: The certificate/key database is in an old, unsupported format.
errore: Stato d'uscita errato da /var/tmp/rpm-tmp.RZPtYz (%build)

Errori di compilazione RPM:
    Stato d'uscita errato da /var/tmp/rpm-tmp.RZPtYz (%build)


Last lines mean:
error: Wrong exit status from /var/tmp/rpm-tmp.RZPtYz (%build)
RPM compilation error:
    Wrong exit status from /var/tmp/rpm-tmp.RZPtYz (%build)


I enclose the /var/tmp/rpm-tmp.RZPtYz file.

Is this another symptom of the same issue that is discussed in this bug? Or should it be filed as a different bug?

Sorry, forgot to add these informations:
lsb_release -d ; uname -r
Description:    Fedora release 23 (Twenty Three)
4.2.8-300.fc23.x86_64

Created attachment 1109202 [details]
rpmbuild -bb produced file

File produced by rpmbuild -bb --with baseonly --without debuginfo --target="$(uname -m)" kernel.spec

This:

> "Could not initialize nss: The certificate/key database is in an old, unsupported format." 

is completely unrelated to the subject:

> NSS does not enable ECC cipher-suites by default

Alessandro, please open a new bug request for the issue you're facing.

nss-util-3.22.0-1.0.fc23 nss-softokn-3.22.0-1.0.fc23 nss-3.22.0-1.0.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-53890487b0

nspr-4.11.0-1.fc23, nss-3.22.0-1.0.fc23, nss-softokn-3.22.0-1.0.fc23, nss-util-3.22.0-1.0.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-53890487b0

nspr-4.11.0-1.fc23, nss-3.22.0-1.0.fc23, nss-softokn-3.22.0-1.0.fc23, nss-util-3.22.0-1.0.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

nspr-4.11.0-1.fc22, nss-3.22.0-1.0.fc22, nss-softokn-3.22.0-1.0.fc22, nss-util-3.22.0-1.0.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-2f0441bc7b

nspr-4.11.0-1.fc22, nss-3.22.0-1.0.fc22, nss-softokn-3.22.0-1.0.fc22, nss-util-3.22.0-1.0.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.