Bug 319901 - missing ec and ecparam commands in openssl package
Summary: missing ec and ecparam commands in openssl package
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: openssl
Version: rawhide
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 612265 796508 894009 (view as bug list)
Depends On:
Blocks: FE-Legal 990423 1012269 ecc 1020292
TreeView+ depends on / blocked
 
Reported: 2007-10-05 09:29 UTC by Thibault LE MEUR
Modified: 2014-01-09 00:13 UTC (History)
77 users (show)

Fixed In Version: openssl-1.0.1e-28.fc20
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-22 09:33:10 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
verified by https://www.ssllabs.com/ssltest/ (160.64 KB, image/png)
2013-10-15 22:07 UTC, Harald Reindl
no flags Details

Description Thibault LE MEUR 2007-10-05 09:29:58 UTC
Description of problem:

the openssl 0.9.8b package doesn't support the 'ec' and 'ecparam' commands
though the 'man ec' and 'man ecparam' describe them.

These commands were introduced in 0.9.8 abnd should be vailable.

Version-Release number of selected component (if applicable):
Issue occurs with package:
openssl.i686      0.9.8b-14.fc7

How reproducible:
Always

Steps to Reproduce:
1. 'man ec' or 'man ecparam' shows the man page
2. 'openssl ec'
3. 'openssl ecparam'
  
Actual results:
1- shows the ec man page or the ecparam man page
2- 'openssl:Error: 'ec' is an invalid command.'
3- 'openssl:Error: 'ecparam' is an invalid command.'

Comment 1 Thibault LE MEUR 2007-10-05 09:42:41 UTC
I had a look at the package and found the following Configure line:
./Configure \
        --prefix=%{_prefix} --openssldir=%{_sysconfdir}/pki/tls ${sslflags} \
        zlib no-idea no-mdc2 no-rc5 no-ec no-ecdh no-ecdsa shared \
        --with-krb5-flavor=MIT --enginesdir=%{_libdir}/openssl/engines \
        -I%{_prefix}/kerberos/include -L%{_prefix}/kerberos/%{_lib} \
        ${sslarch}

So the -no-ec and -no-ecdsa seem to be responsible for the lack of ecparam and
ec commands.

Why are they disabled by default ?

If this is intended and won't be fixed, maybe the related man page should be
removed from the package or better updated to say that they are not supported by
the installed package ?

Comments ?

Comment 2 Tomas Mraz 2007-10-05 10:23:00 UTC
They are intentionally removed due to possible patent issues.


Comment 3 Bill Nottingham 2012-02-08 19:06:07 UTC
*** Bug 612265 has been marked as a duplicate of this bug. ***

Comment 4 Tomas Mraz 2012-02-27 09:04:25 UTC
*** Bug 796508 has been marked as a duplicate of this bug. ***

Comment 5 Rudd-O DragonFear 2012-03-15 23:11:57 UTC
Well this is crap.  Now I can't use Bitcoin.

Comment 6 Valent Turkovic 2012-04-09 20:20:32 UTC
Any news from Fedora Legal?

Tribler developers clain that there is no patent on EC technology:
http://forum.tribler.org/viewtopic.php?f=2&t=1848

And also Ubuntu is using EC in their versions of openssl.

Maybe Ubuntu and Redhat Legal should have a chat regarding this issue?

Comment 7 Joe Julian 2012-04-19 08:02:36 UTC
Since this was closed before the IETF findings were released (http://www.rfc-editor.org/rfc/rfc6090.txt), could we get this reopened and looked at by legal again please?

Comment 8 Peter Lemenkov 2012-06-04 08:52:13 UTC
Ok, let's ask FE-Legal again (but I'm afraid things won't change dramatically).

Comment 9 Tom "spot" Callaway 2012-06-04 17:55:47 UTC
Please note: "Ubuntu does it" is never a viable legal argument.

I have a standing request to revisit this issue with Red Hat Legal, however, I do not think this blocker will be lifted anytime soon.

Comment 10 Rudd-O DragonFear 2012-06-05 22:23:12 UTC
Hopefully this gets sorted out soon.  Without this, it's nigh impossible to compile Bitcoin (my most perentory issue) and many other applications, unless separate directories for a separate OpenSSL build (HARD to build, the mofo) are compiled first.

Comment 11 Rudd-O DragonFear 2012-06-05 22:23:32 UTC
In fact this is the only reason why Bitcoin cannot be packaged for Fedora.

Comment 12 kano 2012-06-07 07:56:33 UTC
Re Comment 11 ...
How to build it while waiting the 7+ years this has been outstanding :)
https://bitcointalk.org/index.php?topic=85228.msg946289#msg946289

Comment 13 Valent Turkovic 2012-07-25 11:13:14 UTC
Who has made contact with Fedora Legal? Has there been any response?

Comment 14 Valent Turkovic 2012-07-25 11:14:38 UTC
If nobody has made contact so far, what is the proper action? Should I post request to Fedora Legal mailing list regarding this issue? Will they respond to "anonymous" request or does it have to come from some prominent Fedora member?

Comment 15 Tom "spot" Callaway 2012-07-25 13:42:41 UTC
Believe me, I'm well aware of this issue. If/when there are updates to this situation, I will update this bug.

Comment 16 Rudd-O DragonFear 2012-07-25 16:55:56 UTC
Sometimes it feels like making contact with Fedora Legal requires the SETI Project :-D

Comment 17 Tom "spot" Callaway 2012-07-25 17:09:16 UTC
(In reply to comment #16)
> Sometimes it feels like making contact with Fedora Legal requires the SETI
> Project :-D

Not so. All you have to do is block a bug against FE-Legal

OR

email the mailing list <legal.org>

OR

email them directly <legal>

Proper legal review, especially on complicated issues, takes a long time. We'd rather get it right than put Red Hat at risk.

Comment 18 m. pholic 2012-09-10 00:21:11 UTC
So you're telling me that some random lawyer's decision is preventing me from generating an SSH key required to do my job?

Classic.

Comment 19 Rudd-O DragonFear 2012-09-14 07:38:32 UTC
Trollawyers.

Comment 20 Peter Lemenkov 2012-09-14 07:56:00 UTC
(In reply to comment #18)
> So you're telling me that some random lawyer's decision is preventing me
> from generating an SSH key required to do my job?
> 
> Classic.

Short answer is yes. Btw you really should tell your deputy/senator your opinion regarding software patents.

Comment 21 Rudd-O DragonFear 2012-09-17 03:26:39 UTC
I'm not telling any of those mafioso scammers anything.  First, I don't grovel to criminals, and second, it's not like they give a shit about what proletarians like us think.  They respond to $, not to letters.

Comment 22 Tomas Mraz 2013-01-10 14:54:15 UTC
*** Bug 894009 has been marked as a duplicate of this bug. ***

Comment 23 Mikhail 2013-01-11 09:08:05 UTC
Fedora 18, trying build openSSL with GOST etc.

1) Downloaded full openSSL
wget http://www.openssl.org/source/openssl-1.0.1c.tar.gz
2) change in spec
 30:  Source: openssl-%{version}.tar.gz
