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.
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. :)
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
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)
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.
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
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.
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
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
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.
(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).
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]
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.
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!
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.
The postfix issue might have been fixed by bug 1022493.
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)
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.
> 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
(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 ;-)
Hi, about bug #1012272, since we haven't disable it, is already enabled so we can close the bug ?
(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
Please consider #1064149.
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 .
The security of the binary curves is disputed and I do not like reenabling them.
@Tomas: How are they disputed?
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.
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.
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
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.
All blocking bugs are closed - shall we close this ticket as well now?
Looks like the last dependency bug marked 'RAWHIDE' has the code in f23, so closing 'CURRENTRELEASE'. Thanks, everybody (especially Spot) - great work all around!
Err, isn't this supposed to remain open in the event more disabled curves are requested to be opened?
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:.