RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
Florian: It would be great to have a self-contained reproducer, so that we can test this before we enable the NSS-backed crypto provider in OpenJDK again. Can you use official channels for this? I can provide you with the x86_64 openssl 1.0.2 utility I built yesterday as the client plus an RPM that is our customized Tomcat as the server, this is sufficient to reproduce the issue. Together they're about 8 Mb, I think that's small enough to get through our email system as attachments in separate emails if necessary. Let me know off-list if you want me to send these to you. -Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
From: owner-openssl-users On Behalf Of Porter, Andrew Sent: Tuesday, December 17, 2013 17:53 Already tried -no_tls1_2 with no effect, but -cipher 'DEFAULT:!ECDH' is a success, and also just -cipher 'DHE-RSA-AES256-SHA' to make it as small as possible. So looks like a bug with nss 3.15 or with OpenJDK 1.7.0_45 calling it with a ClientHello somewhere in size between the failing 321 bytes the stock 1.0.1e sends and the 263 bytes that the RedHat 1.0.1e sends. The OpenSUSE 1.0.1e openssl seems to be vanilla, on my test VM it sends 319 bytes and gets the error. -cipher 'DEFAULT:!RC4' cuts it down to 307 bytes, still too long. -cipher 'HIGH' sends 277 bytes and works. I doubt this one is an instance of the Hello-too-big problem; I've never seen that in Suncle JSSE and I doubt it would be introduced in OpenJDK. The RH bug you pointed to earlier certainly reads to me as involving particular EC curve(s?) in a provider under OpenJDK. How recent a RedHat openssl package are you using? Until a month ago RedHat disabled EC entirely, and as I read bugzilla, it appears they still do only 2 or 3 popular curves not the full list. All the cases you describe as working offer no or very limited EC, and the failing ones full EC. Suncle Java v6 did not include an ECC provider, so it wouldn't agree any EC suite unless you jiggered it, but I don't know if it still looked at the curve and format extensions. v7 has SunECC. To test this idea, try (1) vanilla (or OpenSUSE?) s_client with two specific ciphers, the DHE-RSA one you want and one ECDHE-RSA one -- that's a very small Hello with full EC (2) RedHat s_client with -servername some.long.irrelevant.name to make the Hello big but with little or no EC The affected module of ours only makes SSL connections to other copies of itself and to Java programs of ours running under Java 7 (or recent 6), so it should be safe to eliminate the weakest ciphers. Is there something better to use than 'HIGH', do you think? HIGH by itself includes anonymous suites you almost certainly don't want, and EC suites I suspect will trigger the problem per above. I suggest HIGH:!aNULL:!ECDH or DEFAULT:!EXP:!LOW:!MEDIUM:!ECDH For more general usage I'd also keep MEDIUM or at least RC4 for now, although the Paterson et al results are somewhat worrying. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On 12/17/2013 07:11 PM, Porter, Andrew wrote: and the Java app throws the exception: PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID Can you provide a backtrace? What's the JVM configuration? Does it use the SunPKCS11 provider, or if not, how does it end up in NSS code? (Some RHEL OpenJDK package versions change the default provider to SunPKCS11.) -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
), SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3, signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA, MD5withRSA Unsupported extension type_15, data: 01 *** %% Initialized: [Session-35, SSL_NULL_WITH_NULL_NULL] http-bio-443-exec-8, handling exception: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID %% Invalidated: [Session-35, SSL_NULL_WITH_NULL_NULL] http-bio-443-exec-8, SEND TLSv1.2 ALERT: fatal, description = internal_error http-bio-443-exec-8, WRITE: TLSv1.2 Alert, length = 2 http-bio-443-exec-8, called closeSocket() http-bio-443-exec-8, IOException in getSession(): javax.net.ssl.SSLException: java.security.ProviderException: sun.security.pkcs11.wrapper.PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID http-bio-443-exec-8, called close() http-bio-443-exec-8, called closeInternal(true) -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Florian Weimer Sent: Thursday, December 19, 2013 9:09 AM To: openssl-users@openssl.org Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue? On 12/17/2013 07:11 PM, Porter, Andrew wrote: and the Java app throws the exception: PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID Can you provide a backtrace? What's the JVM configuration? Does it use the SunPKCS11 provider, or if not, how does it end up in NSS code? (Some RHEL OpenJDK package versions change the default provider to SunPKCS11.) -- Florian Weimer / Red Hat Product Security Team __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
Dave (and Florian):
I doubt this one is an instance of the Hello-too-big problem; I've
never seen that in Suncle JSSE and I doubt it would be
introduced in OpenJDK.
You are correct that it is not the hello size: as you suggested I tried the
ECDHE-RSA-x ciphers from the openssl ciphers output, most generated a no
cipher suites in common error at the Java end but -cipher
'ECDHE-RSA-AES256-SHA' generated the pkcs11 error with a ClientHello of only
166 bytes, and artificially making a ClientHello a lot bigger with your
suggested -servername option and a restricted cipher list also works.
The next puzzler: the -cipher ''ECDHE-RSA-AES256-SHA' which fails with stock
OpenSSL 1.0.1e (Cygwin, OpenSUSE v13.1, built myself) works using RHEL-modified
1.0.1e openssl. There are significant ClientHello differences in compression
method and elliptic_curvese extension. From the Java debug output:
RedHat 1.0.1 (works):
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime,
ansiX962_compressed_char2]
Extension elliptic_curves, curve names: {secp384r1, secp256r1}
Unsupported extension type_35, data:
Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown
(hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5,
signature:0x2), SHA384withECDSA, SHA256withRSA, Unknown (hash:0x4,
signature:0x2), SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3,
signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA,
MD5withRSA
Unsupported extension type_15, data: 01
Everybody else (fails):
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
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:
Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown
(hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5,
signature:0x2), SHA384withECDSA, SHA256withRSA, Unknown (hash:0x4,
signature:0x2), SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3,
signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA,
MD5withRSA
Unsupported extension type_15, data: 01
-Andrew
-Original Message-
From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org]
On Behalf Of Dave Thompson
Sent: Thursday, December 19, 2013 12:36 AM
To: openssl-users@openssl.org
Subject: RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
From: owner-openssl-users On Behalf Of Porter, Andrew
Sent: Tuesday, December 17, 2013 17:53
Already tried -no_tls1_2 with no effect, but -cipher 'DEFAULT:!ECDH'
is a success, and also just -cipher 'DHE-RSA-AES256-SHA' to make it as
small as
possible.
So looks like a bug with nss 3.15 or with OpenJDK 1.7.0_45 calling it
with
a
ClientHello somewhere in size between the failing 321 bytes the stock
1.0.1e
sends and the 263 bytes that the RedHat 1.0.1e sends. The OpenSUSE
1.0.1e openssl seems to be vanilla, on my test VM it sends 319 bytes
and gets the error. -cipher 'DEFAULT:!RC4' cuts it down to 307 bytes, still
too long.
-cipher 'HIGH' sends 277 bytes and works.
I doubt this one is an instance of the Hello-too-big problem; I've never seen
that in Suncle JSSE and I doubt it would be introduced in OpenJDK.
The RH bug you pointed to earlier certainly reads to me as involving particular
EC curve(s?) in a provider under OpenJDK. How recent a RedHat openssl package
are you using? Until a month ago RedHat disabled EC entirely, and as I read
bugzilla, it appears they still do only 2 or 3 popular curves not the full
list. All the cases you describe as working offer no or very limited EC, and
the failing ones full EC.
Suncle Java v6 did not include an ECC provider, so it wouldn't agree any EC
suite unless you jiggered it, but I don't know if it still looked at the curve
and format extensions. v7 has SunECC.
To test this idea, try
(1) vanilla (or OpenSUSE?) s_client with two specific ciphers, the DHE-RSA one
you want and one ECDHE-RSA one -- that's a very small Hello with full EC
(2) RedHat s_client with -servername some.long.irrelevant.name to make the
Hello big but with little or no EC
The affected module of ours only makes SSL connections to other copies
of itself and to Java programs of ours running under Java 7 (or recent
6),
so
it should be safe to eliminate the weakest ciphers. Is there something
better to use than 'HIGH', do you think
Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On Thu, Dec 19, 2013, Porter, Andrew wrote:
The next puzzler: the -cipher ''ECDHE-RSA-AES256-SHA' which fails with
stock OpenSSL 1.0.1e (Cygwin, OpenSUSE v13.1, built myself) works using
RHEL-modified 1.0.1e openssl. There are significant ClientHello differences
in compression method and elliptic_curvese extension. From the Java debug
output:
RedHat 1.0.1 (works):
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension ec_point_formats, formats: [uncompressed,
ansiX962_compressed_prime, ansiX962_compressed_char2]
Extension elliptic_curves, curve names: {secp384r1, secp256r1}
Unsupported extension type_35, data:
Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown
(hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5,
signature:0x2), SHA384withECDSA, SHA256withRSA, Unknown (hash:0x4,
signature:0x2), SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3,
signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA,
MD5withRSA
Unsupported extension type_15, data: 01
Everybody else (fails):
Cipher Suites: [TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
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:
Extension signature_algorithms, signature_algorithms: SHA512withRSA, Unknown
(hash:0x6, signature:0x2), SHA512withECDSA, SHA384withRSA, Unknown (hash:0x5,
signature:0x2), SHA384withECDSA, SHA256withRSA, Unknown (hash:0x4,
signature:0x2), SHA256withECDSA, SHA224withRSA, Unknown (hash:0x3,
signature:0x2), SHA224withECDSA, SHA1withRSA, SHA1withDSA, SHA1withECDSA,
MD5withRSA
Unsupported extension type_15, data: 01
If you try OpenSSL 1.0.2 you can customise the signature algorithms and
supported curves using a command line option.
Steve.
--
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: http://www.openssl.org
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
Steve: If you try OpenSSL 1.0.2 you can customise the signature algorithms and supported curves using a command line option. Erm, how? The ssltest.c and ssl_conf.c source files suggest -named_curve or -curves as a possibilities, but trying to use them with openssl s_client just gets me usage output which has some obviously new options but nothing that I recognize as appropriate. Thanks, Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On Thu, Dec 19, 2013, Porter, Andrew wrote: Steve: If you try OpenSSL 1.0.2 you can customise the signature algorithms and supported curves using a command line option. Erm, how? The ssltest.c and ssl_conf.c source files suggest -named_curve or -curves as a possibilities, but trying to use them with openssl s_client just gets me usage output which has some obviously new options but nothing that I recognize as appropriate. The s_client and s_server utilities can use the new SSL_CONF API in 1.0.2, see: http://www.openssl.org/docs/ssl/SSL_CONF_cmd.html#SUPPORTED_COMMAND_LINE_COMMANDS The -sigalgs and -curves options should do the trick. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
The s_client and s_server utilities can use the new SSL_CONF API in 1.0.2, see: http://www.openssl.org/docs/ssl/SSL_CONF_cmd.html#SUPPORTED_COMMAND_LINE_COMMANDS The -sigalgs and -curves options should do the trick. I did try -curves before and failed, but I must have been tripped up by trying to use the secp256r1 I saw in the Java logs which OpenSSL understands as prime256v1. So, additional data now. This works: ./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves 'secp521r1:secp384r1:prime256v1:sect571r1' -connect tomcat-host:443 But use the same curves in a different order, with sect571r1 first the way it is in the list that OpenSSL 1.0.1e sends: ./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves 'sect571r1:secp521r1:secp384r1:prime256v1' -connect tomcat-host:443 That fails with the pkcs11 error. -Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On 19 December 2013 23:47, Porter, Andrew andrew_por...@bmc.com wrote: So, additional data now. This works: ./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves 'secp521r1:secp384r1:prime256v1:sect571r1' -connect tomcat-host:443 But use the same curves in a different order, with sect571r1 first the way it is in the list that OpenSSL 1.0.1e sends: ./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves 'sect571r1:secp521r1:secp384r1:prime256v1' -connect tomcat-host:443 That fails with the pkcs11 error. Maybe just a co-incidence, but the sect571r1 curve is the only binary curve in your list- the others are all prime curves. Maybe it doesn't like binary curves? Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On 20 December 2013 00:24, Matt Caswell fr...@baggins.org wrote: On 19 December 2013 23:47, Porter, Andrew andrew_por...@bmc.com wrote: So, additional data now. This works: ./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves 'secp521r1:secp384r1:prime256v1:sect571r1' -connect tomcat-host:443 But use the same curves in a different order, with sect571r1 first the way it is in the list that OpenSSL 1.0.1e sends: ./openssl s_client -debug -cipher 'ECDHE-RSA-AES256-SHA' -curves 'sect571r1:secp521r1:secp384r1:prime256v1' -connect tomcat-host:443 That fails with the pkcs11 error. Maybe just a co-incidence, but the sect571r1 curve is the only binary curve in your list- the others are all prime curves. Maybe it doesn't like binary curves? Matt Just realised that in your original post you said you were using the fips build of openssl. This could be a manifestation of this bug: https://rt.openssl.org/Ticket/Display.html?id=3022 (username guest, password guest) Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
Maybe just a co-incidence, but the sect571r1 curve is the only binary curve in your list- the others are all prime curves. Maybe it doesn't like binary curves? Yes, if any binary curve (sect571r1, sect571k1, sect409k1, sect409r1, sect283k1, sect283r1, sect239k1, sect233k1, sect233r1, sect193r1, sect193r2, sect163k1, sect163r1, sect163r2) comes before a prime curve in the list it results in failure. Just realised that in your original post you said you were using the fips build of openssl. Yes, but ruled out FIPS as the problem early on. Much of the s_client testing has been with non-fips 1.0.1e and 1.0.2 I've built myself. -Andrew __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
OK, so I'm seeing the same symptoms for a different reason: we're using statically linked openssl 1.0.1e fips-2.0.2 (the full one, not the ecp version with curves removed) we've built ourselves from openssl.org downloads so this is either a bug in openssl or nss (3.15.1 on CentOS 6.5, 3.15.2 on OpenSUSE 13.1, the 2 platforms we've reproduced this on). Here is s_client debug output using the openssl executable from our build, is there something useful here? [root@Fred bin]# ./openssl s_client -debug -connect u-86:1515 CONNECTED(0003) write to 0xa18f4b8 [0xa18f500] (321 bytes = 321 (0x141)) - 16 03 01 01 3c 01 00 01-38 03 03 52 b0 a6 94 ec ...8..R 0010 - ad 02 e0 e2 a9 3d b1 52-6a 93 d1 d9 05 63 21 e4 .=.Rjc!. 0020 - c1 cc 12 c0 38 04 2b 6c-e2 fe da 00 00 a0 c0 30 8.+l...0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$..!.. 0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.2 0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*=.5 0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d 0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ./.+.'.# 0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .g.@.3.2 0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .E.D.1.-.).% 00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 00 07 /...A.. 00b0 - c0 11 c0 07 c0 0c c0 02-00 05 00 04 00 15 00 12 00c0 - 00 09 00 14 00 11 00 08-00 06 00 03 00 ff 01 00 00d0 - 00 6f 00 0b 00 04 03 00-01 02 00 0a 00 34 00 32 .o...4.2 00e0 - 00 0e 00 0d 00 19 00 0b-00 0c 00 18 00 09 00 0a 00f0 - 00 16 00 17 00 08 00 06-00 07 00 14 00 15 00 04 0100 - 00 05 00 12 00 13 00 01-00 02 00 03 00 0f 00 10 0110 - 00 11 00 23 00 00 00 0d-00 22 00 20 06 01 06 02 ...#.. 0120 - 06 03 05 01 05 02 05 03-04 01 04 02 04 03 03 01 0130 - 03 02 03 03 02 01 02 02-02 03 01 01 00 0f 00 01 0140 - 01. read from 0xa18f4b8 [0xa194a60] (7 bytes = 7 (0x7)) - 15 03 03 00 02 02 50 ..P 3086775968:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:741: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 321 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- -Andrew -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Matt Caswell Sent: Tuesday, December 17, 2013 10:47 AM To: openssl-users@openssl.org Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue? On 17 December 2013 18:11, Porter, Andrew andrew_por...@bmc.com wrote: We've into a problem with a native x86/Linux app of ours - linked statically with vanilla openssl-fips-2.0.2 and openssl-1.0.1e we've built - trying to connect to our Java app when it is running under the latest OpenJDK 1.7.0_45 on RedHat 6.5 or OpenSUSE v13.1: the native app logs SSL_connect: tlsv1 alert internal error and the Java app throws the exception: PKCS11Exception: CKR_DOMAIN_PARAMS_INVALID A little searching turned up a very close match to our scenario in this RedHat bug report: https://bugzilla.redhat.com/show_bug.cgi?id=1022017 The conclusion (scroll down to comments 37/38) is that this is a bug with openssl claiming to support an algorithm it doesn't, and the RedHat version of the openssl 1.0.1e source has been patched to fix this. Question: are they correct that this is an openssl bug? If so, will this be fixed in a 1.0.1f or 1.02 release? As I understand it Red Hat OpenSSL packages have restricted EC capabilities due to concerns about patents (although other distros do not share this concern): https://bugzilla.redhat.com/show_bug.cgi?id=319901 The bug that you refer to above concerns an issue with the Red Hat OpenSSL package incorrectly advertising support for an EC curve that has been deliberately removed by the Red Hat package maintainers, i.e. it is not a bug in OpenSSL itself, but in the Red Hat OpenSSL package. Matt __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
That server response (15 03 03 00 02 02 50) has byte 0 = SSL3_RT_ALERT and byte 5 = SSL3_AL_FATAL so that means it hated the s_client TLS 1.2 ClientHello, ja? Tried the non-FIPS 1.0.1e openssl s_client I had a build of, same error so the FIPS code doesn't seem to be the issue. When I add -no_tls1 to the s_client command line so that it uses an SSL3 ClientHello the connection succeeds. The RedHat/CentOS modified 1.0.1e s_client sends a different TLS 1.2 ClientHello that results in a successful connection: [root@u-86 ~]# openssl s_client -debug -msg -connect localhost:1515 CONNECTED(0003) write to 0xa01c60 [0xa229a0] (263 bytes = 263 (0x107)) - 16 03 01 01 02 01 00 00-fe 03 03 52 b0 b4 3d ef ...R..=. 0010 - 08 4b a1 e8 a4 e4 b5 f7-cf 9d ae 20 32 ca aa c9 .K. 2... 0020 - 4b ee b3 9f 38 07 79 6d-6f 56 2f 00 00 94 c0 30 K...8.ymoV/0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a 00 a3 00 9f 00 6b .,.(.$.k 0040 - 00 6a 00 39 00 38 00 88-00 87 c0 32 c0 2e c0 2a .j.9.8.2...* 0050 - c0 26 c0 0f c0 05 00 9d-00 3d 00 35 00 84 c0 12 =.5 0060 - c0 08 00 16 00 13 c0 0d-c0 03 00 0a c0 2f c0 2b ./.+ 0070 - c0 27 c0 23 c0 13 c0 09-00 a2 00 9e 00 67 00 40 .'.#.g.@ 0080 - 00 33 00 32 00 9a 00 99-00 45 00 44 c0 31 c0 2d .3.2.E.D.1.- 0090 - c0 29 c0 25 c0 0e c0 04-00 9c 00 3c 00 2f 00 96 .).%/.. 00a0 - 00 41 00 07 c0 11 c0 07-c0 0c c0 02 00 05 00 04 .A.. 00b0 - 00 15 00 12 00 09 00 14-00 11 00 08 00 06 00 03 00c0 - 00 ff 01 00 00 41 00 0b-00 04 03 00 01 02 00 0a .A.. 00d0 - 00 06 00 04 00 18 00 17-00 23 00 00 00 0d 00 22 .#. 00e0 - 00 20 06 01 06 02 06 03-05 01 05 02 05 03 04 01 . .. 00f0 - 04 02 04 03 03 01 03 02-03 03 02 01 02 02 02 03 0100 - 01 01 00 0f 00 01 01 ... TLS 1.2 Handshake [length 0102], ClientHello ...remainder of data omitted I've run out of things to try. Since I can create the problem using the 1.0.1e s_client I don't see any point in hacking about with our own code, surely disabling TLS can't be the right thing to do... -Andrew -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Porter, Andrew Sent: Tuesday, December 17, 2013 11:36 AM To: openssl-users@openssl.org Subject: RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue? OK, so I'm seeing the same symptoms for a different reason: we're using statically linked openssl 1.0.1e fips-2.0.2 (the full one, not the ecp version with curves removed) we've built ourselves from openssl.org downloads so this is either a bug in openssl or nss (3.15.1 on CentOS 6.5, 3.15.2 on OpenSUSE 13.1, the 2 platforms we've reproduced this on). Here is s_client debug output using the openssl executable from our build, is there something useful here? [root@Fred bin]# ./openssl s_client -debug -connect u-86:1515 CONNECTED(0003) write to 0xa18f4b8 [0xa18f500] (321 bytes = 321 (0x141)) - 16 03 01 01 3c 01 00 01-38 03 03 52 b0 a6 94 ec ...8..R 0010 - ad 02 e0 e2 a9 3d b1 52-6a 93 d1 d9 05 63 21 e4 .=.Rjc!. 0020 - c1 cc 12 c0 38 04 2b 6c-e2 fe da 00 00 a0 c0 30 8.+l...0 0030 - c0 2c c0 28 c0 24 c0 14-c0 0a c0 22 c0 21 00 a3 .,.(.$..!.. 0040 - 00 9f 00 6b 00 6a 00 39-00 38 00 88 00 87 c0 32 ...k.j.9.8.2 0050 - c0 2e c0 2a c0 26 c0 0f-c0 05 00 9d 00 3d 00 35 ...*=.5 0060 - 00 84 c0 12 c0 08 c0 1c-c0 1b 00 16 00 13 c0 0d 0070 - c0 03 00 0a c0 2f c0 2b-c0 27 c0 23 c0 13 c0 09 ./.+.'.# 0080 - c0 1f c0 1e 00 a2 00 9e-00 67 00 40 00 33 00 32 .g.@.3.2 0090 - 00 9a 00 99 00 45 00 44-c0 31 c0 2d c0 29 c0 25 .E.D.1.-.).% 00a0 - c0 0e c0 04 00 9c 00 3c-00 2f 00 96 00 41 00 07 /...A.. 00b0 - c0 11 c0 07 c0 0c c0 02-00 05 00 04 00 15 00 12 00c0 - 00 09 00 14 00 11 00 08-00 06 00 03 00 ff 01 00 00d0 - 00 6f 00 0b 00 04 03 00-01 02 00 0a 00 34 00 32 .o...4.2 00e0 - 00 0e 00 0d 00 19 00 0b-00 0c 00 18 00 09 00 0a 00f0 - 00 16 00 17 00 08 00 06-00 07 00 14 00 15 00 04 0100 - 00 05 00 12 00 13 00 01-00 02 00 03 00 0f 00 10 0110 - 00 11 00 23 00 00 00 0d-00 22 00 20 06 01 06 02 ...#.. 0120 - 06 03 05 01 05 02 05 03-04 01 04 02 04 03 03 01 0130 - 03 02 03 03 02 01 02 02-02 03 01 01 00 0f 00 01 0140 - 01. read from 0xa18f4b8 [0xa194a60] (7 bytes = 7 (0x7)) - 15 03 03 00 02 02 50 ..P 3086775968:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:741: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 7 bytes and written 321 bytes --- New, (NONE), Cipher is (NONE
Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
On Tue, Dec 17, 2013, Porter, Andrew wrote: That server response (15 03 03 00 02 02 50) has byte 0 = SSL3_RT_ALERT and byte 5 = SSL3_AL_FATAL so that means it hated the s_client TLS 1.2 ClientHello, ja? Yes though the internal error alert suggests it might not be OpenSSL's fault. When I add -no_tls1 to the s_client command line so that it uses an SSL3 ClientHello the connection succeeds. [snip] I've run out of things to try. Since I can create the problem using the 1.0.1e s_client I don't see any point in hacking about with our own code, surely disabling TLS can't be the right thing to do... Well try disabling just TLS 1.2 with -no_tls1_2. You could also try restricting the size of the ClientHello by (for example) cutting down the number of ciphers sent. Something like -cipher 'DEFAULT:!ECDH' for example. Steve, -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
Steve: Already tried -no_tls1_2 with no effect, but -cipher 'DEFAULT:!ECDH' is a success, and also just -cipher 'DHE-RSA-AES256-SHA' to make it as small as possible. So looks like a bug with nss 3.15 or with OpenJDK 1.7.0_45 calling it with a ClientHello somewhere in size between the failing 321 bytes the stock 1.0.1e sends and the 263 bytes that the RedHat 1.0.1e sends. The OpenSUSE 1.0.1e openssl seems to be vanilla, on my test VM it sends 319 bytes and gets the error. -cipher 'DEFAULT:!RC4' cuts it down to 307 bytes, still too long. -cipher 'HIGH' sends 277 bytes and works. The affected module of ours only makes SSL connections to other copies of itself and to Java programs of ours running under Java 7 (or recent 6), so it should be safe to eliminate the weakest ciphers. Is there something better to use than 'HIGH', do you think? Should I try reporting this to the OpenJDK or Mozilla NSS folks? Thanks! Andrew -Original Message- From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Dr. Stephen Henson Sent: Tuesday, December 17, 2013 1:37 PM To: openssl-users@openssl.org Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue? On Tue, Dec 17, 2013, Porter, Andrew wrote: That server response (15 03 03 00 02 02 50) has byte 0 = SSL3_RT_ALERT and byte 5 = SSL3_AL_FATAL so that means it hated the s_client TLS 1.2 ClientHello, ja? Yes though the internal error alert suggests it might not be OpenSSL's fault. When I add -no_tls1 to the s_client command line so that it uses an SSL3 ClientHello the connection succeeds. [snip] I've run out of things to try. Since I can create the problem using the 1.0.1e s_client I don't see any point in hacking about with our own code, surely disabling TLS can't be the right thing to do... Well try disabling just TLS 1.2 with -no_tls1_2. You could also try restricting the size of the ClientHello by (for example) cutting down the number of ciphers sent. Something like -cipher 'DEFAULT:!ECDH' for example. Steve, -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