3) enable ec
228:  enable-cms enable-md2 no-mdc2 no-rc5 enable-ec no-ec2m enable-ecdh enable-ecdsa no-srp \
4) remark Source1
 31:   #Source1: hobble-openssl
142:   #%{SOURCE1} > /dev/null
5) Increase number realize
 24:  Release: 8%{?dist}
Run building
rpmbuild -bb ~/rpmbuild/SPECS/openssl.spec 


Building stopped with errors:
make[2]: Entering directory `/home/mikhail/rpmbuild/BUILD/openssl-1.0.1c/apps'
../libcrypto.so: undefined reference to `FIPS_ecdsa_openssl'
../libcrypto.so: undefined reference to `FIPS_ec_key_generate_key'
../libcrypto.so: undefined reference to `FIPS_ecdh_openssl'
../libcrypto.so: undefined reference to `fips_ec_gfp_nist_method'
../libssl.so: undefined reference to `EVP_ecdsa'
../libcrypto.so: undefined reference to `fips_ec_gfp_mont_method'
../libcrypto.so: undefined reference to `fips_ec_gfp_simple_method'
collect2: error: ld returned 1 exit status
make[2]: *** [link_app.gnu] Error 1
make[2]: Leaving directory `/home/mikhail/rpmbuild/BUILD/openssl-1.0.1c/apps'
make[1]: *** [openssl] Error 2
make[1]: Leaving directory `/home/mikhail/rpmbuild/BUILD/openssl-1.0.1c/apps'
make: *** [build_apps] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.rYYbgG (%build)


How solve this problem?

Comment 24 Julian Sikorski 2013-01-11 09:50:29 UTC
Comment out hobble-openssl from prep

Comment 25 Mikhail 2013-01-11 09:55:09 UTC
(In reply to comment #24)
> Comment out hobble-openssl from prep

I do it already, see step 4)

Comment 26 Julian Sikorski 2013-01-11 09:56:58 UTC
Look closer. It is invoked in two places.

