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: [email protected] [mailto:[email protected]]
On Behalf Of Dave Thompson
Sent: Thursday, December 19, 2013 12:36 AM
To: [email protected]
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?
>
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 List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [email protected]
Automated List Manager [email protected]
