This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 1019390 - (ecc) [tracking bug] re-enable ECC/ECDHE/EC/ECDSA/elliptic curves in Fedora
[tracking bug] re-enable ECC/ECDHE/EC/ECDSA/elliptic curves in Fedora
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
unspecified Severity medium
: ---
: ---
Assigned To: Radek Vokal
Radek Vokal
: Tracking
Depends On: 1038683 319901 615372 752980 999078 1012272 1019126 1019216 1019222 1019244 1019245 1019247 1019249 1019251 1019253 1019254 1019256 1019259 1019312 1019333 1019337 1019449 1019553 1019554 1021897 1021898 1023017 1025882 1033370 1064149 1067697
Blocks: 1020446
  Show dependency treegraph
 
Reported: 2013-10-15 11:30 EDT by Bill McGonigle
Modified: 2016-04-01 10:08 EDT (History)
39 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-02-28 11:55:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Bill McGonigle 2013-10-15 11:30:51 EDT
now that bug 319901 is resolved, we need to systematically re-enable elliptic curves in each Fedora package that has them disabled.

This bug exists to utilize Bugzilla's tracking tools to keep a list of the state of each of the required changes and to help make sure we don't miss any.

Please file a separate bug for each package that needs changing, and set it block this bug.  Please set a unique Summary line for each package's bug so the tracking tools here are useful.

Please do not use this bug to discuss issues that can be more appropriately discussed on a bug for a particular package.
Comment 1 Tom "spot" Callaway 2013-10-15 18:53:52 EDT
Also, please be patient. This needs to be done carefully and any ECC related change needs to be cleared first. Should not take six years. :)
Comment 2 Harald Reindl 2013-10-21 17:35:59 EDT
the "only ECC NIST Suite B curves support" seems to cripple down openssl again
with "openssl-1.0.1e-4.fc18.1" all fine over days and starting with "openssl-1.0.1e-28.fc18" a few messages like below in maillog and lead to fall back to a unecnrypted connection (yes postfix was rebuilt against the new SSL build)

Oct 21 20:26:44 mail postfix/smtp[2217]: warning: TLS library problem: 2217:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:17:45 mail postfix/smtp[7226]: warning: TLS library problem: 7226:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:20:04 mail postfix/smtp[7411]: warning: TLS library problem: 7411:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:46:17 mail postfix/smtp[9202]: warning: TLS library problem: 9202:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:55:33 mail postfix/smtp[9799]: warning: TLS library problem: 9799:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:58:54 mail postfix/smtp[10007]: warning: TLS library problem: 10007:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 22:29:22 mail postfix/smtp[12293]: warning: TLS library problem: 12293:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
______________________________________________

result of "only ECC NIST Suite B curves support" followed by "relay=mx00.gmx.net[213.165.67.114]:2" unencrypted

Oct 21 21:55:33 mail postfix/smtp[9799]: SSL_connect error to mx00.gmx.net[213.165.67.114]:25: -1
Oct 21 21:55:33 mail postfix/smtp[9799]: warning: TLS library problem: 9799:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 21:55:33 mail postfix/smtp[9799]: warning: TLS library problem: 9799:error:1408D010:SSL routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
Oct 21 21:55:33 mail postfix/smtp[9799]: 3d3T9G66cmz23: Cannot start TLS: handshake failure
Oct 21 21:55:33 mail postfix/smtp[9799]: Host offered STARTTLS: [mx00.gmx.net]


Oct 21 22:29:22 mail postfix/smtp[12289]: SSL_connect error to mx00.gmx.net[213.165.67.99]:25: -1
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 21 22:29:22 mail postfix/smtp[12289]: warning: TLS library problem: 12289:error:1408D010:SSL routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
Oct 21 22:29:22 mail postfix/smtp[12289]: 3d3Tvy5Cdsz23: Cannot start TLS: handshake failure
Comment 3 Harald Reindl 2013-10-21 17:39:42 EDT
as you clearly can see before the update all was fine

Oct 21 20:16:43 Updated: 1:openssl-libs-1.0.1e-28.fc18.x86_64
__________________________________

