openjdk-6-jdk ssl negotiation incompatibility

Bug #1006776 reported by David Peall on 2012-05-31
124
This bug affects 26 people
Affects Status Importance Assigned to Milestone
CentOS
Unknown
Unknown
openjdk-6 (Ubuntu)
Undecided
Unassigned
openjdk-7 (Debian)
New
Undecided
Unassigned
openjdk-7 (Ubuntu)
Undecided
Unassigned

Bug Description

Ununtu 12.04 LTS

openjdk-6-jdk:
  Installed: 6b24-1.11.1-4ubuntu3
  Candidate: 6b24-1.11.1-4ubuntu3
  Version table:
 *** 6b24-1.11.1-4ubuntu3 0
        500 http://za.archive.ubuntu.com/ubuntu/ precise-updates/main i386 Packages
        100 /var/lib/dpkg/status
     6b24-1.11.1-4ubuntu2 0
        500 http://za.archive.ubuntu.com/ubuntu/ precise/main i386 Packages

From the OpenSSL client:

openssl version
OpenSSL 1.0.1 14 Mar 2012

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

From the OpenJDK6 server (broken):

Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
pool-2-thread-4, setSoTimeout(20000) called
pool-2-thread-4, READ: TLSv1 Handshake, length = 221
*** ClientHello, TLSv1.1
RandomCookie: GMT: 1321675259 bytes = { 184, 44, 25, 155, 123, 0, 221, 149, 99, 164, 30, 145, 14, 82, 5, 146, 179, 15, 178, 161, 250, 169, 115, 69, 239, 126, 131, 196 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, Unknown 0xc0:0x22, Unknown 0xc0:0x21, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, Unknown 0x0:0x88, Unknown 0x0:0x87, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, Unknown 0x0:0x84, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, Unknown 0xc0:0x1c, Unknown 0xc0:0x1b, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, Unknown 0xc0:0x1f, Unknown 0xc0:0x1e, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, Unknown 0x0:0x9a, Unknown 0x0:0x99, Unknown 0x0:0x45, Unknown 0x0:0x44, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, Unknown 0x0:0x96, Unknown 0x0:0x41, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 1, 0 }
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
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}
Unsupported extension type_35, data:
Unsupported extension type_15, data: 01
***
pool-2-thread-4, handling exception: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
pool-2-thread-4, SEND TLSv1 ALERT: fatal, description = internal_error
pool-2-thread-4, WRITE: TLSv1 Alert, length = 2
pool-2-thread-4, called closeSocket()
pool-2-thread-4, IOException in getSession(): javax.net.ssl.SSLException: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID
Finalizer, called close()
Finalizer, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)
Finalizer, called close()
Finalizer, called closeInternal(true)

From the sun-jdk server(works):

Allow unsafe renegotiation: true
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
pool-2-thread-1, setSoTimeout(20000) called
pool-2-thread-1, READ: TLSv1 Handshake, length = 221
*** ClientHello, TLSv1.1
RandomCookie: GMT: 1321675506 bytes = { 188, 132, 89, 108, 237, 169, 129, 49, 160, 33, 112, 237, 203, 27, 146, 187, 53, 152, 148, 219, 10, 93, 44, 51, 49, 209, 241, 18 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, Unknown 0xc0:0x22, Unknown 0xc0:0x21, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, Unknown 0x0:0x88, Unknown 0x0:0x87, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, Unknown 0x0:0x84, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, Unknown 0xc0:0x1c, Unknown 0xc0:0x1b, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, Unknown 0xc0:0x1f, Unknown 0xc0:0x1e, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, Unknown 0x0:0x9a, Unknown 0x0:0x99, Unknown 0x0:0x45, Unknown 0x0:0x44, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, Unknown 0x0:0x96, Unknown 0x0:0x41, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5, SSL_RSA_EXPORT_WITH_RC4_40_MD5, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 1, 0 }
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
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}
Unsupported extension type_35, data:
Unsupported extension type_15, data: 01
***
%% Created: [Session-1, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA]
*** ServerHello, TLSv1
RandomCookie: GMT: 1321675506 bytes = { 141, 15, 202, 217, 253, 174, 240, 169, 172, 62, 151, 132, 183, 87, 204, 146, 37, 174, 38, 204, 18, 234, 112, 30, 174, 165, 57, 117 }
Session ID: {79, 199, 43, 242, 167, 217, 237, 76, 85, 242, 195, 126, 53, 209, 252, 103, 58, 71, 185, 6, 181, 52, 206, 70, 75, 13, 117, 143, 21, 183, 5, 142}
Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
***
Cipher suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
*** Certificate chain