Comment 27 Mikhail 2013-01-11 10:13:19 UTC
(In reply to comment #26)
> Look closer. It is invoked in two places.

Which lines numbers do you mean??
I'm corrected lines 31 and 142.

Comment 28 Valent Turkovic 2013-01-11 13:04:42 UTC
Sent this message to legal:

Hi, could you please take look at this bug and give it your legal blessings:
https://bugzilla.redhat.com/show_bug.cgi?id=319901

Thanks,
Valent.

Comment 29 Julian Sikorski 2013-01-11 17:47:53 UTC
http://pkgs.fedoraproject.org/cgit/openssl.git/tree/openssl.spec

line 145 needs to be commented out, and you need to use pristine tarball. If this does not help, then I can't help you I'm afraid.
One more thing to try is to take out all "no-foo" statements from configure, as the dependencies might be interlocked.

Comment 30 Tomas Mraz 2013-01-11 18:05:04 UTC
The fips patch (and related patches) would have to be dropped and the fips option dropped from the build line and probably other modifications of the spec would be needed.

Comment 31 Mikhail 2013-01-14 09:14:38 UTC
(In reply to comment #30)
> The fips patch (and related patches) would have to be dropped and the fips
> option dropped from the build line and probably other modifications of the
> spec would be needed.

Thanks, I removed 40, 56, 58, 67 patches and successfull build rpm package, but GOST cipher still not work via curl. :(

$ openssl ciphers -v | grep GOST
GOST2001-GOST89-GOST89  SSLv3 Kx=unknown  Au=unknown Enc=unknown   Mac=unknown
GOST94-GOST89-GOST89    SSLv3 Kx=unknown  Au=unknown Enc=unknown   Mac=unknown

I'ts normal that Kx, Au and Mac is unknown?
How diagnose problem?

Comment 32 Mikhail 2013-01-18 06:26:36 UTC
Oh, I found problem...
Why you began using NSS instead OpenSLL in curl???

Comment 33 Jan Pokorný [poki] 2013-04-08 16:24:56 UTC
If ECDSA cannot be allowed for whatever legal reason, it should perhaps be
dropped from manpages as they describe full functionality, not a limited
subset.  Listing these limitations would be IMHO even more fair towards
the user.

$ man ssh-keygen | grep ecdsa | wc -l
5
$ ssh-keygen -t ecdsa
unknown key type ecdsa

Comment 34 Bill McGonigle 2013-04-11 06:26:53 UTC
(In reply to comment #30)
> The fips patch (and related patches) would have to be dropped and the fips
> option dropped from the build line and probably other modifications of the
> spec would be needed.

Just to clarify Tomas's point - NSA paid Certicom for patent licenses specifically for these curves for use in fips; we can probably assume they did their homework.

Wikipedia actually has a good list of references on the issue and I just added one more:
  http://en.wikipedia.org/wiki/ECC_patents

I've read that Sun's ECC code (that went to OpenSSL) was developed to specifically avoid Certicom patents, but I've only seen that asserted, not proven.  Tom St. Denis has some detailed ideas about how to avoid the patents, and the relevant RFC describes pre-patent methods to use.  More links there give opinions on what may or may not be infringing.

What I haven't seen anywhere is a review of the OpenSSL code to discover if it really is non-infringing or not.  Like somebody said, "let's hope the patent issue is dealt with well before RSA is broken."

Also, somebody else is operating a yum repo for the bitcoin client with an openssl built with ECC that installs along- side of Fedora's system openssl; if he's amenable it might be a decent playground to see what can be removed (e.g. fips) without breaking bitcoin. bitcoin is at least an example of a popular implementation using openssl ECC - reducing the scope of the work to validating the functions that bitcoin uses would at least be a starting point if examining the whole thing would be too difficult.

Is code review within scope of Fedora-legal, or would that need to be done separately?  If so, to what standards?  In other words, what does Fedora-legal need to say, "yes," on this one?  If a course of action is required, who develops and manages such a plan?

Comment 35 Michael Hampton 2013-04-11 06:59:12 UTC
(In reply to comment #34)

Hey Bill,

Somebody else certainly is amenable to recompiling OpenSSL a few (hundred?) times and testing Bitcoin with the result.

What we really need here is better communication.

Comment 36 Tom "spot" Callaway 2013-04-11 13:48:57 UTC
Communication is difficult on this issue, due to the nature of the legal issues in play. 

Code-review would be a big part of this, but what I really need is someone with a solid cryptography background who can:

A) identify the specific ECC algorithms in use in openssl
B) identify the earliest known publication dates for those mathematical algorithms (likely in academic publications, but code counts too)

If anyone out there is qualified to do this work and wants to help move this along, please contact me directly.

PLEASE DO NOT POST THIS MATERIAL INTO BUGZILLA. You may think you'd be helping, but you would not be.

Comment 37 Jonas Wielicki 2013-08-05 10:34:09 UTC
(In reply to Tom "spot" Callaway from comment #36)
> If anyone out there is qualified to do this work and wants to help move this
> along, please contact me directly.

Have you found someone who can help with that? If not, have you considered forwarding this problem to a cryptography-related community (for example the cryptography mailing list)?

If you found someone willing to help, it would be useful for the general public to know that. I for myself at least would appreciate a simple “we found someone and are working on it”.

regards,

Comment 38 Peter Lemenkov 2013-08-05 10:46:51 UTC
(In reply to Jonas Wielicki from comment #37)

> Have you found someone who can help with that? If not, have you considered
> forwarding this problem to a cryptography-related community (for example the
> cryptography mailing list)?

The main problem is that the issue in question just cannot be discussed publicly. So I'm sure nobody contacted anyone via maillists.

Comment 39 Jonas Wielicki 2013-08-05 10:51:20 UTC
(In reply to Peter Lemenkov from comment #38)
> (In reply to Jonas Wielicki from comment #37)
> 
> > Have you found someone who can help with that? If not, have you considered
> > forwarding this problem to a cryptography-related community (for example the
> > cryptography mailing list)?
> 
> The main problem is that the issue in question just cannot be discussed
> publicly. So I'm sure nobody contacted anyone via maillists.

Is there any reason not to seek out for cryptographic advice on mailinglist and _then_ discuss that in private?

Comment 40 Tom "spot" Callaway 2013-08-05 15:20:00 UTC
No reason. I don't particularly know where to look. This is well outside of my area of expertise.

Comment 41 Jonas Wielicki 2013-08-05 15:24:40 UTC
Depending on the scope of the request, you might have success by contacting people on the cryptography mailing list at 

   <http://lists.randombit.net/mailman/listinfo/cryptography>. 

I've seen a couple historical questions on that list. Maybe one related to elliptic curves was there too, so searching the archives may be a good idea.

good luck!

Comment 42 Bill McGonigle 2013-08-05 15:59:44 UTC
Just an FYI, this issue is one of the blockers that prevents the use of performant (ECC) perfect forward secrecy with TLS on Fedora-derived platforms with fedora-"hobbled" openssl.  Given the change in security footing between April and now - as in I'm following Google and Facebook's lead and switching all of my services over to TLS with PFS - in my opinion it's worth running this one up the flagpole at this time.  I believe my standard guidance will soon be to not run the vendor-supplied openssl package on EL systems as PFS becomes a real-world requirement.  I'll support DH-RSA as a fallback, but it's a 3.5x performance penalty, so other packages (e.g. Firefox) might be part of this mix as well.

I realize this doesn't change the underlying issue, but I think it might change the severity/priority.  If it just can't be provided, that would be good to know too, so we can get it up on a *forge for easy deployment to the masses.  I already see rapid movement among the alpha geeks; I think this will become a mass-market issue in the next couple months.

Comment 43 Alex Smirnoff 2013-08-05 16:28:13 UTC
(In reply to Bill McGonigle from comment #42)

I wonder why so many people are convinced that PFS == ECDHE, but with pretty common misconfiguration "!DHE" and people complaining "we don't care, redhat is broken and it is their duty to fix it", sometimes it is :-(

Comment 44 Bill McGonigle 2013-08-05 16:56:07 UTC
(In reply to Alex Smirnoff from comment #43)

> I wonder why so many people are convinced that PFS == ECDHE

The 64-bit optimized ECDHE is much, much faster than DHE-RSA.  See:

  http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

for benchmarks.  It's easy to convince somebody to give up 15% of handshake performance, but much harder to convince them to adopt a 300% increase.

Comment 45 Alex Smirnoff 2013-08-05 17:11:37 UTC
This 300% increase hardly affects more that 0.1% of users, resulting tremendous 0.3% performance degradation (or whatever it is). Not a good reason to be an a[censored]hole.

Comment 46 Bill McGonigle 2013-08-05 17:17:03 UTC
(In reply to Alex Smirnoff from comment #45)
> This 300% increase hardly affects more that 0.1% of users

Do you mean because most sysadmins haven't preferentially enabled/required PFS yet?

Comment 47 Alex Smirnoff 2013-08-05 17:22:51 UTC
Because if ECDHE has precedence before DHE, only RedHat clients are subject of performance degradation if the server is not RedHat.

(In reply to Bill McGonigle from comment #46)
> Do you mean because most sysadmins haven't preferentially enabled/required
> PFS yet?

Comment 48 Ananda Samaddar 2013-08-07 19:51:29 UTC
The urgency of this matter has increased somewhat due to the following:

http://www.technologyreview.com/news/517781/math-advances-raise-the-prospect-of-an-internet-security-crisis/

Comment 49 Enrico Scholz 2013-08-13 08:48:04 UTC
EC is a functional *requirement* to speak with big players like google, because  they provide only ECDHE but not DHE.

Comment 50 Scott Doty 2013-08-14 19:56:49 UTC
Okay, at what point do we start to get seriously critical about the lack of progress with this bug?

tl;dr:  Because of recent revelations of the activities of U.S. TLA's, this bug is no longer "low priority" but "highest priority".  Also, it's "NEW" -- really?

Longer version:

The GNU Alternate Domain System (GADS) is being developed using ec crypto for its distributed hash table.  Fedora's crippled openssl cannot support GADS.

Here is a presentation on the subject, which includes ioerror and rms:

   https://gnunet.org/internetistschuld

The "priority" of this ticket needs to be set higher, this is no longer "low" priority, but medium to high priority.

Also, considering the recent security revelations here in the United States -- as well as RedHat's cryptic messages on this bug about not posting helpful information about whether or not a patent applies -- is starting to get my spider sense tingling.

Given that, there are three assurances I would very much appreciate to see from Red Hat:

1) That there is active effort to resolve the issue about whether or not openssl can be uncrippled in Fedora

2) That Red Hat has not been asked to keep ECC out of its products by any TLA's  (c.f. their cryptic comments about "it won't help to talk about it on the bug")

and

3) That Fedora is a community-based distribution.

The latter assurance, because I think all Fedora users would be more comfortable knowing that Red Hat would not (or should not) allow TLA's to dictate what goes into Fedora, using Red Hat as a proxy.  (We know Red Hat is already dictating this because of their own legal ambiguities -- a process that for Fedora, should receive more sunlight...not less.)

Finally, I don't like being the guy that always ends up being blunt about the mistakes Red Hat is making regarding Fedora.  If I'm out of line, tell me to shut up.  But I think there should be a loud clamoring about this bug, especially given the resistance Red Hat has put up about sunlight in getting this "bug" cleared up.

Thanks,

Comment 51 kano 2013-08-14 22:57:51 UTC
Interesting that it might appear that they have also gone to the trouble of adding simple circumvention of the simple work around I posted back at comment 12 of simply building with only changing the original openssl tar file and un-hobbling the spec file

Last rebuild I had to do of bitcoin I simply used the openssl source directly (openssl configure,build, application -I,static -l), and didn't bother to work out why I could no longer build a package with an un-hobbled spec from the RedHat SRPM, the patches and the openssl tar file

So it is still easy to completely work around it ... just annoying that there might even be an attempt to stop the workaround ...

Comment 52 craigbarnes85 2013-08-15 00:01:09 UTC
The number of secure, non-ECC ciphers available in TLS are becoming fewer and fewer. The last 2 SSL/TLS attack papers I read specifically recommended moving towards ECC cipher suites at an accelerated pace.

Are Red Hat going to start taking this as seriously at some point? It's not very reassuring to state (semi-publicly) that you can't asses the issue one way or the other due to lack of available expertise.

Comment 53 Scott Doty 2013-08-15 18:40:22 UTC
Incidentally:  Dietrich T. Schmitz of linuxadvocates.com asked Pete Larmey of Red Hat's PR company for a statement, and he says:

"We are not able to provide any details beyond what is included in the Bugzilla thread."

I'd say it's going on.

Comment 54 Tom "spot" Callaway 2013-08-16 13:41:30 UTC
You can say whatever you'd like. As the person who has been working this bug for the last 6 years or so, I can say with full confidence: You're overreacting.

Yes, this is important. Yes, Red Hat takes this seriously. No, there are no black helicopters circling.

Comment 55 Scott Doty 2013-08-16 20:34:22 UTC
Okay Tom -- but please note, that is the first time I've seen anybody deny this was a TLA issue, rather than just an IP issue.  Even so, there is still a lot of cageyness around this, and it deserves much more sunshine than we are getting.

More to the point, there is no easy way to differentiate between the two alternatives of "TLA" vs. "IP", given Red Hat's behavior around this bug.  If you could shed some light on how we are supposed to tell the difference (sans you actually saying something about it), I'd very much like to learn what that could be.  Since I'm co-owner of an ISP, I've seen the wording in the subpoenas and the NSL's we get -- and I've never seen one of these not include a gag order.  We even once fought against one in court, which is why we have six stars with the EFF's "who's got your back?" list.

And then -- if this is an IP issue, why can't you just check with the openssl folks that their ECC is implemented with the algorithms outlined in RFC6090?

   http://www.rfc-editor.org/rfc/rfc6090.txt

This RFC describes how to implement ECC in a patent-free manner.  It was mentioned ^^ way up there in the comment stream.  Or since you've been "working this bug", have you already done that and just not told us?

I don't mean to be a douche about this, but it seems people have to be ascerbic to get anything moving in Fedora.  If you disagree, then please tell me how much longer we're supposed to wait for this to be resolved before expressing frustration with your efforts?

Finally, it's pretty much obvious to anybody paying attention that your comments about "black helicopters circling" is nothing more than strawman tactics.  If you would kindly depart from your 1999 thinking for the realities of 2013, it would be very helpful to those of us who care about the future of Fedora.  That  future, Sir, must necessarily include EC crypto.  Thank you.

Comment 56 Tom "spot" Callaway 2013-08-16 20:44:02 UTC
Lawyers move slowly. I am not currently restricted by anything from the US government in this matter. I am however, constrained on what I can say by the nature of the issue. I apologize for the frustration it seems to be causing you.

If it was as simple as pointing to RFC6090, it would have been resolved long ago. If you want to help, look at Comment 36 and provide me with the requested specific details. That is the only thing roadblocking this ticket.

Comment 57 Harald Reindl 2013-08-20 11:47:22 UTC
look at this 

https://bugzilla.redhat.com/show_bug.cgi?id=960193
> ECC will be supported on RHEL-6.5 and will also be 
> part of the planned FIPS-140 revalidation

so if this true and affects NSS which makes Firefox in RHEL 6.5 able to use ECDHE this should also affect Fedora and if this is the case openssl needs to get fixed because it would be absurd that our browsers support ciphers which are not possible to support with our servers

if this get's true it is *highly* recommended to enable this also for F18/F19 to support perfect forward secrecy

Comment 59 Peter Lemenkov 2013-08-22 04:30:37 UTC
(In reply to M8R-7fin56 from comment #58)

I wonder can we just ban email services such as Mailinator altogether?

Comment 62 Tom "spot" Callaway 2013-08-26 14:42:20 UTC
Please stop posting references to patents here. I appreciate that you believe you are helping by doing so, but it is not appropriate and those posts will be removed (and if the trend continues, the bug will be closed WONTFIX).

If you want to help, please do the tasks I need done in Comment #36, and email the resulting information directly to me.

No progress on this bug can be made until that is complete.

Comment 63 Harald Reindl 2013-08-26 14:53:46 UTC
> if you want to help, please do the tasks I need done in Comment #36

sorry, but your e-mail is @redhat.com
so why do you not clarify this with Redhat lawyers

how should a normal user reporting a bug and the fact that Redhat/Fedora is currently the only OS not supporting EECDHE give you the informations requested in comment #36?

Comment 64 Tom "spot" Callaway 2013-08-26 15:00:25 UTC
(In reply to Harald Reindl from comment #63)
> > if you want to help, please do the tasks I need done in Comment #36
> 
> sorry, but your e-mail is @redhat.com
> so why do you not clarify this with Redhat lawyers

They are lawyers. Not engineers. Not developers. Not coders. Not cryptographers.

What they need is for someone with the cryptographic skills and the coding skills to review the OpenSSL ECC code and tell them:

* What specific ECC mathematical algorithms are implemented in the OpenSSL code base? (And no, saying ECDHE (for example) is not sufficient. Or if you think it is, explain to me why.)
* When were these specific ECC mathematical algorithms first published (usually in academic literature, but any sort of publication will suffice)? 

> how should a normal user reporting a bug and the fact that Redhat/Fedora is
> currently the only OS not supporting EECDHE give you the informations
> requested in comment #36?

This is irrelevant. This is the "if everyone else is jumping off a bridge to their death, why aren't you?" argument.

I recognize that most (possibly all) of the people on CC for this bug cannot provide this information. If I could provide it, I wouldn't have to ask others for help.

Comment 65 Harald Reindl 2013-08-26 15:06:28 UTC
so why do you not talk to the BSD/Ubuntu people and seek their for help?
they all have enabled ECDHE and Redhat/Fedora needs to prove a good
reason why this is legally not possible and not the other way

why?

because in that case you would have for *any* piece of opensource
software bugreports open for 6 years waiting that one profes it
has no patent or other legal issues which is not possible
__________________

why do you ignore *this*

https://bugzilla.redhat.com/show_bug.cgi?id=960193
> ECC will be supported on RHEL-6.5 and will also be 
> part of the planned FIPS-140 revalidation

so someone at Redhat seems to know more as you and all of us together

Comment 66 Tom "spot" Callaway 2013-08-26 15:16:04 UTC
(In reply to Harald Reindl from comment #65)

> why do you ignore *this*

I don't ignore this. The simple fact is that Red Hat has very real legal exposure that entities like Debian, the BSDs, and even Canonical do not have. In cases where they have done due diligence on legal matters, we take that into consideration.

In this case, the only review that any other distribution seems to have done can be summed up with "we enabled it" or "we disabled it". The closest analog to Fedora is in OpenSUSE, and they have it disabled (or they did the last time I looked).

> so someone at Redhat seems to know more as you and all of us together

I am well aware of Red Hat's plans for RHEL, however, they do not impact Red Hat's decisions on Fedora. I am also aware of how silly that is.

Comment 67 Anonymous account 2013-08-27 23:57:56 UTC
Tom: Have you considered that it may not be possible to provide the answers you desire without reference to patents? As in, "the implemented algorithm is covered by EXPIRED patent #blah.", or "the implemented algorithm is similar to but distinctly different from patent #blah and the difference is XYZ."

Stating that the bug will be closed WONTFIX if anyone tries to help in public just adds on to the belief that the bug continues to exist for nefarious reasons.

Also, consider that everyone else be jumping off the bridge because the bridge is on fire and it's safer to tread water than be burned alive. Logically, if one person jumps then they might be crazy, but if EVERYONE else is jumping then perhaps they know something that you have yet to observe/comprehend but will soon cause you to regret failing to follow suit.

Comment 68 Scott Schmit 2013-08-28 01:58:12 UTC
(In reply to M8R-7fin56 from comment #67)
> Stating that the bug will be closed WONTFIX if anyone tries to help in
> public just adds on to the belief that the bug continues to exist for
> nefarious reasons.

Please take a look at https://lwn.net/Articles/338981/ and https://lwn.net/Articles/338943/ and I think you'll understand that Tom is behaving this way because he's trying to *help* you get what you want. Really.

Lawyers working for the other side (i.e., not Red Hat) will happily twist your words around against you if you give them a chance. It doesn't matter if the result is correct or makes any sense, it only matters if it sounds convincing for long enough that they get what they want.

Comment 69 Jan-Frode Myklebust 2013-08-28 07:01:33 UTC
(In reply to Tom "spot" Callaway from comment #64)
> 
> What they need is for someone with the cryptographic skills and the coding
> skills to review the OpenSSL ECC code and tell them:
> 
> * What specific ECC mathematical algorithms are implemented in the OpenSSL
> code base? (And no, saying ECDHE (for example) is not sufficient. Or if you
> think it is, explain to me why.)

I have no crypto skills, but can read the comments in crypto/ec/*.c. Does these not tell you what you're asking for? Or do you need someone to review that they are really implementing what they claim to be implementing ?

> * When were these specific ECC mathematical algorithms first published
> (usually in academic literature, but any sort of publication will suffice)? 

Also seems covered by the same comments..

Comment 71 Anonymous account 2013-08-28 18:19:44 UTC
Scott: The case you refer to (VFAT) was handled in a way that is questionable at best. Even if that is correct, it is inapplicable. That dealt with a known infringement that had to be worked around. This deals with something that is not infringing in the forst place. There was no point during which there was infringement to be concerned about. Tom is NOT working for what I/we want. I want software patents to not exist. I want software that works. I want lawyers to be burned alive for the crime of existing!

Comment 72 Anonymous account 2013-08-29 01:09:45 UTC
Critical thinking exercise:

RedHat is a large commercial entity. RedHat effectively controls Fedora despite claims that the latter is a community project. RedHat, as one of the early Linux IPO successes, has deep pockets. Why would anyone with the requisite skills do the the requested time-consuming work for free for the benefit of RedHat? Really, there is no motive to do so. Anyone who wants quality software can simply use any other distro. If RedHat wanted to serve their customers, they would have hired someone with the required expertise long ago to resolve this matter. In fact, they may well have done so if RHEL will indeed finally enable support for ECC ciphers. If indeed RHEL enables support but Fedora does not, that is simply more evidence that there is no legitimate reason for lack of ECC support in Fedora. If Fedora is really a community project, why can the community not give RedHat the middle finger and turn on ECC support in OpenSSL as nearly everyone else has done long ago?

I wonder, how many people are using this same BMN provided account for commenting on this bug report? It'd be interesting to know that tidbit. My personal opinion may not have spilled forth so easily had the solution to sharing it not been waved in my face.

Comment 73 Harald Reindl 2013-08-29 09:03:52 UTC
> The case you refer to (VFAT) was handled in a way that is questionable 

and without that we would not talk here because in days of Win95/98
nobody would have tried Linux at all without access to his data
from both installed operating systems

the same thing now:

if Redhat insists not to support ECDHE Redhat will lose customers - period
if Redhat enables ECDHE and not allow it for Fedora Fedora will lose users 

not today, not tomorrow, but it will happen if any other operating system doe ssupport it and more and more current useable Ciphers get broken and crypto experts are saying this will happen in the next 2-5 years

so the clock is ticking and not supporting Perfect Forwarding Secrecy is even today unacceptable

Comment 74 Peter Robinson 2013-08-29 09:09:06 UTC
This bug is for technical discussion it's not a place for opinion. Please take that discussion to the mailing list where it belongs. The last two comments are completely off topic

Comment 75 Enrico Scholz 2013-08-29 10:20:19 UTC
> not today, not tomorrow

no; they lose customers and users already today due to the poor crypto support.  Today, no RHEL or Fedora system can communicate with google in a safe way or can serve https for IE10.

The issue must be solved now (or better yesterday).

Comment 77 Jannik 2013-08-29 19:07:32 UTC
Ok, I think insulting comments (which are partially deleted) are not very constructive. We should discuss possible solutions, rather than blaming RedHat or its employees.
Everybody should accept that this "bug" is too important to wait until the US patent law changes.

I'm not aware of the RedHat internals, but wouldn't it be possible to pay a qualified reviewer to do the work mentioned by Tom?
Maybe the openssl developers could also help (since they definitely know the code) and might be interested in clearing out some patent issues concerning their software.

But apparently, whichever solution will be picked by RedHat, it will take a while. So lets think about some (suboptimal) "workarounds".

On the server side, maybe it is an option to use gnutls instead of openssl, since gnutls ships with ECDH.

I have no idea if it is possible to split openssl to several packages. If this is possible, Fedora could still provide the core openssl package, and everything needed for elliptic curve support could be available from rpmfusion.

Even if this is not possible, the user still needs easy access to an openssl rpm with ec enabled. So someone (who is not a RedHat employee) could provide a third-party repository for this purpose. And maybe it would be nice to have it listed here https://www.openssl.org/related/binaries.html . This would increase the user-friendliness because no one would notice some small 3rd-party repo. I know, they typically not include linux packages because the user should use official repos, but this matter could be a exception.
(I found a discussion about building openssl with ec here: https://bitcointalk.org/index.php?topic=85228.0 and there was a link to a currently maintained repo from some xiph.org guy: https://people.xiph.org/~greg/openssl/ )

I really hope this bug gets some progress soon...

Comment 78 Tom "spot" Callaway 2013-08-29 20:44:39 UTC
As a friendly reminder:

* I am the Fedora Legal liason, but I am not a lawyer.
* This issue is outstanding with Red Hat, they are considering the situation actively (I had a meeting today with them on it).
* Please troll elsewhere, it will have no real impact on this issue unless the signal becomes completely lost in the noise (and then I'll be forced to close this bug WONTFIX, which I do not wish to do).
* If there are any changes to this issue, I will address them in this bug. This bug has been bothering me for years, and I've invested a lot of time and tears into trying to bring it to resolution.

That said, please do not discuss patents in bugzilla, you may be putting Fedora at additional legal risk without realizing it. I am also sometimes limited in what I can say on tickets with legal factors, so please do not assume I am ignoring anyone (or anything).

Comment 79 Enrico Scholz 2013-08-30 10:14:40 UTC
> On the server side, maybe it is an option to use gnutls instead of openssl,
> since gnutls ships with ECDH.

no; gnutls has been crippled too

$ gnutls-cli --priority 'NORMAL:!RSA' www.google.com -p 443
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed


> So someone (who is not a RedHat employee) could provide a third-party
> repository for this purpose

rpmfusion would be a candidate because it is widely used.  But the crypto stuff in RHEL/Fedora is botched to the death; using original sources causes conflicts when applying following patches, which can not be solved trivially.  Maintaining alternative crypto libs (openssl, gnutls, nss) won't be funny and will cause lot of effort hence.

Comment 80 Jannik 2013-08-30 10:37:41 UTC
Ok, I thought gnutls support ECDH because it is listed in gnutls-cli --list .. My fault.

rpmfusion would only be a candidate if it is possible to split up openssl, because rpmfusion does not include competing packages and the official repos still have to contain the "crippled" openssl.

Comment 81 Cesar Eduardo Barros 2013-08-30 10:52:55 UTC
(In reply to Enrico Scholz from comment #79)
> > On the server side, maybe it is an option to use gnutls instead of openssl,
> > since gnutls ships with ECDH.
> 
> no; gnutls has been crippled too
> 
> $ gnutls-cli --priority 'NORMAL:!RSA' www.google.com -p 443
> *** Fatal error: A TLS fatal alert has been received.
> *** Received alert [40]: Handshake failed
> *** Handshake has failed

This bug is about openssl. There should be a separate bug for gnutls, since the code is different and thus it will need a separate review. The same for NSS, since the existing bug is for RHEL instead of Fedora.

I am not from RedHat, but I believe it is possible that they are waiting to release first the RHEL with the fixed NSS packages before applying the same fix to the corresponding Fedora packages. This gives them more time to rollback the fix if they find any problems (legal or otherwise); after they release (either on RHEL or on Fedora), it is too late.

> > So someone (who is not a RedHat employee) could provide a third-party
> > repository for this purpose
> 
> rpmfusion would be a candidate because it is widely used.  But the crypto
> stuff in RHEL/Fedora is botched to the death; using original sources causes
> conflicts when applying following patches, which can not be solved
> trivially.  Maintaining alternative crypto libs (openssl, gnutls, nss) won't
> be funny and will cause lot of effort hence.

For NSS, it is easy. You just have to recompile the nss-softokn source package (which is very easy to do with mock) and everything works. I do it on my Fedora 19 machines, and Firefox can use ECDHE without being recompiled.

For openssl, it is much harder, since it is compile-time, and thus you need to recompile all packages which depend on openssl (which are many). I do not know how hard it is with gnutls/nettle, but I believe it is also compile-time; but again, gnutls/nettle would be a separate bug.


For those criticizing RedHat: from what I could infer from their public comments, they are doing everything they can. But the patent situation on the USA is insane, so they need to do everything in secret, which gives the appearance of stonewalling. What Tom Callaway mentioned on comment 36 is the only way outside people can help: gather the relevant information *in secret*, and send it to him (who will relay to whoever is actually working on the issue) *in secret*. Anything else (other than directly working towards the abolition of software patents) will not help and can even hinder the effort. The same work will benefit both RHEL and Fedora, since they are so similar.

Sorry for adding to the noise if this comment was not helpful.

Comment 82 Howard Chu 2013-09-09 17:48:31 UTC
I would not be in such a hurry to adopt Elliptic-Curve based key exchanges.

https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1676105

DHE also provides perfect forward secrecy. It has a higher computation cost, but that's only in the handshake anyway. And it's already supported in all distro builds. Frankly I think it's premature for Google or anyone else to have jumped on the ECDHE bandwagon. And given the fact that Google has been forced to cooperate with the NSA already, I find it difficult to believe that this decision is anything more than theater - i.e., at once claiming to be more proactive about security, all the while knowing that their algorithm of choice has a back door already embedded in it. (Note - I am not saying EC has such a back door for certain. But neither can Google be certain, especially given the NSA's influence on EC design, unless they have already been told by the NSA.)

Comment 83 Harald Reindl 2013-09-09 17:51:59 UTC
> https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1676105

i missed the prove - where is it

> DHE also provides perfect forward secrecy

oh yeah, that helps you so much until the rest of the world does not offer it becuse the large performance impact and you are not talking to your own services all day long

Comment 84 Peter Backes 2013-09-21 07:44:24 UTC
(In reply to Howard Chu from comment #82)
> I would not be in such a hurry to adopt Elliptic-Curve based key exchanges.
> 
> https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1676105

If it were that easy, everything would be alright. However, you missed one important reservation: "the code has been subverted".

Even if, as Schneier suspects, EC crypto may have a NSA backdoor built into some of its constants, the alternatives that are actually there are even worse. For example, openssh requires DSA keys to have exactly 1024 bits. This is caused by some decision to require SHA1 to be used for SSH-DSS, and more than 1024 bits discrete logarithm keys seem not to increase the overall cryptographic strength if SHA1 is used (the hash would the weakest link then).

Further, openssh seems to use DH key exchange with group size of 1024 bits by default (max(key len, block size, iv len, mac len) * 8, where all variables are <= 128 in the default configuration). 1024 bits discrete logarithm cryptography can be considered breakable for a sufficiently sophisticated adversary, certainly including not just government agencies. Given this, it really comes as no surprise that the leaked NSA slides name SSH as one of those applications that the NSA is able to decrypt.

These issues are well known and the openssh are essentially responding to them by saying "openssh supports EC crypto. shut up and use that". See https://bugzilla.mindrot.org/show_bug.cgi?id=2109

Since Fedora doesn't have support for EC crypto, it should come with a big warning sign telling people not to use it as an openssh client or server for transmitting sensitive information.

It seems that noone is really aware of the consequences of this bug. Either EC needs to be enabled, or pre-EC-era-crypto seriously needs to be fixed.

Comment 85 Harald Reindl 2013-09-21 09:10:36 UTC
> responding to them by saying "openssh supports EC crypto

as long no Redhat/Fedora systems are ever involved

Comment 86 Enrico Scholz 2013-09-21 11:56:10 UTC
fwiw, rpmfusion is working on an uncrippled openssl version:

https://bugzilla.rpmfusion.org/show_bug.cgi?id=2842

Comment 87 Peter Backes 2013-09-22 01:43:29 UTC
I opened bug 1010607 to at least alleviate some of the consequences of not shipping ec support. I kindly ask for a second (and perhaps third, fourth, etc.) opinion, though, since I am not an expert in cryptography. I am sure some subscribed to this bug here know better than me. Can you please have a look at my bug report and check if the argument is valid and the solution is reasonable?

Comment 88 Harald Reindl 2013-09-22 01:49:38 UTC
the rpmfusion package may solve this for users like me building relevant server software from sources and using their own packages - you need to rebuild any relevant package against openssl-freeeworld

but even in this case: as long it is not supported in the distribution you will never be able to use "perfect forward secrecy" to any server (even your own) with Firefox/Thunderbird, so you can offer this for your clients, but you can't really use it

Comment 89 druIRdRlmV 2013-09-24 22:19:52 UTC
I would like to respectfully echo the concern that other users have expressed over the absence of ECC in Fedora. For us to build our own packages is what the community is about -- to provide ourselves with tools that we not necessarily given. However, as more and more providers switch to PFS and ECC in the wake of NSA "revelations", Fedora users are very likely unknowingly using non-optimal crypto and putting their entire sessions at risk.

I think most folks CC'ed here would be comforted by an update on the status. We all know attorneys move at a snails pace -- that's nothing new. And understandable, as long as there is continued progress.

Most people here are probably hoping for a non-retaliatory, constructive response by legal that they are indeed actively working to resolve the issue. Please let us know what any of us can do to facilitate progress here. I am confident that the community will be receptive.

Comment 90 Peter Backes 2013-09-25 02:04:47 UTC
(In reply to druIRdRlmV from comment #89)
> that we not necessarily given. However, as more and more providers switch to
> PFS and ECC in the wake of NSA "revelations"

I agree that it would be great to have ECC support, but please let me set some of the facts straight:

0. This bug is not about PFS.

1. Usually, you do not have to "switch" to PFS. It is provided automatically where it is available.

2. ECC support is not a requirement for PFS. Algorithms providing PFS support that are based on discrete logarithms (Discrete Logarithm Diffie-Hellman) have been available for ages.

3. The advantage ECC offers you is not security, at least not directly, but efficiency and lower time complexity. Compared to RSA and DSA, with ECC, it is cheaper to get higher security. However, this applies to PFS only with strong reservation, because  Discrete Logarithm Diffie-Hellman benefits from some shortcuts that make it pretty fast (especially when compared to the obvious choice: ephemeral RSA keys).

4. PFS ("perfect forward security") is a marketing buzzword. All it does is protect your encrypted sessions from subsequent disclosure of the private key you use for authentication. However, PFS does not protect you from someone who is able to break the cryptographic algorithms used for PFS itself. openssh, for example, with ECC disabled, seems to use only 1024 bit Diffie-Hellman group order for key exchange if you choose a 128 bit symmetric block cipher (such as AES), which seems to make the PFS algorithm clearly the weakest link. 1024 bit Discrete Logarithm, RSA and DSA crypto arguably can be broken today (certainly not only by the NSA; see bug 1010607), and given the ever-increasing computing power, the same will eventually happen for more bits. So PFS actually neither provides perfect security, nor provides forward security. And this holds for ECC PFS just in the same way, except that the numbers of bits are different. (1024 bit Discrete Logarithm group size is about the same strength as 160 bit ECC.) Given the fact that Discrete Logarithm Diffie-Hellman hardly suffers from complexity issues, the reason to demand ECC support for PFS thus seems mostly based on design and implementation issues (in software such as openssh), not with the crypto!

5. ECC arguably does not protect you from the NSA's ability to decrypt, because there are reasonable suspicions that ECC standards have been tampered with by the NSA, and contain a backdoor (there are some constants lacking a reasonable explanation)--the actually as with Dual_EC_DRBG. (Note that Dual_EC_DRBG is actually based on elliptic curves, that's what the EC stands for.)

Comment 91 Tom "spot" Callaway 2013-09-25 16:35:01 UTC
There is continued progress on this front. It is being actively worked. I have no updates to share at this time.

Comment 92 Jan-Frode Myklebust 2013-10-07 09:18:49 UTC
Is this now solved in the RHEL6.5 beta, so that the same can be fixed in fedora?

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6-Beta/html-single/6.5_Release_Notes/index.html

* ECDHE Support in OpenSSL
Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) is supported, witch allows for Perfect Forward Secrecy with much lower computational requirements. 

* ECDSA Support in OpenSSL
Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) which uses Elliptic Curve Cryptography (ECC). Note that only the nistp256 and nistp384 curves are supported.

Comment 93 Harald Reindl 2013-10-10 10:50:05 UTC
ping - if RHEL6.5 contains it Fedora should be *first* here and ship fixed packages for F18/F19/F20

Comment 94 Robert Scheck 2013-10-10 11:46:30 UTC
Cross-filed case #00964151 in the Red Hat customer portal. Either RHEL 6.5
beta ships legally encumbered software (all I can read in the comments above
brings me to this wording) or the legal issues have been resolved but Fedora
must then be able to ship an updated OpenSSL as well. Correct me, but I do
not see any other option and thus above ticket requests a statement from Red
Hat for at least RHEL (from the perspective of a paying RHEL customer).

Comment 95 Tom "spot" Callaway 2013-10-10 14:20:29 UTC
There are no updates to the status on this issue as it relates to Fedora at this time.

Comment 96 Harald Reindl 2013-10-10 15:39:38 UTC
> There are no updates to the status on this issue 
> as it relates to Fedora at this time.

that's not how transparency looks like.....

Comment 97 craigbarnes85 2013-10-10 17:26:34 UTC
Who needs export controls when nebulous patent concerns are just as effective?

Comment 98 Tom "spot" Callaway 2013-10-15 02:03:06 UTC
As of the following update revisions, the "ec", "ecdh", and "ecdsa" options have been re-enabled in the openssl package:

openssl-1.0.1e-4.fc18.1
openssl-1.0.1e-4.fc19.1
openssl-1.0.1e-27.fc20
openssl-1.0.1e-27.fc21

Comment 99 Fedora Update System 2013-10-15 02:05:43 UTC
openssl-1.0.1e-4.fc19.1 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/openssl-1.0.1e-4.fc19.1

Comment 100 Fedora Update System 2013-10-15 02:06:08 UTC
openssl-1.0.1e-27.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openssl-1.0.1e-27.fc20

Comment 101 Fedora Update System 2013-10-15 02:07:03 UTC
openssl-1.0.1e-4.fc18.1 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/openssl-1.0.1e-4.fc18.1

Comment 102 Peter Lemenkov 2013-10-15 05:00:41 UTC
(In reply to Tom "spot" Callaway from comment #98)
> As of the following update revisions, the "ec", "ecdh", and "ecdsa" options
> have been re-enabled in the openssl package:
> 
> openssl-1.0.1e-4.fc18.1
> openssl-1.0.1e-4.fc19.1
> openssl-1.0.1e-27.fc20
> openssl-1.0.1e-27.fc21

Awesome! Thanks Tom for helping this happen! 

Can we just start re-adding these algorithms back in other libraries and applications, or should we deal with each library separately (separate bugzilla ticket)?

Comment 103 Thorsten Hoeger 2013-10-15 05:14:47 UTC
Thanks for resolving this issue. Does this affect the availability of elliptic curves in CentOS?

Comment 104 Michael S. 2013-10-15 05:57:09 UTC
Elliptic curves in CentOS should be seen with CentOS folks ( who will likely say they follow RHEL, but RHEL is not Fedora )

Comment 105 Tom "spot" Callaway 2013-10-15 06:04:05 UTC
(In reply to Peter Lemenkov from comment #102)

> Awesome! Thanks Tom for helping this happen! 
> 
> Can we just start re-adding these algorithms back in other libraries and
> applications, or should we deal with each library separately (separate
> bugzilla ticket)?

No, please open separate bugzilla tickets for other packages.

Comment 106 Tom "spot" Callaway 2013-10-15 06:04:50 UTC
(In reply to Tom "spot" Callaway from comment #105)

> No, please open separate bugzilla tickets for other packages.

... and be sure to CC me.

Comment 107 Fedora Update System 2013-10-15 06:41:00 UTC
Package openssl-1.0.1e-27.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssl-1.0.1e-27.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-19099/openssl-1.0.1e-27.fc20
then log in and leave karma (feedback).

Comment 108 Harald Reindl 2013-10-15 08:35:59 UTC
god bless you

as followup packages like httpd, dovecot and so on needs a rebuild
tested it recently on my testserver with own packages and before
re-compile httpd ECDHE did not appear at https://www.ssllabs.com/ssltest/

additionally NSS should enable ECDHE too to achieve at least with the next Firefox/Thunderbird updates get it enabled too, otherwise we have the situation that now PFS is supported on Fedora servers but not on the clients

Comment 109 Cesar Eduardo Barros 2013-10-15 11:17:02 UTC
(In reply to Harald Reindl from comment #108)
> god bless you
> 
> as followup packages like httpd, dovecot and so on needs a rebuild
> tested it recently on my testserver with own packages and before
> re-compile httpd ECDHE did not appear at https://www.ssllabs.com/ssltest/

Every package depending on openssl will have to be recompiled, since the presence of EC is a compile-time test. Adding them to this bug will not help much, it will be better to file a separate bug for each package you care about.

> 
> additionally NSS should enable ECDHE too to achieve at least with the next
> Firefox/Thunderbird updates get it enabled too, otherwise we have the
> situation that now PFS is supported on Fedora servers but not on the clients

NSS is a separate library (nss-softokn), so it needs a separate bug filled. And in fact, it has already been filled. Bug 1019216 is for NSS, and I also found bug 1019222 for openssh.

As Tom Callaway mentioned, if you file any new bug requesting ECC to be enabled in a package, always add him to the CC: list of the bug.

Comment 110 Harald Reindl 2013-10-15 11:29:36 UTC
since OpenSSL in Fedora from now on supports ECDHE
depending software needs to be rebuilt to make use
of it as well as libraries like NSS/GNUTLS should
do the same and depending packages like Firefox
needs a rebuild against refreshed NSS to support 
it also on the client side

i made some triage today
_____________________________________________________

openssl:
https://bugzilla.redhat.com/show_bug.cgi?id=319901#c108

nss-softokn
https://bugzilla.redhat.com/show_bug.cgi?id=1019244

nss
https://bugzilla.redhat.com/show_bug.cgi?id=1019245

firefox
https://bugzilla.redhat.com/show_bug.cgi?id=1019247

thunderbird:
https://bugzilla.redhat.com/show_bug.cgi?id=1019249

httpd:
https://bugzilla.redhat.com/show_bug.cgi?id=1019251

dovecot:
https://bugzilla.redhat.com/show_bug.cgi?id=1019253

postfix:
https://bugzilla.redhat.com/show_bug.cgi?id=1019254

openssh:
https://bugzilla.redhat.com/show_bug.cgi?id=1019256

dbmail:
https://bugzilla.redhat.com/show_bug.cgi?id=1019259

Comment 111 Christopher Meng 2013-10-15 11:35:35 UTC
Congrats!

Comment 112 Harald Reindl 2013-10-15 13:09:49 UTC
curl:
https://bugzilla.redhat.com/show_bug.cgi?id=1019312

Comment 113 Harald Reindl 2013-10-15 13:56:48 UTC
libssh2:
https://bugzilla.redhat.com/show_bug.cgi?id=1019333

Comment 114 Harald Reindl 2013-10-15 14:00:11 UTC
kde-baseapps (Konqueror):
https://bugzilla.redhat.com/show_bug.cgi?id=1019337

Comment 115 Bill McGonigle 2013-10-15 15:36:32 UTC
Folks, we have a bugzilla - let's use it to track this properly and leave this bug alone for any issues with the openssl package.

I made bug 1019390 to serve as a tracking bug and set the bugs linked here so far to block it.  Please cc: yourselves there and help with the effort.

Comment 116 Harald Reindl 2013-10-15 22:07:26 UTC
Created attachment 812698 [details]
verified by https://www.ssllabs.com/ssltest/

BTW: since some hours wre are in *production* with self-maintained Apache/Dovecot/Postfix packages linked against the ECDHE-enabled OpenSSl and it works like a charme

Comment 117 Fedora Update System 2013-10-21 00:56:22 UTC
openssl-1.0.1e-28.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 118 Fedora Update System 2013-10-22 05:05:42 UTC
openssl-1.0.1e-28.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 119 Peter Lemenkov 2013-10-22 08:58:06 UTC
EC was disabled again - this time just partially. I think it's time to reopen this again.

Comment 120 Robert Scheck 2013-10-22 09:06:49 UTC
To which commit of http://pkgs.fedoraproject.org/cgit/openssl.git/log/ do you
refer here?

Comment 121 Tom "spot" Callaway 2013-10-22 09:25:36 UTC
Please stop reopening this bug. The original bug was about ec and ecparam commands being missing, and they are now here. I recognize that not all of the curves that are wanted/needed are enabled in openssl, but please open a bug for the curves that you have a specific want or need for, block the new bugs against FE-Legal, and they will be considered individually.

I recognize how annoying this is, yet, this is how we must proceed with the legal concerns around this space. But, please, let this ancient bug die.

Comment 122 Michael J Gruber 2013-10-22 09:29:59 UTC
http://pkgs.fedoraproject.org/cgit/openssl.git/commit/?id=b3551463cafee86a63c60e294f754a8c5cddc37a

is the commit from 27 to 28. No git tag, no explanation on the why, and the diff looks quite large and has large additions of code for a commit claiming only to remove stuff.

Comment 123 Cesar Eduardo Barros 2013-10-22 09:48:53 UTC
To stop this edit war, I created bug 1021897 for secp521r1 and bug 1021898 for Bitcoin's secp256k1.

Comment 124 Henrik Nordström 2013-10-22 09:55:22 UTC
The changelog comment is pretty self-explaining imho.

And from what it looks it's not that much code, only adding back stripped down versions of the same that was removed in openssl-hobbled.

In other words I suppose the request in Comment #36 is still open, but meanwhile lawyers have found some form of agreement that makes them accept some specific EC curves in Fedora.

Comment 125 Michael J Gruber 2013-10-22 10:29:19 UTC
(In reply to Henrik Nordström from comment #124)
> The changelog comment is pretty self-explaining imho.
> 
> And from what it looks it's not that much code, only adding back stripped
> down versions of the same that was removed in openssl-hobbled.
> 
> In other words I suppose the request in Comment #36 is still open, but
> meanwhile lawyers have found some form of agreement that makes them accept
> some specific EC curves in Fedora.

The point is that it went forth and (partially) back, and the why on that would be good to know. Especially since the partially seems to have been done partially only.

Comment 126 Fedora Update System 2013-11-10 07:38:24 UTC
openssl-1.0.1e-28.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


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