Oct 21 19:59:48 mail postfix/smtp[17217]: Trusted TLS connection established to mx00.gmx.net[213.165.67.99]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 21 20:07:16 mail postfix/smtp[1687]: Trusted TLS connection established to mx00.gmx.net[213.165.67.114]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 21 20:15:02 mail postfix/smtp[3036]: Trusted TLS connection established to mx00.gmx.net[213.165.67.114]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Comment 4 Tom "spot" Callaway 2013-10-21 18:12:36 EDT
Hmm. When I look at the cipher list in the latest openssl (run: openssl ciphers), I see:

ECDHE-RSA-AES256-GCM-SHA384

I'm not sure why postfix doesn't pick it up. If you hadn't already said you rebuilt postfix against the latest openssl, I'd suggest trying that. :/ 

Might need to file a separate bug against openssl directly.
Comment 5 Harald Reindl 2013-10-21 18:22:12 EDT
who file? you or me?
the change was yours :-)

verified 100% for sure, tried with the original ECDHE-supporting openssl 
again and it delivers like a charme to the same GMX host

here you go: http://marc.info/?l=postfix-users&m=138239029006207&w=2
Comment 6 Scott Schmit 2013-10-21 20:56:41 EDT
Well, both ends can support ECDH and not agree on the curve to use. Curves are negotiable too, but both ends must implement the right extensions, IIUC.
Comment 7 Harald Reindl 2013-10-21 21:17:06 EDT
but what to do?

until the last change god bless ECDHE worked like a charme
i rebuilt postfix/dovecot/httpd on the same day it was available 
there was no single issue with the first ECDHE-enabled openssl build
Comment 8 Patrick 2013-10-21 22:12:19 EDT
Quoting from the postfix mailing list at http://archives.neohapsis.com/archives/postfix/2013-10/0462.html

"The author of comment #4 is not getting it.  The problem is NOT
that Postfix fails to negotiate EECDH, rather the problem is that
it does!  Once EECDH is negotiated, the server (gmx) selects an
unsupported (by RedHat's crippled OpenSSL) curve and the handshake
fails."

So doesn't that mean that for EECDH to work the openssl-1.0.1e-speed-suiteb.patch needs to be reverted?

For completeness here are the ones disabled by that patch:

ecdsap160, ecdsab163, ecdsap192, ecdsap224, eecdsab233, ecdsab283, ecdsab409, ecdsap521

ecdsak163, ecdsak233, ecdsak283, ecdsak409, ecdsak571

ecdhp160, ecdhp192, ecdhp224, ecdhp521
 
ecdhk163, ecdhk233, ecdhk283, ecdhk409, ecdhk571

ecdhb163, ecdhb233, ecdhb283, ecdhb409, ecdhb571
Comment 9 Scott Schmit 2013-10-21 22:41:46 EDT
Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4), there is either a bug in the server or the client isn't offering the extension advertising the curves it supports. You need to get the protocol message trace in order to determine which.  If it's client-side, the bug is (probably) against postfix. If you want openssl to support more curves, you should file a new bug.

As mentioned in comment #0:
> Please do not use this bug to discuss issues that can be more appropriately
> discussed on a bug for a particular package.
Comment 10 Tom "spot" Callaway 2013-10-22 04:14:30 EDT
(In reply to Scott Schmit from comment #9)
> Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4), there is
> either a bug in the server or the client isn't offering the extension
> advertising the curves it supports. You need to get the protocol message
> trace in order to determine which.  If it's client-side, the bug is
> (probably) against postfix. If you want openssl to support more curves, you
> should file a new bug.

Indeed. If there is a specific curve that is needed, it would be generally helpful to know which one (and why).
Comment 11 Harald Reindl 2013-10-22 04:24:19 EDT
well, someone with debug-knowledge could register a freemail address at https://registrierung.gmx.net/