David Peall (dkpeall) on 2012-05-31
tags: added: precise
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openjdk-6 (Ubuntu):
status: New → Confirmed
Christoph W (wech) wrote :

Same problem exists in openjdk-7u3-2.1.1

Changed in openjdk-7 (Ubuntu):
status: New → Confirmed
Christoph W (wech) on 2012-06-02
affects: openjdk → openjdk-7 (Ubuntu)
Christoph W (wech) wrote :

Same as https://bugs.launchpad.net/ubuntu/+source/openjdk-7/+bug/989240

sun.security.pkcs11.wrapper.PKCS11Exception of CKR_DOMAIN_PARAMS_INVALID while creating private

    // Called by ServerHandshaker for ephemeral ECDH
    ECDHCrypt(String curveName, SecureRandom random) {
        try {
            KeyPairGenerator kpg = JsseJce.getKeyPairGenerator("EC");
            ECGenParameterSpec params = new ECGenParameterSpec(curveName);
            kpg.initialize(params, random);
            KeyPair kp = kpg.generateKeyPair(); <<<<<<<< ***BOOOM

I expierience the crash in jetty7 when connecting with libssl>=1.0.0.

It does work fine when I run jetty sun/oracles jdk7u4 and it also worked on ubuntu 8.04 lts with openjdk6b18, but not on ubuntu 10.04 lts with openjdk6b20 or on 12.04 with openjdk6b24 or openjdk7u3.

The ciphersuite chosen in my case is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 in my case. When I disable all Elliptic Curve cipher suites trough jettys ssl configuration, the problem gets away.

This bug had been fixed for openjdk-6 - 6b18-1.8-0ubuntu1 (see https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/556549), but produced another bug so was undone it seems (https://bugs.launchpad.net/ubuntu/+source/openjdk-6/+bug/580982)

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in openjdk-7 (Ubuntu):
status: New → Confirmed
Christoph W (wech) wrote :

Out of curiosity I've further examined the problem. Here my results.

It seems that the used libnss3 only supports these 3 elliptic curves: secp256r1 secp384r1 and secp521r1

(See source package for libnss3 on ubuntu 12.04
   openjdk-6-src/nss-3.13.1.with.ckbi.1.88/mozilla/security/nss/freebl/ecl/ecl-curve.h:

/* mapping between ECCurveName enum and pointers to ECCurveParams */
static const ECCurveParams *ecCurve_map[] = {
        NULL, /* ECCurve_noName */
        NULL, /* ECCurve_NIST_P192 */
        NULL, /* ECCurve_NIST_P224 */
        &ecCurve_NIST_P256, /* ECCurve_NIST_P256 */
        &ecCurve_NIST_P384, /* ECCurve_NIST_P384 */
        &ecCurve_NIST_P521, /* ECCurve_NIST_P521 */
        NULL, /* ECCurve_NIST_K163 */
        NULL, /* ECCurve_NIST_B163 */

    all following are NULL too
}

)

But sun.security.ssl.HelloExtensions.isSupported() always returns true (because "fips mode" is false) - for every existing or non existing curve ID.

OpenSSL in ssl client mode suggests curves in the following order: 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}

Because HelloExtensions.isSupported() now says true for the first one (Index 14 = sect571r1), this one is being chosen, but as libnss3 does not support it this leads to

-> SECFailure in gf_populate_params in ecdecode.c:182
-> SECFailure with SetError(SEC_ERROR_UNSUPPORTED_ELLIPTIC_CURVE); in EC_FillParams:597
-> rv 304 (CKR_DOMAIN_PARAMS_INVALID) at Java_sun_security_pkcs11_wrapper_PKCS11_C_1GenerateKeyPair:167
167 rv = (*ckpFunctions->C_GenerateKeyPair)(ckSessionHandle, &ckMechanism,
168 ckpPublicKeyAttributes, ckPublicKeyAttributesLength,
169 ckpPrivateKeyAttributes, ckPrivateKeyAttributesLength,
170 ckpPublicKeyHandle, ckpPrivateKeyHandle);

which prouces a PKCS11Exception in sun.security.pkcs11.P11KeyPairGenerator:314
long[] keyIDs = token.p11.C_GenerateKeyPair
                (session.id(), new CK_MECHANISM(mechanism),
                publicKeyTemplate, privateKeyTemplate);

which is being converted into a ProviderException which is catched in the Handshakers DelegatedTask and being remembered als "thrown" until the unwrap() and then thrown.

call stack at this point:
P11KeyPairGenerator.generateKeyPair() line: 314
KeyPairGenerator$Delegate.generateKeyPair() line: 687
ECDHCrypt.<init>(String, SecureRandom) line: 63
ServerHandshaker.setupEphemeralECDHKeys() line: 1204
ServerHandshaker.trySetCipherSuite(CipherSuite) line: 1058
ServerHandshaker.chooseCipherSuite(HandshakeMessage$ClientHello) line: 887

This prevents the response from the server being created and the HandshakeResponse stays in NEEDS_UNWRAP mode as nothing can be sent back to the client and the connection hangs and times out.

Christoph W (wech) wrote :

*Ouch*

I just realized that it is sufficient to modify /etc/java-6-openjdk/security/java.security so it uses the sun Elliptic Curve impelementation wich is also included in openjdk.

Just change the line
security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
to
security.provider.9=sun.security.ec.SunEC
security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

and move the Sun EC implementation, which provides all curves, in front of the pkcs11 implementation so it is being tried first when creating the key pair.

Christoph W (wech) wrote :

hm. This worked on ubuntu 12.04, but not on 10.04 with openjdk-6_6b20-1.9.13 *sigh*

Christoph W (wech) wrote :

Hm. Now I get a java.lang.ClassNotFoundException: sun.security.ec.SunEC even on openjdk7. I was sure this worked before.

It seems the SunEC provider was added in jdk7, so no way to get this to work in jdk6, but it should work on openjdk7 at least.
http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html#SunEC

The reason it worked on openjdk-6 yesterday was plainly, that I commented out the pkcs11 provider and the SunEC provider is not available so EllipticCurve was disabled completely when negotiating the used cipher.

So a potential workaround for people affected by this problem would be to comment out the line

#security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

But of course this has the potential problem that EC is no longer available at all which might affect other java applications too.

In my opinion it would be best to fix sun.security.ssl.HelloExtensions.isSupported() so it returns only true for secp256r1 secp384r1 and secp521r1 when the SunEC Provider is not available.

I guess somebody else knows better than me how to implement this in a generic way. For example I don't know why the SunEC provider is not included in IceadTea. Is this a licensing issue for oss? For libnss3 it seems to be a patent issue with the other curves from what I've read, but I'm also not sure about this. Otherwise the best solution at all would be to add the missing curves - but I guess there is a reason they were removed.

The most-non-generic but easiest working solution would probably be trough a patch to the openjdk sources for IcedTea which does a hard check for all curves ones implemented in libnss3 and only returns true for them.

David Peall (dkpeall) wrote :
Download full text (6.1 KiB)

#
# List of providers and their preference orders (see above):
#
security.provider.1=sun.security.provider.Sun
security.provider.2=sun.security.rsa.SunRsaSign
security.provider.3=com.sun.net.ssl.internal.ssl.Provider
security.provider.4=com.sun.crypto.provider.SunJCE
security.provider.5=sun.security.jgss.SunProvider
security.provider.6=com.sun.security.sasl.Provider
security.provider.7=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.8=sun.security.smartcardio.SunPCSC
security.provider.9=sun.security.ec.SunEC
security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

Not working...

Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
matching alias: fmsrns
pool-2-thread-1, called closeSocket()
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
MessageManager, setSoTimeout(20000) called
[Raw read]: length = 5
0000: 16 03 01 00 DD .....
[Raw read]: length = 221
0000: 01 00 00 D9 03 02 4F CD B8 7F 37 09 DE 24 83 80 ......O...7..$..
0010: 94 0D 69 FC 1F 57 91 E8 27 B8 B5 57 4A 2A 1C 9B ..i..W..'..WJ*..
0020: 5D 34 50 CE B4 05 00 00 66 C0 14 C0 0A C0 22 C0 ]4P.....f.....".
0030: 21 00 39 00 38 00 88 00 87 C0 0F C0 05 00 35 00 !.9.8.........5.
0040: 84 C0 12 C0 08 C0 1C C0 1B 00 16 00 13 C0 0D C0 ................
0050: 03 00 0A C0 13 C0 09 C0 1F C0 1E 00 33 00 32 00 ............3.2.
0060: 9A 00 99 00 45 00 44 C0 0E C0 04 00 2F 00 96 00 ....E.D...../...
0070: 41 C0 11 C0 07 C0 0C C0 02 00 05 00 04 00 15 00 A...............
0080: 12 00 09 00 14 00 11 00 08 00 06 00 03 00 FF 02 ................
0090: 01 00 00 49 00 0B 00 04 03 00 01 02 00 0A 00 34 ...I...........4
00A0: 00 32 00 0E 00 0D 00 19 00 0B 00 0C 00 18 00 09 .2..............
00B0: 00 0A 00 16 00 17 00 08 00 06 00 07 00 14 00 15 ................
00C0: 00 04 00 05 00 12 00 13 00 01 00 02 00 03 00 0F ................
00D0: 00 10 00 11 00 23 00 00 00 0F 00 01 01 .....#.......
MessageManager, READ: TLSv1 Handshake, length = 221
*** ClientHello, TLSv1.1
RandomCookie: GMT: 1322039423 bytes = { 55, 9, 222, 36, 131, 128, 148, 13, 105, 252, 31, 87, 145, 232, 39, 184, 181, 87, 74, 42, 28, 155, 93, 52, 80, 206, 180, 5 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, Unknown 0xc0:0x22, Unknown 0xc0:0x21, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, Unknown 0x0:0x88, Unknown 0x0:0x87, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, Unknown 0x0:0x84, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, Unknown 0xc0:0x1c, Unknown 0xc0:0x1b, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, Unknown 0xc0:0x1f, Unknown 0xc0:0x1e, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CB...

Read more...

Christoph W (wech) wrote :

yes. I've updated my suggestion above. Please comment out the line like this:

#security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

This completely disables Elliptic Curves so another method is chosen. It seems SunEC is not available in iced tea builds currently.

Christoph W (wech) wrote :

btw: the reason it stopped working with openssl1.0 is, that openssl0.9.8 did only send these ciphers:
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC4-SHA:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5

while 1.0 extended them to include EllipticCurve-Chipers:
ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHA:CAMELLIA256-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA:PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC4-MD5

(actual output on ubuntu 8.04 and 12.04 of command "openssl ciphers -tls1" )

David Peall (dkpeall) wrote :

Removing
security.provider.10=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg
Has solved the problem for us for now.

description: updated
Thorsten Glaser (mirabilos) wrote :

Just debugged this on OpenJDK 7, Tomcat 7, Debian wheezy.

The workaround to comment out the line

security.provider.9=sun.security.pkcs11.SunPKCS11 ${java.home}/lib/security/nss.cfg

worked. The line

#security.provider.9=sun.security.ec.SunEC

was already commented out, since this is the nōn-free part AFAICT.

Thorsten Glaser (mirabilos) wrote :

Also tracked in Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=1022017

The bug is apparently caused by a change in NSS (not Java™) adding partial/incomplete ECC support.

Andrew John Hughes (ahughes) wrote :

Some feedback on this bug as I worked on it from the RH side.

* The OpenJDK Java code for elliptic curve support in SSL uses a list of curves based on the in-tree code used by Oracle.
* The actual curves supported by the system version of NSS used on most distributions is much shorter; it's basically three approved NIST curves. I assume this is for legal reasons which I won't try and go into further.
* This bug comes about because of the mismatch between the two. The Java code says it supports one set of curves, but in practice, the underlying provider code doesn't.
* This is true whether the combination of NSS with the PKCS11 provider is used (the Ubuntu setup above and what Red Hat were trying in its bug) or with the SunEC provider (support for this is coming in IcedTea 2.5.0).

The next set of releases (2.4.8, 2.5.0) will include a patch which fixes the list of curves on the Java side to match the list used by system NSS. This bug should then be properly resolved and the above workaround will not be needed.

Looking to the future, the SunEC provider may be a better solution for providing elliptic curve support - it matches what Oracle use in their packages - but doing so with a system NSS will require 3.16.1, in order to expose necessary APIs. Even then, it is necessary to link against a static NSS library at build-time.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.