And it's InputStream.class where this exception is thrown,

public void handleConnection(InputStream sockInput, OutputStream sockOutput) {

     byte[] buf = new byte[1024];
     
     try {
        int bytes_read ;
        // This call to read() will wait forever, until the
        // program on the other side either sends some data,
        // or closes the socket.
        bytes_read = sockInput.read(buf, 0, buf.length);


public int read(byte b[], int off, int len) throws IOException {
        if (b == null) {
            throw new NullPointerException();

I am running into the same issue on Fedora 19. It caused by the change indicated here: http://koji.fedoraproject.org/koji/buildinfo?buildID=590488

"* Fri Oct 24 2014 Jiri Vanek <jvanek> - 1:1.8.0.25-2.b18
- added patch12,removeSunEcProvider-RH1154143"

After this update to remove the Sun EC provider, it looks like OpenJDK cannot handle some https connections anymore (which should be a pretty big concern).

I will attach the stack trace I am seeing.

Created attachment 963403 [details]
Stack trace from jgit when trying to connect over https

There's two parts to this bug. The first is the removal of ECC. This is intentional: we should be using system ECC (via NSS or something) not carrying our own implementation. It was a mistake in the first place that ECC was (somehow) enabled.

The second issue that came up with the ECC fix is that the size restriction on DH is too small. This is probably bug 1163501 and will be fixed separately.

(In reply to Matt Wringe from comment #3)
> Stack trace from jgit when trying to connect over https

Is there a URL I can use to reproduce this?

One of the URLs used is https://github.com/liveoak-io/liveoak-example-chat-html.git

(In reply to Dave Chen from comment #0)
> Would anyone kindly give us some suggestion?

Is there a way I can reproduce this?


(In reply to Matt Wringe from comment #5)
> One of the URLs used is
> https://github.com/liveoak-io/liveoak-example-chat-html.git

I can not reproduce this on F19:

$ uname -a
Linux localhost.localdomain 3.9.5-301.fc19.x86_64 #1 SMP Tue Jun 11 19:39:38 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25.x86_64/jre jgit clone https://github.com/liveoak-io/liveoak-example-chat-html.git
Initialized empty Git repository in /home/omajid/liveoak-example-chat-html/.git
remote: Counting objects: 239
remote: Compressing objects: 100% (28/28)
Receiving objects:      100% (239/239)
Resolving deltas:       100% (50/50)
Updating references:    100% (4/4)
remote: Total 239 (delta 13), reused 0 (delta 0)
From https://github.com/liveoak-io/liveoak-example-chat-html.git
 * [new branch]      master     -> origin/master
 * [new tag]         1.0.0.Alpha01 -> 1.0.0.Alpha01
 * [new tag]         1.0.0.Alpha02 -> 1.0.0.Alpha02
 * [new tag]         1.0.0.Beta01 -> 1.0.0.Beta01

Also couldn't reproduce this on F20 and F21.

hi, Omair
We will upload a sample code tomorrow if the error still exists.

Created attachment 971389 [details]
one sample

This is one sample code to reproduce the exception.

I ran into this same exception when Jenkins tries to connect via SVN to the following URL: https://ja2svn.mooo.com/source/ja2/trunk/GameSource/ja2_v1.13/Build/

ECC is being increasingly used in HTTPS, as it's more secure for a given number of key bits than RSA or DSA, so anything which prevents it functioning is probably a bad idea.

Omair, would you help to me debugthe reason why it throws the exception in the sample code, and how to solve the exception?

Hallo!

I run into a similar problem using jameica/hibiscus
(http://software.opensuse.org/package/jameica and http://software.opensuse.org/package/hibiscus)
after upgrading from Fedora 20 to Fedora 21:

[Mon Dec 22 21:56:51 CET 2014][ERROR][de.willuhn.jameica.hbci.HBCICallbackSWT.log]
  org.kapott.hbci.exceptions.HBCI_Exception: Fehler beim Senden der HBCI-Nachricht zum Server
	at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:148)
	at org.kapott.hbci.comm.Comm.pingpong(Comm.java:67)
	at org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:352)
	at org.kapott.hbci.manager.HBCIKernelImpl.rawDoIt(HBCIKernelImpl.java:178)
	at org.kapott.hbci.manager.HBCIInstitute.fetchBPD(HBCIInstitute.java:223)
	at org.kapott.hbci.manager.HBCIInstitute.register(HBCIInstitute.java:367)
	at org.kapott.hbci.manager.HBCIHandler.registerInstitute(HBCIHandler.java:209)
	at org.kapott.hbci.manager.HBCIHandler.<init>(HBCIHandler.java:131)
	at de.willuhn.jameica.hbci.passports.pintan.server.PassportHandleImpl.open(PassportHandleImpl.java:180)
	at de.willuhn.jameica.hbci.gui.action.PassportTest$1.run(PassportTest.java:80)
	at de.willuhn.jameica.gui.GUI$6.run(GUI.java:964)
Caused by: javax.net.ssl.SSLException:
   java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1917)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1874)
	at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1857)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1378)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1355)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
	at org.kapott.hbci.comm.CommPinTan.ping(CommPinTan.java:138)

The jameica/hibiscus packages are the old ones. Only the java-1.8.0-openjdk packages has been updated.
Do you think the problem lies in the jamaica package or in openjdk itself?

I also ran into the problem described in Comment 11 and have a reproducer for you;
versions tested:

Hibiscus 2.6.10
Jameica 2.6.1
java-1.8.0-openjdk-1.8.0.25-5.b18.fc21.x86_64


steps to reproduce;

1. install Jameica and Hibiscus as per http://www.willuhn.de/wiki/doku.php?id=handbuch:sonstiges:install (sorry, it's in German). Basically one needs to:
    - download the jameica-linux64.zip and hibiscus.zip
    - unpack only jameica-linux64.zip location is irrelevant
    - run ./'jameica.sh
    - set some password
    - go to the menu entry Datei/Einstellungen
    - then in the tab Plugins the 'Neues Plugin installieren' button.
    - Feed it the hibiscus.zip
    - restart Jameica to activate the plugin

2. Set up a test account in Jameica, using the Hibiscus plugin
   - navigate in the tree to Jameica / Hibiscus / Bank-Zugänge
   - button 'Neuer Bank-Zugang'
   - HBCI-Verfahren: PIN/TAN
   - login details:
      - Benutzerkenn…: demo
      - Kundenkennung: demo
      - Bankleitzahl:  60090800
      - Hostname/URL…: fints.bankingonline.de/fints/FinTs30PinTanHttpGate
      - TCP-Port des…: 443
      - Filter für d…: Base64

3. click 'Konfiguration testen' (you can abort the PIN entry, bug triggers before PIN exchange)


actual result:
java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available


expected result:
java-1.8.0-openjdk can to connect to https://fints.bankingonline.de:443/fints/FinTs30PinTanHttpGate


additional info from the Hibiscus log:
[05.01.2015 15:17:47] Teste Sicherheits-Medium...
[05.01.2015 15:17:47]   saving passport config
[05.01.2015 15:17:47]   creating progress monitor for GUI
[05.01.2015 15:17:47]   activating progress monitor
[05.01.2015 15:17:47]   open pin/tan passport
[05.01.2015 15:17:47]   [PIN/TAN] url         : fints.bankingonline.de/fints/FinTs30PinTanHttpGate
[05.01.2015 15:17:47]   [PIN/TAN] blz         : 60090800
[05.01.2015 15:17:47]   [PIN/TAN] filter      : Base64
[05.01.2015 15:17:47]   [PIN/TAN] HBCI version: 300
[05.01.2015 15:17:47]   [PIN/TAN] tan sec mech: null
[05.01.2015 15:17:47]   hole kreditinstituts-spezifische Daten
[05.01.2015 15:17:47]   fetching BPD
[05.01.2015 15:17:47]   erzeuge HBCI-Nachricht DialogInitAnon
[05.01.2015 15:17:47]   creating a connection to https://fints.bankingonline.de:443/fints/FinTs30PinTanHttpGate and checking the certificate
[05.01.2015 15:17:47]   versende HBCI-Nachricht
[05.01.2015 15:17:47]    Fehler beim Senden der HBCI-Nachricht zum Server
[05.01.2015 15:17:47]    EC AlgorithmParameters not available
[05.01.2015 15:17:47]    EC AlgorithmParameters not available
[05.01.2015 15:17:47]    EC AlgorithmParameters not available
[05.01.2015 15:17:47]   beende Dialog
[05.01.2015 15:17:47]    kann HBCI-Wert für MsgHead.dialogid nicht auf null setzen
[05.01.2015 15:17:47]   fetching BPD failed: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available org.kapott.hbci.manager.HBCIInstitute.fetchBPD(HBCIInstitute.java:334)
[05.01.2015 15:17:47]    Abholen der BPD fehlgeschlagen
[05.01.2015 15:17:47]   FAILED! - maybe this institute does not support anonymous logins
[05.01.2015 15:17:47]   we will nevertheless go on
[...]

I am using jenkins for building. The Jenkins Mailer Plugin doesn't can send emails when ssl is selected and shows me the exact same stacktrace from above. The same is when my build artifacts are would be uploaded to a remove via ssl.

After investigating the issue i found out that the required sunec.jar found in this article:
http://armoredbarista.blogspot.de/2013/10/how-to-use-ecc-with-openjdk.html
is found in the current version here:
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-5.b18.fc21.x86_64/jre/lib/ext/sunec.jar

So the ecc class is available. I don't know how to use it? Or have it in the classpath.

The jar file shouldn't be there. The fact that it is may be why you're having problems. Have you tried moving the sunec.jar file outside the JDK?

I'm working on this to solve. sunec.jar is not removed in the released package. The patch (12) in the spec mentioned just disable the providers. 
I just read about issues with "make". So this issue maybe is in the meantime solved seems.
I don't know why it was really disabled? Law issue? I also read that people wrote that "it is available" but don't know the meaning.

There are some patents around certain implementations of ECC cryptography, but nothing preventing the use of the encoding itself. See https://en.wikipedia.org/wiki/ECC_patents for details.

For now, it's by far the easiest to just download the Sun JDK and use that instead. It doesn't share the problem.

(In reply to Daniel Rindt from comment #16)
> I'm working on this to solve. sunec.jar is not removed in the released
> package. The patch (12) in the spec mentioned just disable the providers. 
> I just read about issues with "make". So this issue maybe is in the meantime
> solved seems.
> I don't know why it was really disabled? Law issue? I also read that people
> wrote that "it is available" but don't know the meaning.

I gathered that. Have you tried removing it manually?

(In reply to numien from comment #17)
> There are some patents around certain implementations of ECC cryptography,
> but nothing preventing the use of the encoding itself. See
> https://en.wikipedia.org/wiki/ECC_patents for details.
> 
> For now, it's by far the easiest to just download the Sun JDK and use that
> instead. It doesn't share the problem.

I don't think that this is the appropriate forum to be offering legal advice.

Moreover, it's also quite unhelpful to recommend proprietary software that is not part of Fedora as a proposed solution.

(In reply to Andrew John Hughes from comment #18)
> (In reply to Daniel Rindt from comment #16)
> > I'm working on this to solve. sunec.jar is not removed in the released
> > package. The patch (12) in the spec mentioned just disable the providers. 
> > I just read about issues with "make". So this issue maybe is in the meantime
> > solved seems.
> > I don't know why it was really disabled? Law issue? I also read that people
> > wrote that "it is available" but don't know the meaning.
> 
> I gathered that. Have you tried removing it manually?

I removed the patch12 in the spec file which disables ECC. IT build fine and jenkins is now working with openjdk.

(In reply to Daniel Rindt from comment #20)
> (In reply to Andrew John Hughes from comment #18)
> > (In reply to Daniel Rindt from comment #16)
> > > I'm working on this to solve. sunec.jar is not removed in the released
> > > package. The patch (12) in the spec mentioned just disable the providers. 
> > > I just read about issues with "make". So this issue maybe is in the meantime
> > > solved seems.
> > > I don't know why it was really disabled? Law issue? I also read that people
> > > wrote that "it is available" but don't know the meaning.
> > 
> > I gathered that. Have you tried removing it manually?
> 
> I removed the patch12 in the spec file which disables ECC. IT build fine and
> jenkins is now working with openjdk.

I meant sunec.jar, which shouldn't be present. The patch is correct, but sunec.jar and libsunec.so shouldn't be included either. At present, this provider is only supported on the latest versions of java-1.7.0-openjdk.

Ok, will the patch be removed from the official package too?
Do I understand it correctly, that the patch just disables the providers and is new in Fedora21?

What is in the sunec.jar archive? Why should the be removed, if some software still needs it? Maybe we can enable the providers and add the files as an sub-package?

(In reply to Andrew John Hughes from comment #19)
> I don't think that this is the appropriate forum to be offering legal advice.

This was not intended to be legal advice, simply replying to the earlier question, that the decision to remove ECC being for legal reasons was unlikely.

> Moreover, it's also quite unhelpful to recommend proprietary software that
> is not part of Fedora as a proposed solution.

Please note the use of the words "for now." It was not intended as a solution, merely a simple work-around for those affected, until the issue is resolved.

Hello!

I'm not sure, if just disabling EC via the patch is just incomplete.
I had to disable the EC algorithms in 

 /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-5.b18.fc21.x86_64/jre/lib/security/java.security

by adding the following line:

 jdk.tls.disabledAlgorithms=EC,ECDHE,ECDH

This way the problematic software (Jameica/Hibiscus), which wants to establish a secure
connection using EC, does work again.


But I think do not understand correctly why the more secure EC algorithms were disabled
in the first place. Shouldn't we support the more secure algorithms?
If it worked in the old versions, why were they disabled now?

Maybe somebody can give a good explanation for this ?!

Regards
 Sven

(In reply to Sven Anders from comment #24)
> Hello!
> 
> I'm not sure, if just disabling EC via the patch is just incomplete.
> I had to disable the EC algorithms in 
> 
>  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-5.b18.fc21.x86_64/jre/lib/security/
> java.security
> 
> by adding the following line:
> 
>  jdk.tls.disabledAlgorithms=EC,ECDHE,ECDH
> 
> This way the problematic software (Jameica/Hibiscus), which wants to
> establish a secure
> connection using EC, does work again.
> 
> 
> But I think do not understand correctly why the more secure EC algorithms
> were disabled
> in the first place. Shouldn't we support the more secure algorithms?
> If it worked in the old versions, why were they disabled now?
> 
> Maybe somebody can give a good explanation for this ?!
> 
> Regards
>  Sven


hi, Sven

I try your solution, and it works well in our env:). 

Thanks
Emily

(In reply to Sven Anders from comment #24)
> I'm not sure, if just disabling EC via the patch is just incomplete.

Yes, my "fix" for disabling EC was incomplete. It was based on what we did in OpenJDK 7, which seems to be insufficient for OpenJDK 8. Apologies.

> I had to disable the EC algorithms in 
> 
>  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-5.b18.fc21.x86_64/jre/lib/security/
> java.security
> 
> by adding the following line:
> 
>  jdk.tls.disabledAlgorithms=EC,ECDHE,ECDH
> 
> This way the problematic software (Jameica/Hibiscus), which wants to
> establish a secure connection using EC, does work again.

Thanks for identifying this! I will make this the default.

> But I think do not understand correctly why the more secure EC algorithms
> were disabled in the first place. Shouldn't we support the more secure 
> algorithms? If it worked in the old versions, why were they disabled now?

It is purely an implementation detail: the current implementation of sunec in (upstream) OpenJDK violates the no-bundled-libraries packaging policy in Fedora. From a Fedora point of view, the right fix is to make OpenJDK 8 use the system nss libraries, just like how OpenJDK 7 (in Fedora) does it. But it hasn't been implemented yet for OpenJDK 8, so I chose to disable EC instead.

Will this bug be fixed? Right now I'm using Oracle JDK 1.7 that is working, but I would rather use the OpenJDK.

This bug breaks Zoho Meeting, one of the few webmeeting applications that you can host from Fedora  (http://meeting.zoho.com). 

I tried without success following the suggestions here by setting jdk.tls.disabledAlgorithms and then instead by rebuilding without the patch that disables sunec. 

I was able to get everything working using the Oracle JRE.

This is breaking us as well:

182817 [http-apr-8443-exec-4] INFO org.apache.commons.httpclient.HttpMethodDirector - I/O exception (javax.net.ssl.SSLException) caught when processing request: java.lang.RuntimeException: java.security.NoSuchAlgorithmException: EC AlgorithmParameters not available

This is when making an HTTP call to a partner REST service, example URL:

https://na1.secure.gooddata.com/gdc/account/customerlogin?sessionId

The server picks cipher TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 and the client barfs with the error above.

Note: if you try to test this, the request above shouldn't succeed but it should at least be able to negotiate the TLS connection.

We're on openjdk 1.8.0_31

This is breaking all of our Jboss (WildFly 8.2) servers. The SSL service is starting normally, server is listening on 8443 port, but the peer certificate is not available.

(root.local ~)# netstat -tulnp | grep java | grep 8443
tcp        0      0 0.0.0.0:8443                0.0.0.0:*                   LISTEN      21218/java          

(root.local ~)# openssl s_client -connect localhost:8443
CONNECTED(00000003)
140274105988936:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:744:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---

After adding the following line to java.security things are getting better.
security.provider.3=sun.security.ec.SunEC

No problems when using Oracle JDK.

After adding the following line to java.security things also working fine.
jdk.tls.disabledAlgorithms=EC,ECDHE,ECDH

Created attachment 999874 [details]
Jenkins debug log

I've attached debug log produced by Jenkins. Jenkins works correctly after adding lines from provious posts or starting it with the following parameter:
JENKINS_JAVA_OPTIONS="-Dcom.sun.net.ssl.enableECC=false" .

I've encountered this problem as well! Our workaround is to use the Oracle JRE. Unfortunately, the Oracle JRE has other issues building some of our software which otherwise works fine using the OpenJDK.

java-1.8.0-openjdk-1.8.0.40-23.b25.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21

Package java-1.8.0-openjdk-1.8.0.40-23.b25.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing java-1.8.0-openjdk-1.8.0.40-23.b25.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-4853/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21
then log in and leave karma (feedback).

java-1.8.0-openjdk-1.8.0.40-24.b25.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/java-1.8.0-openjdk-1.8.0.40-24.b25.fc21

The java.security file doesn't get properly replaced on upgrade, so this fix isn't automatically applied unless the user notices and manually replaces the java.security file with the one named java.security.rpmnew:

# dnf update ~/Download/java-1.8.0-openjdk-*
Using metadata from Fri Mar 27 11:37:56 2015
Dependencies resolved.
================================================================================
 Package                     Arch   Version                  Repository    Size
================================================================================
Upgrading:
 java-1.8.0-openjdk          x86_64 1:1.8.0.40-24.b25.fc21   @commandline 213 k
 java-1.8.0-openjdk-headless x86_64 1:1.8.0.40-24.b25.fc21   @commandline  31 M

Transaction Summary
================================================================================
Upgrade  2 Packages

Total size: 31 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
  Upgrading   : java-1.8.0-openjdk-headless-1:1.8.0.40-24.b25.fc21.x86_64   1/4 
warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-24.b25.fc21.x86_64/jre/lib/security/US_export_policy.jar created as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-24.b25.fc21.x86_64/jre/lib/security/US_export_policy.jar.rpmnew
warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-24.b25.fc21.x86_64/jre/lib/security/java.security created as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-24.b25.fc21.x86_64/jre/lib/security/java.security.rpmnew
warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-24.b25.fc21.x86_64/jre/lib/security/local_policy.jar created as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-24.b25.fc21.x86_64/jre/lib/security/local_policy.jar.rpmnew
  Upgrading   : java-1.8.0-openjdk-1:1.8.0.40-24.b25.fc21.x86_64            2/4 
  Cleanup     : java-1.8.0-openjdk-1:1.8.0.40-23.b25.fc21.x86_64            3/4 
  Cleanup     : java-1.8.0-openjdk-headless-1:1.8.0.40-23.b25.fc21.x86_64   4/4 
warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21.x86_64/jre/lib/security/local_policy.jar saved as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21.x86_64/jre/lib/security/local_policy.jar.rpmsave
warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21.x86_64/jre/lib/security/java.security saved as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21.x86_64/jre/lib/security/java.security.rpmsave
warning: /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21.x86_64/jre/lib/security/US_export_policy.jar saved as /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.40-23.b25.fc21.x86_64/jre/lib/security/US_export_policy.jar.rpmsave
  Verifying   : java-1.8.0-openjdk-1:1.8.0.40-24.b25.fc21.x86_64            1/4 
  Verifying   : java-1.8.0-openjdk-headless-1:1.8.0.40-24.b25.fc21.x86_64   2/4 
  Verifying   : java-1.8.0-openjdk-1:1.8.0.40-23.b25.fc21.x86_64            3/4 
  Verifying   : java-1.8.0-openjdk-headless-1:1.8.0.40-23.b25.fc21.x86_64   4/4 

Upgraded:
  java-1.8.0-openjdk.x86_64 1:1.8.0.40-24.b25.fc21                              
  java-1.8.0-openjdk-headless.x86_64 1:1.8.0.40-24.b25.fc21

(In reply to Fedora Update System from comment #37)
> java-1.8.0-openjdk-1.8.0.40-24.b25.fc21 has been submitted as an update for
> Fedora 21.
> https://admin.fedoraproject.org/updates/java-1.8.0-openjdk-1.8.0.40-24.b25.
> fc21

While I did not try this version as it was obsoleted by java-1.8.0-openjdk-1.8.0.40-24.b25.fc21; the latter fixes Jameica for me. Thank you.

doh! forgot to add
with renaming as per Comment 38

java-1.8.0-openjdk-1.8.0.40-24.b25.fc21 has been pushed to the Fedora 21 stable repository.  If problems still persist, please make note of it in this bug report.

On my Fedora 21 with OpenJDK:
openjdk version "1.8.0_40"
OpenJDK Runtime Environment (build 1.8.0_40-b25)
OpenJDK 64-Bit Server VM (build 25.40-b25, mixed mode)

I had problems with running Jetty with HTTP/2 protocol. It seems that new versions of Firefox implements h2-16 which requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher. This was not available with OpenJDK. I reported that on Jetty bugzilla: https://bugs.eclipse.org/bugs/show_bug.cgi?id=464144

When I switched to Oracle JDK my problem disappeared and I was able to work with HTTP/2 protocol using Jetty and Firefox.

(In reply to Omair Majid from comment #26)
> (In reply to Sven Anders from comment #24)
> > I'm not sure, if just disabling EC via the patch is just incomplete.
> 
> Yes, my "fix" for disabling EC was incomplete. It was based on what we did
> in OpenJDK 7, which seems to be insufficient for OpenJDK 8. Apologies.
> 
> > I had to disable the EC algorithms in 
> > 
> >  /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.25-5.b18.fc21.x86_64/jre/lib/security/
> > java.security
> > 
> > by adding the following line:
> > 
> >  jdk.tls.disabledAlgorithms=EC,ECDHE,ECDH
> > 
> > This way the problematic software (Jameica/Hibiscus), which wants to
> > establish a secure connection using EC, does work again.
> 
> Thanks for identifying this! I will make this the default.
> 
> > But I think do not understand correctly why the more secure EC algorithms
> > were disabled in the first place. Shouldn't we support the more secure 
> > algorithms? If it worked in the old versions, why were they disabled now?
> 
> It is purely an implementation detail: the current implementation of sunec
> in (upstream) OpenJDK violates the no-bundled-libraries packaging policy in
> Fedora. From a Fedora point of view, the right fix is to make OpenJDK 8 use
> the system nss libraries, just like how OpenJDK 7 (in Fedora) does it. But
> it hasn't been implemented yet for OpenJDK 8, so I chose to disable EC
> instead.

Can you please point me to the no-bundled-libraries packaging policy?
Is there an issue explaining in more detail the removal of SunEC provider in preference of NSS?

(In reply to Jaime Hablutzel from comment #43)
> Can you please point me to the no-bundled-libraries packaging policy?

https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

> Is there an issue explaining in more detail the removal of SunEC provider in
> preference of NSS?

Not really. Various issues, including the bundles of libraries, led us to choosing one of two options: remove SunEC provider (easy) or fix integration with NSS (which is hard, and no one has implemented it yet). I went with the first option. Once NSS integration is implemented, using that instead of SunEC would make much more sense.