On 5/23/2017 1:34 PM, Bernd Eckenfels wrote:
Hello,
It is a PKIX KeyManager with a loaded P12 key store. But I tried quite a
few alternatives, so maybe there is something wrong within all the
commented code. If you think it should work I can try to clean it up for
reproduction.
I think, it is needed to check the KeyAgreement key usage in both
key/trust manager in the JSSE implementation. I appreciate it very much
if you can help and clean up the test code for reproduction.
Thanks & Regards,
Xuelei
Gruss
Bernd
--
http://bernd.eckenfels.net
------------------------------------------------------------------------
*From:* Xuelei Fan <xuelei....@oracle.com>
*Sent:* Tuesday, May 23, 2017 9:12:10 PM
*To:* Bernd; security-dev@openjdk.java.net
*Subject:* Re: ECC Key Usage ignored with and ECDH(E) ciphers
Hi Bernd,
What are the JSSE key/trust managers used for the testing ("SunX509" or
"PKIX")?
Thanks & Regards,
Xuelei
On 5/23/2017 7:08 AM, Bernd wrote:
Hello,
according to RFC 4492 the key usage for ECDHE and ECDH ciphers need to
be observed in regards to key agreement: When I use ECDH_ECDSA ciphers
then the server certificate must have the keyAgreement usage. When I use
ECDHE_ECDSA ciphers then the server certificate must have
"digitalSignature".
# Note that there is no structural difference between ECDH and ECDSA
# keys. A certificate issuer may use X.509 v3 keyUsage and
# extendedKeyUsage extensions to restrict the use of an ECC public key
# to certain computations [15 <https://tools.ietf.org/search/rfc4492#ref-15>]. This document refers to
an ECC key as
# ECDH-capable if its use in ECDH is permitted. ECDSA-capable is
# defined similarly.
This rule is enforced by the openssl s_client: when the server proposes
a cipher which does not pass this check it will terminate the connection:
> openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect
localhost:1234
> 1252:error:1411713E:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc
cert not for signing:.\ssl\ssl_lib.c:2512:
> 1252:error:14082130:SSL routines:ssl3_check_cert_and_algorithm:bad
ecc cert:.\ssl\s3_clnt.c:3544:
In this case the certificate had key usage:
> [ server-exch ]
> extendedKeyUsage = serverAuth
> basicConstraints = CA:FALSE
> keyUsage = keyAgreement
> subjectAltName=IP:127.0.0.1,DNS:localhost.
The connect with static ECDH works:
> openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234
...
> SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDH-ECDSA-AES128-SHA256
The other way around, when I use the following key usage:
> [ server-sign ]
> extendedKeyUsage = serverAuth
> basicConstraints = CA:FALSE
> keyUsage = digitalSignature
> subjectAltName=IP:127.0.0.1,DNS:localhost.
OpenSSL client works this way:
>openssl s_client -cipher ECDH-ECDSA-AES128-SHA256 -connect localhost:1234
>9916:error:1411713D:SSL routines:ssl_check_srvr_ecc_cert_and_alg:ecc
cert not for key agreement
>openssl s_client -cipher ECDHE-ECDSA-AES128-SHA256 -connect localhost:1234
>SSL-Session:
> Protocol : TLSv1.2
> Cipher : ECDHE-ECDSA-AES128-SHA256
In both cases however JSSE (OracleJDK8u121 or OpenJDK 9-ea+162) will
offer both cipher suites and not filter them by key usage capabilties.
Would you agree this is a bug? And should this also apply to client
side? I have not tested it with RSA certificates, but I would expect
this to be the same.
Gruss
Bernd
PS: config file and openssl commands to create multiple ECC certificates
used for this test:
https://gist.github.com/ecki/d66d79bf0cf12872d015804f5edec6e4
