Bug 1329342 - 1.8.0.91-1.b14.fc25 (OpenJDK April CPU) breaks EC ciphers
Summary: 1.8.0.91-1.b14.fc25 (OpenJDK April CPU) breaks EC ciphers
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: java-1.8.0-openjdk
Version: 24
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: jiri vanek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedFreezeException
Keywords: Reopened
: 1329909 1330163 (view as bug list)
Depends On:
Blocks: F24BetaFreezeException F24FinalBlocker
TreeView+ depends on / blocked
 
Reported: 2016-04-21 16:29 UTC by Kevin Fenzi
Modified: 2016-11-07 21:35 UTC (History)
20 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2016-05-03 18:06:15 UTC


Attachments (Terms of Use)

Description Kevin Fenzi 2016-04-21 16:29:37 UTC
With 1.8.0.77-2.b03.fc25.x86_64 zanata-cli works fine. If I upgrade to 1.8.0.91-1.b14.fc25 I get: 

[ERROR] Execution failed: 
com.sun.jersey.api.client.ClientHandlerException: javax.net.ssl.SSLException: java.security.ProviderException: java.security.KeyException
	at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:155)
	at org.zanata.rest.client.RedirectFilter.handle(RedirectFilter.java:45)
	at org.zanata.rest.client.ApiKeyHeaderFilter.handleNext(ApiKeyHeaderFilter.java:59)
	at org.zanata.rest.client.ApiKeyHeaderFilter.handle(ApiKeyHeaderFilter.java:54)
	at org.zanata.rest.client.AcceptTypeFilter.handle(AcceptTypeFilter.java:47)
	at org.zanata.rest.client.TraceDebugFilter.handle(TraceDebugFilter.java:60)
	at org.zanata.rest.client.InvalidContentTypeFilter.handle(InvalidContentTypeFilter.java:61)
	at com.sun.jersey.api.client.Client.handle(Client.java:652)
	at com.sun.jersey.api.client.WebResource.handle(WebResource.java:694)
	at com.sun.jersey.api.client.WebResource.get(WebResource.java:198)
	at org.zanata.rest.client.ProjectIterationLocalesClient.getLocales(ProjectIterationLocalesClient.java:54)
	at org.zanata.client.commands.OptionsUtil.fetchLocalesFromServer(OptionsUtil.java:114)
	at org.zanata.client.commands.OptionsUtil.applyConfigFiles(OptionsUtil.java:101)
	at org.zanata.client.commands.ArgsUtil.runCommand(ArgsUtil.java:41)
	at org.zanata.client.ZanataClient.processArgs(ZanataClient.java:170)
	at org.zanata.client.ZanataClient.main(ZanataClient.java:95)
Caused by: javax.net.ssl.SSLException: java.security.ProviderException: java.security.KeyException
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)
	at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1906)
	at sun.security.ssl.SSLSocketImpl.handleException(SSLSocketImpl.java:1889)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1410)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
	at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)
	at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1513)
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1441)
	at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:480)
	at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(HttpsURLConnectionImpl.java:338)
	at com.sun.jersey.client.urlconnection.URLConnectionClientHandler._invoke(URLConnectionClientHandler.java:253)
	at com.sun.jersey.client.urlconnection.URLConnectionClientHandler.handle(URLConnectionClientHandler.java:153)
	... 15 more
Caused by: java.security.ProviderException: java.security.KeyException
	at sun.security.ec.ECKeyPairGenerator.generateKeyPair(ECKeyPairGenerator.java:147)
	at java.security.KeyPairGenerator$Delegate.generateKeyPair(KeyPairGenerator.java:703)
	at sun.security.ssl.ECDHCrypt.<init>(ECDHCrypt.java:77)
	at sun.security.ssl.ClientHandshaker.serverKeyExchange(ClientHandshaker.java:721)
	at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:281)
	at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
	at sun.security.ssl.Handshaker.process_record(Handshaker.java:914)
	at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1062)
	at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
	at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
	... 24 more
Caused by: java.security.KeyException
	at sun.security.ec.ECKeyPairGenerator.generateECKeyPair(Native Method)
	at sun.security.ec.ECKeyPairGenerator.generateKeyPair(ECKeyPairGenerator.java:128)
	... 33 more

