ECC Key Usage ignored with and ECDH(E) ciphers

[Bernd Eckenfels]

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.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: Xuelei Fan <xuelei.fan at oracle.com>
Sent: Tuesday, May 23, 2017 9:12:10 PM
To: Bernd; security-dev at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170523/ed9f2e3f/attachment.htm>