@Andrew_Porter: "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:
<url>
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?
I can work around the problem by modifying OpenJDK's
java.security file and disabling the NSS provider but would
prefer not to do this since a customer would have to do
that every time OpenJDK was updated.
-Andrew
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @frodo: "<quote>
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):
<url>
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                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @Andrew_Porter: "OK, so I'm seeing the same symptoms for a different reason: we're using sta=
tically 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 r=
eproduced
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(00000003)
write to 0xa18f4b8 [0xa18f500] (321 bytes =3D> 321 (0x141))
0000 - 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   .....=3D.Rj....c!.
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   ...*.&.......=3D.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 =3D> 7 (0x7))
0000 - 15 03 03 00 02 02 50                              ......P
769.573.8502:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert i=
nternal 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: <email_address> [mailto:<email_address>=
rg] On Behalf Of Matt Caswell
Sent: Tuesday, December 17, 2013 10:47 AM
To: <email_address>
Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
<quote>
As I understand it Red Hat OpenSSL packages have restricted EC capabilities=
 due to concerns about patents (although other distros do not share this co=
ncern):
<url>
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 delib=
erately 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                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @Andrew_Porter: "That server response (15 03 03 00 02 02 50) has byte 0 =3D SSL3_RT_ALERT an=
d
byte 5 =3D SSL3_AL_FATAL so that means it hated the s_client TLS 1.2 Client=
Hello, 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(00000003)
write to 0xa01c60 [0xa229a0] (263 bytes =3D> 263 (0x107))
0000 - 16 03 01 01 02 01 00 00-fe 03 03 52 b0 b4 3d ef   ...........R..=3D.
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   .&.......=3D.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                              .......
<quote>
...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: <email_address> [mailto:<email_address>=
rg] On Behalf Of Porter, Andrew
Sent: Tuesday, December 17, 2013 11:36 AM
To: <email_address>
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 sta=
tically linked openssl 1.0.1e & fips-2.0.2 (the full one, not the ecp versi=
on 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 Op=
enSUSE 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(00000003)
write to 0xa18f4b8 [0xa18f500] (321 bytes =3D> 321 (0x141))
0000 - 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   .....=3D.Rj....c!.
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   ...*.&.......=3D.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 =3D> 7 (0x7))
0000 - 15 03 03 00 02 02 50                              ......P
769.573.8502:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert i=
nternal 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: <email_address> [mailto:<email_address>=
rg] On Behalf Of Matt Caswell
Sent: Tuesday, December 17, 2013 10:47 AM
To: <email_address>
Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
As I understand it Red Hat OpenSSL packages have restricted EC capabilities=
 due to concerns about patents (although other distros do not share this co=
ncern):
<url>
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 delib=
erately 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                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @steve: "<quote>
Yes though the "internal error" alert suggests it might not be OpenSSL's
fault.
[snip]
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: <url>
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @Andrew_Porter: "Steve:
Already tried -no_tls1_2 with no effect, but -cipher 'DEFAULT:!ECDH' is a s=
uccess,
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.1=
e
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: <email_address> [mailto:<email_address>=
rg] On Behalf Of Dr. Stephen Henson
Sent: Tuesday, December 17, 2013 1:37 PM
To: <email_address>
Subject: Re: OpenSSL 1.0.1e - OpenJDK/NSS interoperability issue?
<quote>
=20
ClientHello, ja?
Yes though the "internal error" alert suggests it might not be OpenSSL's fa=
ult.
[snip]
Well try disabling just TLS 1.2 with -no_tls1_2. You could also try restric=
ting the size of the ClientHello by (for example) cutting down the number o=
f ciphers sent. Something like -cipher 'DEFAULT:!ECDH' for example.
Steve,
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: <url> _________=
_____________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @dthompson: "<quote>
possible.
a
1.0.1e
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
so
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                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @fweimer: "<quote>
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                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @steve: "<quote>
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: <url>
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @Andrew_Porter: "Steve:
<quote>
upported 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_clie=
nt just gets me usage output which has some obviously new options but nothi=
ng that I recognize as appropriate.
Thanks,
Andrew
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @steve: "<quote>
The s_client and s_server utilities can use the new SSL_CONF API in 1.0.2,
see:
<url>
The -sigalgs and -curves options should do the trick.
Steve.
Dr Stephen N. Henson. OpenSSL project core developer.
Commercial tech support now available see: <url>
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @Andrew_Porter: "<quote>
, see:
COMMANDS
I did try -curves before and failed, but I must have been tripped up by try=
ing 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                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @frodo: "<quote>
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                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @frodo: "<quote>
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:
<url>
(username guest, password guest)
Matt
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @Andrew_Porter: "<quote>
ve
ry curves?
Yes, if any binary curve (sect571r1, sect571k1, sect409k1, sect409r1, sect2=
83k1, sect283r1, sect239k1, sect233k1, sect233r1, sect193r1, sect193r2,  se=
ct163k1, sect163r1, sect163r2) comes before a prime curve in the list it re=
sults in failure.
 build of openssl.
Yes, but ruled out FIPS as the problem early on. Much of the s_client testi=
ng has been with non-fips 1.0.1e and 1.0.2 I've built myself.
-Andrew
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @fweimer: "<quote>
We reverted OpenJDK to use the SunJCE provider in version 
83.161.120.155-83.161.120.155.el6.
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?
Florian Weimer / Red Hat Product Security Team
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
    @Andrew_Porter: "Florian:
<quote>
I can provide you with the x86_64 openssl 1.0.2 utility I built yesterday a=
s 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=
arate emails if necessary.
Let me know off-list if you want me to send these to you.
-Andrew
______________________________________________________________________
OpenSSL Project                                 <url>
User Support Mailing List                    <email_address>
Automated List Manager                           <email_address>"
{'source': 'USENET', 'other_information': '{"reply_count": 16, "forum_name": "mailing.openssl.users.20141028.mbox"}', 'file': 'data/output/usenet-mailing.openssl.parquet'}