Oct 22 10:16:29 mail postfix/smtp[13476]: warning: TLS library problem: 13476:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:ec_curve.c:316:
Oct 22 10:16:29 mail postfix/smtp[13476]: warning: TLS library problem: 13476:error:1408D010:SSL routines:SSL3_GET_KEY_EXCHANGE:EC lib:s3_clnt.c:1641:
Oct 22 10:16:29 mail postfix/smtp[13476]: 3d3nc82yyrz2k: Cannot start TLS: handshake failure
Oct 22 10:16:30 mail postfix/smtp[13476]: Host offered STARTTLS: [mx01.gmx.net]
Comment 12 Michael J Gruber 2013-10-22 04:38:22 EDT
On the other other hand, a slightly more detailed explanation than

only ECC NIST Suite B curves support
- drop -fips subpackage 

in the commit http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=b3551463cafee86a63c60e294f754a8c5cddc37a that triggered this would be generally helpful, too. I.a.W.: Say "why", not just "what" in your commit message. And that diff is large for just removing something, and even has large additions.

Of course, using tags so that one can associate package versions with commits more easily would be generally helpful, too. At least that info is in the spec diff.

But we should take this whole discussion to an openssl bug.
Comment 13 Harald Reindl 2013-10-22 04:38:59 EDT
well, that guy is the maintainer of the postfix SSL/TLS code

http://marc.info/?l=postfix-users&m=138240935211163&w=2

> I can't connect to gmx's SMTP servers on port 25 from my laptop
> since I am on a residential dynamic IP.  On port 587 however, I
> can definitely confirm that [smtp.gmx.de]:587 is using secp521r1,
> which is one of the curves removed by RedHat.  It seems likely
> that they do the same on port 25

