Bug 1022017 - OpenJDK should report the elliptic curves supported by NSS, not the SunEC library
OpenJDK should report the elliptic curves supported by NSS, not the SunEC lib...
Status: VERIFIED
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: java-1.8.0-openjdk (Show other bugs)
6.5
Unspecified Linux
high Severity urgent
: rc
: 6.5
Assigned To: Andrew John Hughes
Lukas Zachar
: Reopened, ZStream
Depends On:
Blocks: 1361283 1010111 1028028 1348525
  Show dependency treegraph
 
Reported: 2013-10-22 09:42 EDT by Jesus M. Rodriguez
Modified: 2016-12-02 05:41 EST (History)
16 users (show)

See Also:
Fixed In Version: java-1.8.0-openjdk-1.8.0.91-2.b14.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1028028 1348525 (view as bug list)
Environment:
Last Closed: 2014-04-09 13:48:45 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SSL debug from tomcat6's catalina.out (5.71 KB, text/plain)
2013-10-22 09:42 EDT, Jesus M. Rodriguez
no flags Details
Specify only the three supported curves (1.55 KB, patch)
2013-11-07 07:51 EST, Andrew John Hughes
no flags Details | Diff
SSL debug from tomcat6 for comment #26 (10.89 KB, text/plain)
2013-11-12 10:57 EST, Jesus M. Rodriguez
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Icedtea Bugzilla 1834 None None None 2016-06-20 23:23 EDT

  None (edit)
Description Jesus M. Rodriguez 2013-10-22 09:42:23 EDT
Created attachment 815006 [details]
SSL debug from tomcat6's catalina.out

Description of problem:
Using RHEL 6.5, tomcat6 and java-1.7.0-openjdk, I get the following exception in the catalina.out:

%% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]
matching alias: tomcat
http-8443-1, handling exception: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
%% Invalidated:  [Session-1, SSL_NULL_WITH_NULL_NULL]

The client gets an SSL error. If I use java-1.6.0 the problem goes away. If I used the java.security and nss.cfg from java-1.60 with java-1.7.0 it works fine as well.

This is *not* a problem with java-1.7.0-1.7.0.60 on Fedora 18 or 19. Looking in dist-git we enabled nss for RHEL 6.5:

%global enable_nss 1

That is the only difference I have found between the JREs.

Version-Release number of selected component (if applicable):

I have tried both version of the jdk with no success.

java-1.7.0-openjdk-1.7.0.40-2.4.2.5.el6.x86_64
java-1.7.0-openjdk-1.7.0.45-2.4.3.0.el6.x86_64
nss-softokn-freebl-3.14.3-9.el6.x86_64
nss-util-3.15.1-3.el6.x86_64
mod_dnssd-0.6-2.el6.x86_64
python-nss-0.13-1.el6.x86_64
openssl-1.0.1e-15.el6.x86_64
openssh-askpass-5.3p1-94.el6.x86_64
openssl-devel-1.0.1e-15.el6.x86_64
openssh-server-5.3p1-94.el6.x86_64
openssh-clients-5.3p1-94.el6.x86_64
nss-3.15.1-15.el6.x86_64
nss-tools-3.15.1-15.el6.x86_64
openssh-5.3p1-94.el6.x86_64
nss-softokn-3.14.3-9.el6.x86_64
nss-sysinit-3.15.1-15.el6.x86_64

How reproducible:
On my RHEL 6.5 guest with the above rpm versions, I can recreate it at will.

Steps to Reproduce:
1. Installed RHEL 6.5
2. Ensure java-1.7.0-openjdk is installed
3. Install Subscription Asset Manager (SAM) 1.3
4. try to connect using rest-client
4a. scl enable ruby193 'irb'
4b. > require 'rest-client'
4c. > RestClient.get("https://localhost:8443/candlepin/status")

Actual results:
client gets an error.

OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert internal error
        from /opt/rh/ruby193/root/usr/share/ruby/net/http.rb:800:in `connect'

Tomcat spews out:
%% Initialized:  [Session-1, SSL_NULL_WITH_NULL_NULL]
http-8443-1, handling exception: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
%% Invalidated:  [Session-1, SSL_NULL_WITH_NULL_NULL]


Expected results:
The JSON output from the Candlepin java app. Like I said above if I switch to java-1.6 or use the configs from 1.6 with java-1.7, it works fine.

Additional info:
Comment 1 Jesus M. Rodriguez 2013-10-22 09:44:05 EDT
This came about while investigating BZ 1010111
Comment 2 Deepak Bhole 2013-10-22 10:00:26 EDT
Assigning to Andrew to take a look.
Comment 3 Deepak Bhole 2013-10-24 13:36:04 EDT
Hi Jesus, can you try a workaround while we try to fix this issue?

You need to edit /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.45.x86_64/jre/lib/security/java.security

In there, change the priorities to make sun.security.provider.Sun #1 and so on i.e. change:

security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
security.provider.2=sun.security.provider.Sun
security.provider.3=sun.security.rsa.SunRsaSign
...
...
security.provider.10=sun.security.smartcardio.SunPCSC

to:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
...
...
security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
Comment 5 Jesus M. Rodriguez 2013-10-25 11:07:33 EDT
(In reply to Deepak Bhole from comment #3)
> Hi Jesus, can you try a workaround while we try to fix this issue?
> 
> You need to edit
> /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.45.x86_64/jre/lib/security/java.
> security
> 
> In there, change the priorities to make sun.security.provider.Sun #1 and so
> on i.e. change:
> 
> security.provider.1=sun.security.pkcs11.SunPKCS11
> ${java.home}/lib/security/nss.cfg
> security.provider.2=sun.security.provider.Sun
> security.provider.3=sun.security.rsa.SunRsaSign
> ...
> ...
> security.provider.10=sun.security.smartcardio.SunPCSC
> 
> to:
> 
> security.provider.1=sun.security.provider.Sun
> security.provider.2=sun.security.rsa.SunRsaSign
> ...
> ...
> security.provider.10=sun.security.pkcs11.SunPKCS11
> ${java.home}/lib/security/nss.cfg

my java.security now has the following:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

Same error:

%% Initialized:  [Session-4, SSL_NULL_WITH_NULL_NULL]
http-8443-2, handling exception: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
%% Invalidated:  [Session-4, SSL_NULL_WITH_NULL_NULL]
Comment 6 Andrew John Hughes 2013-10-25 13:01:05 EDT
Yes, CKR_DOMAIN_PARAMS_INVALID is an error coming from NSS, not OpenJDK.

Jesus, what happens if you remove the security.provider.10 line altogether?
Comment 7 Jesus M. Rodriguez 2013-10-25 14:18:01 EDT
Using the following providers in java.security:

security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=sun.security.ec.SunEC
security.provider.4=com.sun.net.ssl.internal.ssl.Provider
security.provider.5=com.sun.crypto.provider.SunJCE
security.provider.6=sun.security.jgss.SunProvider
security.provider.7=com.sun.security.sasl.Provider
security.provider.8=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.9=sun.security.smartcardio.SunPCSC
# the NSS security provider was not enabled for this build; it can be enabled
# if NSS (libnss3) is available on the machine. The nss.cfg file may need
# editing to reflect the location of the NSS installation.
#security.provider.1=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

I no longer get the CKR_DOMAIN_PARAMS_INVALID:

%% Initialized:  [Session-4, SSL_NULL_WITH_NULL_NULL]
%% Negotiating:  [Session-4, TLS_RSA_WITH_AES_256_CBC_SHA]
*** ServerHello, TLSv1.2

And when I connect with RestClient I get the actual JSON response I expected:

RestClient.get("https://localhost:8443/candlepin/status")
=> "{\"result\":true,\"version\":\"0.8.26\",\"rulesVersion\":\"4.2\",\"release\":\"1\",\"standalone\":true,\"timeUTC\":\"2013-10-25T18:17:16.391+0000\",\"managerCapabilities\":[\"cores\",\"ram\",\"instance_multiplier\",\"derived_product\",\"cert_v3\"],\"rulesSource\":\"DEFAULT\"}"
Comment 8 Andrew John Hughes 2013-10-25 16:40:46 EDT
Interesting.  What is happening here is the following:

1.  The client tries to get a crypto provider that supports SSL_NULL_WITH_NULL_NULL.
2.  If the NSS provider is not present, no provider responds to this request and the client requests TLS_RSA_WITH_AES_256_CBC_SHA instead.
3.  If the NSS provider is present, instead of saying it doesn't support the algorithm it throws an exception which is carried up to the client.

So the NSS provider is giving the wrong response.
Comment 9 Deepak Bhole 2013-10-25 17:32:54 EDT
So is this a bug in NSS then, or do you mean NSS provider as in OpenJDK code that interfaces with NSS that is misinterpreting what low-level NSS libraries are saying?
Comment 10 Andrew John Hughes 2013-10-25 17:46:48 EDT
Seems like the latter, but I won't know 100% until I have time to look into this fully.
Comment 16 Andrew John Hughes 2013-11-05 22:11:37 EST
I think https://bugzilla.redhat.com/show_bug.cgi?id=1022950 is related, if not the same issue.

This is the difference on Jesus' machine when the PKCS11 NSS provider is enabled and when it isn't:

+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 TLS_RSA_WITH_AES_256_CBC_SHA256
+TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
+TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
+TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
 TLS_RSA_WITH_AES_256_CBC_SHA
+TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
+TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
 TLS_DHE_RSA_WITH_AES_256_CBC_SHA
 TLS_DHE_DSS_WITH_AES_256_CBC_SHA
+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
 TLS_RSA_WITH_AES_128_CBC_SHA256
+TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
+TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
+TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
 TLS_RSA_WITH_AES_128_CBC_SHA
+TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
+TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
 TLS_DHE_RSA_WITH_AES_128_CBC_SHA
 TLS_DHE_DSS_WITH_AES_128_CBC_SHA
+TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
+TLS_ECDHE_RSA_WITH_RC4_128_SHA
 SSL_RSA_WITH_RC4_128_SHA
+TLS_ECDH_ECDSA_WITH_RC4_128_SHA
+TLS_ECDH_RSA_WITH_RC4_128_SHA
+TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
+TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
 SSL_RSA_WITH_3DES_EDE_CBC_SHA
+TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
+TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
 SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
 SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
 SSL_RSA_WITH_RC4_128_MD5
 TLS_EMPTY_RENEGOTIATION_INFO_SCSV
 TLS_DH_anon_WITH_AES_256_CBC_SHA256
+TLS_ECDH_anon_WITH_AES_256_CBC_SHA
 TLS_DH_anon_WITH_AES_256_CBC_SHA
 TLS_DH_anon_WITH_AES_128_CBC_SHA256
+TLS_ECDH_anon_WITH_AES_128_CBC_SHA
 TLS_DH_anon_WITH_AES_128_CBC_SHA
+TLS_ECDH_anon_WITH_RC4_128_SHA
 SSL_DH_anon_WITH_RC4_128_MD5
+TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
 SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
 TLS_RSA_WITH_NULL_SHA256
+TLS_ECDHE_ECDSA_WITH_NULL_SHA
+TLS_ECDHE_RSA_WITH_NULL_SHA
 SSL_RSA_WITH_NULL_SHA
+TLS_ECDH_ECDSA_WITH_NULL_SHA
+TLS_ECDH_RSA_WITH_NULL_SHA
+TLS_ECDH_anon_WITH_NULL_SHA
 SSL_RSA_WITH_NULL_MD5
 SSL_RSA_WITH_DES_CBC_SHA
 SSL_DHE_RSA_WITH_DES_CBC_SHA

So, with it enabled, the SSL connection is trying to use TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 and failing because NSS doesn't actually support it.

I didn't get the ECC algorithms on my local RHEL machine (latest 6.4).  Has there been a change in NSS?
Comment 17 Andrew John Hughes 2013-11-05 22:33:45 EST
* Sun May 26 2013 Elio Maldonado <emaldona@redhat.com> - 3.14.3-5
- Syncup with uptream changes for aes gcm and ecc suiteb
- Enable ecc support for suite b
- Apply several upstream AES GCM fixes
- Use the pristine nss upstream sources with ecc included
- Export NSS_ENABLE_ECC=1 in both the build and the check sections
- Make failed requests for unsupoprted ssl pkcs 11 bypass non fatal
- Resolves: rhbz#882408 - NSS_NO_PKCS11_BYPASS must preserve ABI
- Related:  rhbz#918950  - rebase nss to 3.14.3

6.4 is on 3.14.3-4, the change before the above.
6.5 is on 3.15.1-15, so includes the above.
Comment 18 Hubert Kario 2013-11-06 04:59:27 EST
(In reply to Andrew John Hughes from comment #16)
> I think https://bugzilla.redhat.com/show_bug.cgi?id=1022950 is related, if
> not the same issue.
> 
> This is the difference on Jesus' machine when the PKCS11 NSS provider is
> enabled and when it isn't:
> 
>[snip]
> 
> So, with it enabled, the SSL connection is trying to use
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 and failing because NSS doesn't
> actually support it.
> 
> I didn't get the ECC algorithms on my local RHEL machine (latest 6.4).  Has
> there been a change in NSS?

yes, NSS in 6.5 introduced support for TLSv1.2 and ECC.
But the support is not complete.

In case of TLSv1.2 two features are not supported:
 * GCM
 * SHA384 as MAC
In case of ECC, only three curves are supported: nistp256, nistp384, nistp521.

so TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 won't work
Comment 19 Andrew John Hughes 2013-11-06 22:19:14 EST
Yeah, that's what I just worked out, tracing through the code :)

Can you tell us which of the additions in the list above should work, if any?  It looks like we're going to need to find where this list is created and patch out the ones our NSS doesn't support.

We came across an issue with the curves before.  Oracle's upstream test cases for this provider expect additional curves.  See:

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=469
Comment 20 Hubert Kario 2013-11-07 06:20:17 EST
There are basically only four suites that won't work:

> +TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
> +TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
> +TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
> +TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384

rest of additions should work.
Comment 21 Andrew John Hughes 2013-11-07 07:51:22 EST
Created attachment 821065 [details]
Specify only the three supported curves

The attached patch should resolve the issue.

Looking at the code, I don't think NSS is being used for its TLS 1.2 implementation at all:

"* TLS 1.2 uses a different hash algorithm than 1.0/1.1 for the PRF calculations.  As of 2010, there is no PKCS11-level support for TLS 1.2 PRF calculations, and no known OS's have an internal variant we could use.  Therefore for TLS 1.2, we are updating JSSE to request different provider algorithms (e.g. "SunTls12Prf"), and currently only SunJCE has these TLS 1.2 algorithms. If we reused the names such as "SunTlsPrf", the PKCS11 providers would need be updated to fail correctly when presented with the wrong version number (via Provider.Service.supportsParameters()), and we would also need to add the appropriate supportsParamters() checks into KeyGenerators (not currently there).In the future, if PKCS11 support is added, we will restructure this."

                                                                           
which is where the mismatch occurs.  Instead of probing providers for which curves they support, the OpenJDK TLS code hardcodes a set list and uses that in its implementation of the Hello ECC curves extension.

The fix just cuts that list down to the three NSS curves.  I don't know why this wasn't designed so as to use an API to ask providers for the curves they support.  We obviously can't add it to 7 now.
Comment 22 Andrew John Hughes 2013-11-07 11:24:19 EST
Why did you change the assignment?
Comment 25 Jesus M. Rodriguez 2013-11-12 10:53:09 EST
As Lukas mentioned above, using the java from comment #23, java-1.7.0-openjdk-1.7.0.45-2.4.3.4.el6.x86_64 I get:

candlepin      FAIL   SSL_connect returned=1 errno=0 state=SSLv3 read server key exchange B: EC lib 
candlepin_auth FAIL   SSL_connect returned=1 errno=0 state=SSLv3 read server key exchange B: EC lib 


This is slightly different than the *old* message which was a generic tlsv1 internal error:

candlepin      FAIL   SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert internal error 
candlepin_auth FAIL   SSL_connect returned=1 errno=0 state=SSLv2/v3 read server hello A: tlsv1 alert internal error
Comment 26 Jesus M. Rodriguez 2013-11-12 10:54:56 EST
Using the RestClient method I get the following:

# scl enable ruby193 'irb'
irb> require 'rest-client'
irb> RestClient.get("https://localhost:8443/candlepin/status")
OpenSSL::SSL::SSLError: SSL_connect returned=1 errno=0 state=SSLv3 read server key exchange B: EC lib
Comment 27 Jesus M. Rodriguez 2013-11-12 10:57:31 EST
Created attachment 823039 [details]
SSL debug from tomcat6 for comment #26

The third attachment contains the SSL debug from tomcat for the comment run on comment #26.
Comment 28 Andrew John Hughes 2013-11-12 12:45:15 EST
I'm a little baffled that this:

Extension elliptic_curves, curve names: {sect571r1, sect571k1, secp521r1, sect409k1, sect409r1, secp384r1, sect283k1, sect283r1, secp256k1, secp256r1, sect239k1, sect233k1, sect233r1, secp224k1, secp224r1, sect193r1, sect193r2, secp192k1, secp192r1, sect163k1, sect163r1, sect163r2, secp160k1, secp160r1, secp160r2}

is still present in the output.  Is this definitely from the current run?  Have both the server and client been restarted?
Comment 29 Jesus M. Rodriguez 2013-11-12 13:48:44 EST
(In reply to Andrew John Hughes from comment #28)
> I'm a little baffled that this:
> 
> Extension elliptic_curves, curve names: {sect571r1, sect571k1, secp521r1,
> sect409k1, sect409r1, secp384r1, sect283k1, sect283r1, secp256k1, secp256r1,
> sect239k1, sect233k1, sect233r1, secp224k1, secp224r1, sect193r1, sect193r2,
> secp192k1, secp192r1, sect163k1, sect163r1, sect163r2, secp160k1, secp160r1,
> secp160r2}
> 
> is still present in the output.  Is this definitely from the current run? 
> Have both the server and client been restarted?

Yeah, I rebooted the machine completely. Same result.

java -version
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.4.el6-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)

rpm -q nss
nss-3.15.1-15.el6.x86_64
Comment 30 Andrew John Hughes 2013-11-13 11:36:32 EST
Yeah, I don't think that's the cause, just wondering why it shows up.

Once I can upgrade to 6.5, I'll start testing/debugging this locally.
Comment 31 Andrew John Hughes 2013-11-27 11:31:10 EST
Ok, I have 6.5 now (after updating nearly broke my entire install...) but:

]# yum install katello-headpin-all
Loaded plugins: auto-update-debuginfo, presto, product-id, refresh-packagekit, security, subscription-manager
This system is receiving updates from Red Hat Subscription Management.
Setting up Install Process
No package katello-headpin-all available.

Is there an extra repo I need for this?
Comment 34 Andrew John Hughes 2013-11-27 19:04:24 EST
# /usr/bin/java -version
java version "1.7.0_45"
OpenJDK Runtime Environment (rhel-2.4.3.3.el6-x86_64 u45-b15)
OpenJDK 64-Bit Server VM (build 24.45-b08, mixed mode)

# scl enable ruby193 'irb'
irb(main):001:0> require 'rest-client'
=> true
irb(main):002:0> RestClient.get("https://localhost:8443/candlepin/status")
=> "{\"result\":true,\"version\":\"0.8.26\",\"rulesVersion\":\"4.2\",\"release\":\"1\",\"standalone\":true,\"timeUTC\":\"2013-11-28T00:00:16.894+0000\",\"managerCapabilities\":[\"cores\",\"ram\",\"instance_multiplier\",\"derived_product\",\"cert_v3\"],\"rulesSource\":\"DEFAULT\"}"

# rpm -q nss
nss-3.15.1-15.el6.x86_64

# rpm -q java-1.7.0-openjdk
java-1.7.0-openjdk-1.7.0.45-2.4.3.3.el6.x86_64

I'm not seeing the error.
Comment 36 Andrew John Hughes 2013-12-02 11:58:45 EST
I've managed to reproduce it on there too, but I can't see any obvious differences.  It's mystifying.

Are both ends of the transmission Java clients?  I did notice that lsof shows postgres, sendmail, cups and ssh to have references to a deleted version of NSS.

If anyone has a simpler reproducer, it would be very welcome :)

As a workaround, there is a property we could change the default of and thus turn off ECC.  Thoughts?
Comment 37 Andrew John Hughes 2013-12-04 09:07:03 EST
Ok, I'm pretty sure I've found the issue here and it's nothing to do with either Java or even NSS.

I can access the URL fine on  both machines with wget and curl.  The same issue I patched earlier has also been fixed in OpenSSL (used by your ruby client) recently:

* Thu Oct 31 2013 Tomáš Mráz <tmraz@redhat.com> 1.0.1e-16
- do not advertise ECC curves we do not support
- fix CPU identification on Cyrix CPUs

My box:

Name        : openssl                      Relocations: (not relocatable)
Version     : 1.0.1e                            Vendor: Red Hat, Inc.
Release     : 16.el6_5                      Build Date: Mon 04 Nov 2013 16:10:09 GMT

Box from Lukas:

Name        : openssl                      Relocations: (not relocatable)
Version     : 1.0.1e                            Vendor: Red Hat, Inc.
Release     : 15.el6                        Build Date: Fri 27 Sep 2013 10:13:23 EDT

After a yum upgrade of openssl, surprise, surprise...

irb(main):001:0> require 'rest-client'
=> true
irb(main):002:0> RestClient.get("https://localhost:8443/candlepin/status")
=> "{\"result\":true,\"version\":\"0.8.26\",\"rulesVersion\":\"4.2\",\"release\":\"1\",\"standalone\":true,\"timeUTC\":\"2013-12-04T14:06:23.328+0000\",\"managerCapabilities\":[\"cores\",\"ram\",\"instance_multiplier\",\"derived_product\",\"cert_v3\"],\"rulesSource\":\"DEFAULT\"}"
Comment 38 Andrew John Hughes 2013-12-04 09:11:17 EST
i.e. basically your OpenSSL implementation was saying it supports nist512 when it doesn't.  Thus, when the Java side sent it data encrypted with a nist512 curve, it failed.
Comment 39 Deepak Bhole 2013-12-04 16:35:07 EST
Jesus, can you confirm that everything works now on your end with the new OpenSSL? If so, we will close this issue as NOTABUG.
Comment 40 Andrew John Hughes 2013-12-05 08:08:59 EST
Deepak, there was still a bug to begin with.  It just means our patch did fix it.
Comment 41 Deepak Bhole 2013-12-05 11:29:22 EST
(In reply to Andrew John Hughes from comment #40)
> Deepak, there was still a bug to begin with.  It just means our patch did
> fix it.

Ah, right, sorry.

Jesus, if this works for you then, can you please close it as CURRENTRELEASE?
Comment 44 Andrew John Hughes 2013-12-18 13:00:26 EST
Yes that is correct.  The patch changes it to the shorter output to match NSS.
Comment 46 rhbugzilla.5.nebuchadnezar 2014-01-26 18:21:55 EST
Could you guys please send the bugfix, or a link to this bugreport to the openssl guys? Your bugfix is quite worthless to the rest of the world if you don't report this bug upstream and keeping the fix to yourselves. I had to disable nss via. the java.security file in order to use mcabber with my jabber server, because I had this exact exception on a debian box with openfire running on top of it.
Comment 47 Deepak Bhole 2014-01-28 10:57:57 EST
(In reply to rhbugzilla.5.nebuchadnezar from comment #46)
> Could you guys please send the bugfix, or a link to this bugreport to the
> openssl guys? Your bugfix is quite worthless to the rest of the world if you
> don't report this bug upstream and keeping the fix to yourselves. I had to
> disable nss via. the java.security file in order to use mcabber with my
> jabber server, because I had this exact exception on a debian box with
> openfire running on top of it.

The fix is not applicable to upstream. Upstream does does not remove support for certain Elliptic Curves. That is something specific to RHEL packages.
Comment 48 Andrew John Hughes 2014-01-28 12:54:31 EST
(In reply to rhbugzilla.5.nebuchadnezar from comment #46)
> Could you guys please send the bugfix, or a link to this bugreport to the
> openssl guys? Your bugfix is quite worthless to the rest of the world if you
> don't report this bug upstream and keeping the fix to yourselves. I had to
> disable nss via. the java.security file in order to use mcabber with my
> jabber server, because I had this exact exception on a debian box with
> openfire running on top of it.

This bug is not about OpenSSL.  You need to comment on their bug report.
Comment 50 rhbugzilla.5.nebuchadnezar 2014-01-28 18:37:07 EST
It is clearly about openssl, or nss. At least the same reason why this bug report was opened. The workaround proposed here, worked for openfire too. It is something about the handling of tls 1.2. Openfire can't do anything about it, if the error is somewhere below the jvm, isn't it. Unfortunately I'm not well versed with nss/openssl, so I don't really know to whom I should report this, but I figured, due to the fact that the workaround provided here worked too, I can only conclude that the source of the problem is the same; or at least something very similar. Sorry, if I sounded angry before, but it looked to me like, .. nah don't bother with reporting this upstream, we just patch it ourselves, but whatever; I'm a bit helpless here to whom this should be reported. At least, the workaround helped.
Comment 53 Andrew John Hughes 2014-02-24 17:39:45 EST
(In reply to rhbugzilla.5.nebuchadnezar from comment #50)
> It is clearly about openssl, or nss. At least the same reason why this bug
> report was opened. The workaround proposed here, worked for openfire too. It
> is something about the handling of tls 1.2. Openfire can't do anything about
> it, if the error is somewhere below the jvm, isn't it. Unfortunately I'm not
> well versed with nss/openssl, so I don't really know to whom I should report
> this, but I figured, due to the fact that the workaround provided here
> worked too, I can only conclude that the source of the problem is the same;
> or at least something very similar. Sorry, if I sounded angry before, but it
> looked to me like, .. nah don't bother with reporting this upstream, we just
> patch it ourselves, but whatever; I'm a bit helpless here to whom this
> should be reported. At least, the workaround helped.

This is a bug related to java-1.7.0-openjdk, so no it's not "clearly about openssl or nss".
Comment 55 Deepak Bhole 2014-04-09 13:48:45 EDT
As far as RHEL is concerned, this issue is "resolved", in the sense that we have reverted the use of NSS as the default provider due to other issues with it. Marking it so.
Comment 56 Thorsten Glaser 2014-04-25 09:01:23 EDT
This is also tracked on Launchpad:

https://bugs.launchpad.net/centos/+bug/1006776

Thanks for the additional information regarding that this is caused by a change in NSS (not Java™ or so) adding partial/incomplete ECC support.
Comment 57 Andrew John Hughes 2016-06-02 21:47:25 EDT
Re-opening this as we appear to have regressed on this issue with the java-1.8.0-openjdk package. We now ship the SunEC provider which also uses NSS (see bug 1208307) and the same three curves, but the patch from comment #21 was never forward-ported to the OpenJDK 8 packages. It was already in the OpenJDK 7 packages when SunEC support was added, so it was missed as not being one of the changes we made then.
Comment 63 liug 2016-10-03 16:12:21 EDT
I saw upstream tracks this issue in https://bugs.openjdk.java.net/browse/JDK-8160342 and marka as fix version 9.1 [ 18400 ]

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