This may be a zanata-cli bug, feel free to move it if so, but it does seem to work or not based on the java version installed.

Comment 1 Severin Gehwolf 2016-04-21 17:11:09 UTC
How would we reproduce this? 1.8.0.91-1.b14 got some changes to crypto libs, but it's hard to tell from this stack trace only.

Comment 2 jiri vanek 2016-04-22 10:15:12 UTC
Eclipse hit it too:
https://paste.fedoraproject.org/358513/

Comment 3 jiri vanek 2016-04-22 10:18:34 UTC
Thats reproducible when you run eclipse updater

Comment 4 jiri vanek 2016-04-22 10:20:49 UTC
AFAIK jdk disabled few legacy algorithms, and when server can not use newer, then you got this exception. From top of my head, I'm now nto able to find them.

Comment 5 Severin Gehwolf 2016-04-22 10:34:24 UTC
(In reply to jiri vanek from comment #3)
> Thats reproducible when you run eclipse updater

This doesn't exactly help. We'd need a https URL which works before and no longer works after. Then we should have a reproducer.

Comment 6 jiri vanek 2016-04-22 10:38:46 UTC
Reproducer:

import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.net.URL;

/*
 * To change this license header, choose License Headers in Project Properties.
 * To change this template file, choose Tools | Templates
 * and open the template in the editor.
 */


/**
 *
 * @author jvanek
 */
public class HttpsCheck {

    static String[] urls = {
    "https://bugzilla.redhat.com/",
    "https://dl.bintray.com/fabioz/pydev/4.5.5/",
    "https://hudson.eclipse.org/cdt/job/launchbar-master/lastSuccessfulBuild/artifact/repo/target/repository"};
    
            public static void main(String[] args) throws Exception{
                for (String url : urls) {
                    URL u = new URL(url);
                    InputStream is = u.openStream();
                    BufferedReader bw = new BufferedReader(new InputStreamReader(is,"utf8"));
                    StringBuilder page = new StringBuilder();
                    while(true){
                        String s = bw.readLine();
                        if (s == null){
                            break;
                        }
                        page.append(s);
                    }
                    System.out.println(page.toString());
                }
    }
    
}

Comment 7 jiri vanek 2016-04-22 10:43:26 UTC
https://java.com/en/download/faq/release_changes.xml is mentioning only  MD5withRSA may it be so widespread?

Comment 8 jiri vanek 2016-04-22 10:47:04 UTC
java.security file is same as in u77

Comment 14 jiri vanek 2016-04-22 11:38:44 UTC
(In reply to jiri vanek from comment #13)
> However, the mentioned test IS included
> http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.
> 0-openjdk.spec#n817

ah.. is NOT run

> http://pkgs.fedoraproject.org/cgit/rpms/java-1.8.0-openjdk.git/tree/java-1.8.
> 0-openjdk.spec#n1390
> and 
> according to logs:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13734068

Comment 15 Severin Gehwolf 2016-04-22 16:25:55 UTC
It fails in EC_NewKey() on line 124[1] which in turn fails in ec_GenerateRandomPrivateKey()[2] which returns NULL:

    // Generate the new keypair (using the supplied seed)
    if (EC_NewKey(ecparams, &privKey, (unsigned char *) pSeedBuffer,
        jSeedLength, 0) != SECSuccess) {
        ThrowException(env, KEY_EXCEPTION);
        goto cleanup;
    }

[1] http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/file/0e757f8bf24c/src/share/native/sun/security/ec/ECC_JNI.cpp#l124
[2] http://hg.openjdk.java.net/aarch64-port/jdk8u/jdk/file/0e757f8bf24c/src/share/native/sun/security/ec/impl/ec.c#l383

Comment 16 Severin Gehwolf 2016-04-22 16:40:55 UTC
Sorry wrong sources. Those functions come from system nss, not openjdk. Can't find the links :(

Comment 18 Andrew John Hughes 2016-04-22 16:53:45 UTC
http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2934

I suggest removing Alex's patch for now:

Patch517: pr2899.patch

until we have a proper resolution. 

There is a test for this in the RPM. I suspect the disabling of this test has been wrongly synced across from RHEL 7.3 (which hasn't shipped yet) to Fedora.

Comment 19 Andrew John Hughes 2016-04-22 18:19:34 UTC
Ok, try this:

http://icedtea.classpath.org/hg/release/icedtea8-forest-3.0/jdk/rev/dab76de2f91c

It makes the ECDSATest pass locally.

$ /mnt/builder/icedtea-3.0/images/j2sdk-image/bin/java ECDSATest
Signature: 3046022100afd27e5b82c3b3e607e4a0568691e1e817672e45ed1f7f1f62f2273ad021aa8b0221008aceea3a84a688426aa34151c1d5abb385250d6fdfdd47c02f5a7c694d9939c1
Test passed.

Comment 20 Omair Majid 2016-04-22 20:05:14 UTC
In reply to Andrew John Hughes from comment #19)
> Ok, try this:
> 
> http://icedtea.classpath.org/hg/release/icedtea8-forest-3.0/jdk/rev/
> dab76de2f91c

I tried a scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13764668

The new patch being applied in the build log:

Patch #518 (pr2934-system-nss.patch):
+ echo 'Patch #518 (pr2934-system-nss.patch):'
+ /usr/bin/patch -p0 --fuzz=0
patching file openjdk/jdk/src/share/native/sun/security/ec/ECC_JNI.cpp
patching file openjdk/jdk/src/share/native/sun/security/ec/ecc_impl.h

The test result from the build log:
+ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/build/jdk8.build/images/j2sdk-image/bin/javac -d . /builddir/build/SOURCES/TestECDSA.java
++ sed 's|\.java||'
+++ basename /builddir/build/SOURCES/TestECDSA.java
++ echo TestECDSA.java
+ /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/build/jdk8.build/images/j2sdk-image/bin/java TestECDSA
Signature: 30460221008358fef430add1b9d4b0aa7c1ddf846b23271a9129c6d53b0127d9bbca4f3f46022100a2431012bf257898fe56a2e28032ccba521649ce67bb2c2b0536d998852e5b69
Test passed.

Should I add the patch in F22, F23, F24 and Rawhide?

Comment 21 Kevin Fenzi 2016-04-22 20:17:58 UTC
I can confirm that scratch build gets zanata-cli working again here. ;)

Comment 22 Andrew John Hughes 2016-04-23 23:05:07 UTC
> Should I add the patch in F22, F23, F24 and Rawhide?

Yeah, I've already added it in RHEL but can't commit to Fedora. Just backported the most recent rhel-7.3 changeset.

Comment 23 Andrew John Hughes 2016-04-23 23:05:43 UTC
(In reply to Andrew John Hughes from comment #22)
> > Should I add the patch in F22, F23, F24 and Rawhide?
> 
> Yeah, I've already added it in RHEL but can't commit to Fedora. Just
> backported the most recent rhel-7.3 changeset.

'backport' even... sigh.

Comment 24 jiri vanek 2016-04-24 09:11:39 UTC
(In reply to Omair Majid from comment #20)
> In reply to Andrew John Hughes from comment #19)
> > Ok, try this:
> > 
> > http://icedtea.classpath.org/hg/release/icedtea8-forest-3.0/jdk/rev/
> > dab76de2f91c
> 
> I tried a scratch build:
> http://koji.fedoraproject.org/koji/taskinfo?taskID=13764668
> 
> The new patch being applied in the build log:
> 
> Patch #518 (pr2934-system-nss.patch):
> + echo 'Patch #518 (pr2934-system-nss.patch):'
> + /usr/bin/patch -p0 --fuzz=0
> patching file openjdk/jdk/src/share/native/sun/security/ec/ECC_JNI.cpp
> patching file openjdk/jdk/src/share/native/sun/security/ec/ecc_impl.h
> 
> The test result from the build log:
> +
> /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/
> build/jdk8.build/images/j2sdk-image/bin/javac -d .
> /builddir/build/SOURCES/TestECDSA.java
> ++ sed 's|\.java||'
> +++ basename /builddir/build/SOURCES/TestECDSA.java
> ++ echo TestECDSA.java
> +
> /builddir/build/BUILD/java-1.8.0-openjdk-1.8.0.91-1.b14.fc23.i386/openjdk/
> build/jdk8.build/images/j2sdk-image/bin/java TestECDSA
> Signature:
> 30460221008358fef430add1b9d4b0aa7c1ddf846b23271a9129c6d53b0127d9bbca4f3f46022
> 100a2431012bf257898fe56a2e28032ccba521649ce67bb2c2b0536d998852e5b69
> Test passed.
> 
> Should I add the patch in F22, F23, F24 and Rawhide?

Patch is applied  and test enabled  in f22-f25. builds running

Comment 25 Fedora Update System 2016-04-24 16:51:35 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f7c893042

Comment 26 Fedora Update System 2016-04-24 17:00:11 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2016-c283d0e78e

Comment 27 Fedora Update System 2016-04-24 17:07:47 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5

Comment 28 Jonny Heggheim 2016-04-24 19:38:24 UTC
*** Bug 1329909 has been marked as a duplicate of this bug. ***

Comment 29 Jonny Heggheim 2016-04-24 19:41:14 UTC
FEDORA-2016-9f5172b1c5 fixed duplicate bug 1329909

Comment 30 Fedora Update System 2016-04-25 00:20:34 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-c283d0e78e

Comment 31 Fedora Update System 2016-04-25 00:22:43 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f7c893042

Comment 32 Robert Marcano 2016-04-25 14:21:55 UTC
*** Bug 1330163 has been marked as a duplicate of this bug. ***

Comment 33 Fedora Update System 2016-04-25 17:52:05 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5

Comment 34 Fedora Update System 2016-04-25 22:20:19 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

Comment 35 Fedora Update System 2016-04-25 23:51:39 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

Comment 36 jiri vanek 2016-04-26 12:55:05 UTC
Reopening for f24

Comment 37 jiri vanek 2016-04-26 12:59:43 UTC
Hello, please push ​https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5 to stable. java-1.8.0-openjdk-1.8.0.91-1.b14.fc24 was nearly uusable, and -2. is fixing the issue (As seen form karmas for f23 and also f24

Comment 38 jiri vanek 2016-04-26 13:09:57 UTC
(In reply to jiri vanek from comment #37)
> Hello, please push
> ​https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5 to stable.
> java-1.8.0-openjdk-1.8.0.91-1.b14.fc24 was nearly uusable, and -2. is fixing
> the issue (As seen form karmas for f23 and also f24

More verbose - this update is fixin bug in previous update which is making most https connections broken. So any java deplyment (tomcat and spol) canbe moreover considered as dead. 
Of course also client apps like sqriell or similar are doomed with https.

Comment 39 Kamil Páral 2016-04-26 13:33:44 UTC
We have openjdk on Workstation Live, libreoffice depends on it (not sure whether libreoffice uses java for accessing https urls). We also have openjdk in Server repo, but after installation it is not installed, so Server doesn't seem to depend on it.

Comment 40 Kamil Páral 2016-04-26 13:47:45 UTC
(In reply to Kamil Páral from comment #39)
> We also have
> openjdk in Server repo, but after installation it is not installed, so
> Server doesn't seem to depend on it.

I was wrong, I forgot to install all addons. If you install all addons, there are many things depending on openjdk, like tomcat, pki-ca, freeipa-server, glassfish, etc.

Comment 41 jiri vanek 2016-04-26 14:35:25 UTC
Most of those addons  may suffer by this issue.

Comment 42 Adam Williamson 2016-04-26 16:16:10 UTC
This was not considered as a blocker because the dependency was done the wrong way round - this bug was set to *depend on* the tracker, rather than block it. Fixing.

Comment 43 Dennis Gilmore 2016-04-27 16:54:48 UTC
+1 FE, I am not sure what blocking criteria it violates, but would be good to fix

Comment 44 Mairi Dulaney 2016-04-27 18:14:56 UTC
I'm also +1 FE; I don't quite see it hitting a release criteria.

Comment 45 Andrew John Hughes 2016-04-27 18:58:19 UTC
It's fixed as far as I know.

https://bodhi.fedoraproject.org/updates/FEDORA-2016-9f5172b1c5

Comment 46 Adam Williamson 2016-04-27 19:17:02 UTC
That update is in updates-testing, which means it would not be included in Beta composes. The blocker/freeze exception review process exists to decide what fixes *must* and *can* be pushed to stable and included in composes during the freeze period. That is what we're voting about.

https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process

Comment 47 Adam Williamson 2016-04-27 19:19:35 UTC
I also am +1 FE, -1 Blocker, +1 Final blocker. The relevant criterion is Final:

"The release must contain no known security bugs of 'important' or higher impact according to the Red Hat severity classification scale which cannot be satisfactorily resolved by a package update (e.g. issues during installation)." - https://fedoraproject.org/wiki/Fedora_24_Final_Release_Criteria#Security_bugs

there is no corresponding Beta criterion. That's +3 FE, -3 blocker, so setting that status.

Comment 48 Tim Flink 2016-05-02 22:07:30 UTC
Discussed during the 2016-05-02 blocker review meeting.

The decision on final blocker status has been delayed because we expect this to be closed soon as the fix was included in the last beta compose as an FE and the update has sufficient karma to be pushed stable.

Comment 49 Fedora Update System 2016-05-03 18:06:05 UTC
java-1.8.0-openjdk-1.8.0.91-2.b14.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

Comment 50 Oliver 2016-10-25 13:10:19 UTC
Is this problem also fixed in RedHat Server versions? How can i figure this out? Thanks for helping.

Comment 51 Andrew John Hughes 2016-10-26 02:57:36 UTC
Yes, see comment #22.

Comment 52 Oliver 2016-10-26 08:06:34 UTC
Andrew thanks for your time, i apologize already in advance but I've got no clue how to figure out in which patch of RHEL this bug is fixed. We have experienced this on one of our systems months ago and are unsure which version we have to upgrade to in order to resolve this.

In Fedora i would assume from what i can read from this bug report that it was fixed immediately. Is it the same in Redhat? (they cycle packages slower right?)

Comment 53 Andrew John Hughes 2016-10-27 01:18:15 UTC
RHEL java-1.8.0-openjdk packages are updated at least four times a year for the security updates (Jan, Apr, Jul and Oct). The Fedora packages feed from the RHEL ones, though that includes stuff for the next RHEL releases, so it will appear in Fedora first, even though it was applied to RHEL spec file beforehand (if that make sense).

There is no ECC support yet in RHEL 7. This is coming with RHEL 7.3, where this patch has been applied.

For RHEL 6, ECC support appeared in RHEL 6.8 but it seems this patch hasn't yet been included, which I hadn't realised until now, so thanks for raising this. I'll make sure that gets in for the January update at the latest.

Hope that helps.

Comment 54 Oliver 2016-10-27 09:06:51 UTC
Thank you Andrew, that clears up my picture. We have 6.8 so that makes totally sense. We will check in January for the package.

Comment 55 daba 2016-11-02 15:35:47 UTC
(In reply to Andrew John Hughes from comment #53)
> RHEL java-1.8.0-openjdk packages are updated at least four times a year for
> the security updates (Jan, Apr, Jul and Oct). The Fedora packages feed from
> the RHEL ones, though that includes stuff for the next RHEL releases, so it
> will appear in Fedora first, even though it was applied to RHEL spec file
> beforehand (if that make sense).
> 
> There is no ECC support yet in RHEL 7. This is coming with RHEL 7.3, where
> this patch has been applied.
> 
> For RHEL 6, ECC support appeared in RHEL 6.8 but it seems this patch hasn't
> yet been included, which I hadn't realised until now, so thanks for raising
> this. I'll make sure that gets in for the January update at the latest.
> 
> Hope that helps.

Thank you Andrew for the info.

Currently several of our redhat servers can only support TLS_RSA* ciphers. Our security has flagged with several vulnerabilities.

/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.x86_64/jre/lib/security/java.security

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC, ECDHE, ECDH

Not sure how other enterprise installs are dealing without ECC in openjdk8?

I removed last three ciphers in the above disabled list and put below config and it seems to work with limited testing and no errors in catalina. Our team is pondering over this workaround on a production systems.

sslEnabledProtocols="TLSv1.2"
ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA

256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECD

H_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_A

ES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS

_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,TLS_DHE_RSA_WITH_AES_256_CB

C_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA"

Comment 56 daba 2016-11-02 16:15:15 UTC
(In reply to daba from comment #55)
> (In reply to Andrew John Hughes from comment #53)
> > RHEL java-1.8.0-openjdk packages are updated at least four times a year for
> > the security updates (Jan, Apr, Jul and Oct). The Fedora packages feed from
> > the RHEL ones, though that includes stuff for the next RHEL releases, so it
> > will appear in Fedora first, even though it was applied to RHEL spec file
> > beforehand (if that make sense).
> > 
> > There is no ECC support yet in RHEL 7. This is coming with RHEL 7.3, where
> > this patch has been applied.
> > 
> > For RHEL 6, ECC support appeared in RHEL 6.8 but it seems this patch hasn't
> > yet been included, which I hadn't realised until now, so thanks for raising
> > this. I'll make sure that gets in for the January update at the latest.
> > 
> > Hope that helps.
> 
> Thank you Andrew for the info.
> 
> Currently several of our redhat servers can only support TLS_RSA* ciphers.
> Our security has flagged with several vulnerabilities.
> 
> /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.111-1.b15.el7_2.x86_64/jre/lib/
> security/java.security
> 
> jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC,
> ECDHE, ECDH
> 
> Not sure how other enterprise installs are dealing without ECC in openjdk8?
> 
> I removed last three ciphers in the above disabled list and put below config
> and it seems to work with limited testing and no errors in catalina. Our
> team is pondering over this workaround on a production systems.
> 
> sslEnabledProtocols="TLSv1.2"
> ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384,
> TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA
> 
> 256,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA,TLS_ECD
> 
> H_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
> TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_A
> 
> ES_128_CBC_SHA,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA,TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS
> 
> _DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_256_GCM_SHA384,
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
> TLS_DHE_RSA_WITH_AES_256_CB
> 
> C_SHA256,TLS_DHE_DSS_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA"

Sorry....just got report that above ciphers are failing on several machines so the workaround is useless. Back to square one of only using TLS_RSA*ciphers.

Comment 57 Andrew John Hughes 2016-11-03 18:16:26 UTC
On RHEL 7.2, EC, ECDHE and ECDH are disabled because there is no elliptic curve cryptography provider. Enabling them won't magically make one appear. This is resolved in RHEL 7.3.

Major additions like this need sufficient testing, so can only really happen in feature releases.

Comment 58 daba 2016-11-05 01:09:10 UTC
Andrew, with yum update  we got openjdk-1.8.0.111-2.b15.el7_3.x86_64 over existing openjdk-1.8.0.111-1.b15.el7_2.x86_64.  After restart the issue persisted.

Noticed ..usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.111-2.b15.el7_3.x86_64/lib/security has two files….

java.security --jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, EC, ECDHE, ECDH

java.security.rpmnew -- jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768


I made the .rpmnew as the java.security file...and this seems to have fixed the issue. Chrome on windows reports "The connection to this site is encrypted and authenticated using a strong protocol (TLS 1.2), a strong key exchange (ECDHE_RSA), and a strong cipher (AES_256_GCM)". 

Are the changes expected for java.security.rpmnew to enable ECC instead of out of the box RHEL 7.3 update?

Thank you!

Comment 59 Andrew John Hughes 2016-11-07 21:35:56 UTC
java.security.rpmnew is what should be used and it should have been automatically copied over, if java.security was unchanged.

However, this hasn't happened in this case. It seems to be a consequence of the security update for RHEL 7.2 being applied. The 7.3 RPM was actually produced first, so it isn't aware of the checksum used in the RHEL 7.2 security RPM and so it can't determine that the java.security file you have installed from that RPM is an unchanged RPM copy rather than one you've modified yourself.

The next update will make sure that the 7.2 one is replaced by the version from the 7.3 RPM, but for now, it will have to be manually copied over, as you did.


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