http://marc.info/?l=postfix-users&m=138242211613713&w=2

    ---
    Reading RFC 4492 (https://tools.ietf.org/html/rfc4492#section-4),
    there is either a bug in the server or the client isn't offering
    the extension advertising the curves it supports. 
    ---

* Firstly, client TLS extensions are not possible when the client starts
  with an SSLv2 compatible SSL HELLO.  So the list of supported curves
  is not sent by clients that are backwards compatible with SSLv2 (though
  of course by now SSLv2 should be disabled in most clients).

* Secondly, the OpenSSL server API does not expose the client's
  supported EC curves to the server application which is expected
  to configure the EECDH curve.  Thus the extension from RFC 4492
  is almost never used, most servers choose the EECDH curve blindly.

* Auto-configuration of the server curve (in response to client
  extensions) is coming in OpenSSL 1.0.2 which is not yet released!
Comment 14 Gregory Maxwell 2013-10-22 05:00:28 EDT
Greetings.

We'd like to have the secp256k1 curve included because it is a requirement for the Bitcoin software.

secp256k1 a curve with fully rigid parameters (in DJB's parlance: http://safecurves.cr.yp.to/rigid.html, meaning there is no substantial author side freedom to choose curves with secret weaknesses) over a prime field (e.g. it is not a characteristic-2 curve, which have had some specific patent issues in the past).

Like other fully rigid curves secp256k1 supports certain high speed implementations (and this, combined with security constraints is what fixes the curve parameters in a fully rigid curve selection), but OpenSSL does not implement any of these fancy performance enhancements and uses curve generic code for them.

Cheers.
Comment 15 Cesar Eduardo Barros 2013-10-26 08:38:29 EDT
The postfix issue might have been fixed by bug 1022493.
Comment 16 Harald Reindl 2013-10-26 09:16:41 EDT
confirmed: postfix/smtp[13130]: Trusted TLS connection established to mx01.gmx.net[213.165.67.97]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Comment 17 Wolfgang Rupprecht 2013-11-01 15:40:56 EDT
lighttpd (an alternate web server) also needs a recompile.  Whoever has the template that is opening the specific bugs might want to open one for lighttpd too.
Comment 18 Harald Reindl 2013-11-01 15:45:47 EDT
> Whoever has the template that is opening the specific bugs 
> might want to open one for lighttpd too.

well, no template needed, simply open a bug is enough
here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1025882
Comment 19 Cesar Eduardo Barros 2013-11-01 18:05:28 EDT
(In reply to Harald Reindl from comment #18)
> > Whoever has the template that is opening the specific bugs 
> > might want to open one for lighttpd too.
> 
> well, no template needed, simply open a bug is enough
> here we go: https://bugzilla.redhat.com/show_bug.cgi?id=1025882

It must also block this bug. It might also need to CC tcallawa, but I am not sure about that, and he already receives enough bugspam just from this tracking bug ;-)
Comment 20 Sergio Monteiro Basto 2014-01-09 15:32:58 EST
Hi, about bug #1012272,  since we haven't disable it, is already enabled so we can close the bug ?
Comment 21 Hubert Kario 2014-01-10 06:28:36 EST
(In reply to Sergio Monteiro Basto from comment #20)
> Hi, about bug #1012272,  since we haven't disable it, is already enabled so
> we can close the bug ?

yes, it can be closed as NOTABUG
Comment 24 Ilari Stenroth 2015-01-31 17:15:46 EST
Please consider #1064149.
Comment 25 Sergio Monteiro Basto 2015-12-13 22:25:31 EST
Hello , 

openssl ecparam -list_curves

secp256k1 : SECG curve over a 256 bit prime field
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field

So openssl just enabled 4 of 81 elliptic curve cryptography that are available on openssl (without hobble-openssl ) 

I'd like require enable sect233k1  NIST/SECG/WTLS curve over a 233 bit binary field which is the default for secg.org TLS test server, according 
M2Crypto-0.22.5/M2Crypto/EC.py file .
Comment 26 Tomas Mraz 2015-12-14 04:55:01 EST
The security of the binary curves is disputed and I do not like reenabling them.
Comment 27 Neal Gompa 2015-12-17 01:16:34 EST
@Tomas: How are they disputed?
Comment 28 Tomas Mraz 2015-12-17 03:21:41 EST
See for example here:
https://www.quora.com/What-are-the-advantages-of-elliptic-curve-cryptography-using-binary-fields-over-prime-fields-and-vice-versa?share=1

Also note that openssl upstream wants to remove the binary field curves from the default set in the 1.1.0 branch. It does not mean that the support for binary field curves will be removed, just it won't be in the default supported set for TLS anymore.
Comment 29 Neal Gompa 2016-01-06 22:36:41 EST
Tomas,

I'm not sure if that necessarily means you shouldn't enable them. There has not yet been a provable case where you could definitively break those curves. Honestly, I would err on the side of making the curves available simply because upstream offers them.

Hobbling it like this is not helpful or useful to others who may want or need these curves.

It's up to you, of course, but I would strongly suggest that unless there's definitively a good reason to disable them, you should allow them to be usable in Fedora.
Comment 30 Sergio Monteiro Basto 2016-01-26 10:41:48 EST
Hi,
from (#1067697) many EC aren't enable , but first we need to know what elliptic curves are legal and what elliptic curves are not legal. 
Tomas Mraz wrote : AFAIK there is no blank approval for any elliptic curves by legal anyway.

Meanwhile I built openssl unhobble , my work is here [1] I had test it since Dez 14 2015 , I added openssl-fips-2.0.10.tar.gz . my openssl.spec is in a draft state and of course needs many clean ups.

But the main propose of this comment is to know what elliptic curves could be enabled by FE-Legal, should we block FE-Legal bug tracker ?  

[1] https://github.com/sergiomb2/openssl
Comment 31 Tom "spot" Callaway 2016-01-26 11:40:59 EST
With regards to OpenSSL, the curves which are currently enabled are the ones which have been cleared by legal. Any disabled curves are disabled intentionally.
Comment 32 Peter Lemenkov 2016-02-28 09:35:15 EST
All blocking bugs are closed - shall we close this ticket as well now?
Comment 33 Bill McGonigle 2016-02-28 11:55:51 EST
Looks like the last dependency bug marked 'RAWHIDE' has the code in f23, so closing 'CURRENTRELEASE'.

Thanks, everybody (especially Spot) - great work all around!
Comment 34 Neal Gompa 2016-03-02 01:04:03 EST
Err, isn't this supposed to remain open in the event more disabled curves are requested to be opened?
Comment 35 Bill McGonigle 2016-03-02 12:54:49 EST
Neal, I think we've fixed "Fedora doesn't permit ECC".  If you create a tracking bug for enabling additional curves, I'd love to be on the CC:.

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