The fix is available in OpenJDK repository:
http://hg.openjdk.java.net/jdk/jdk/
You can build it from the source code or use the next Early-Access build:
https://jdk.java.net/13/
Regards,
Xuelei
On 4/10/2019 3:02 PM, John Gray wrote:
Hello,
It looks like we hit this issue with our Entrust Java toolkit using TLS 1.2 (
not just TLS 1.3):
We get this error, which is almost identical.
java.lang.ClassCastException: class
com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable cannot
be cast to class java.security.interfaces.ECPrivateKey
(com.entrust.toolkit.security.crypto.ec.EcConfinedPrivateKey$Unexportable is in
unnamed module of loader 'app'; java.security.interfaces.ECPrivateKey is in
module java.base of loader 'bootstrap')
at
java.base/sun.security.ssl.SignatureScheme.getPreferableAlgorithm(SignatureScheme.java:436)
at
java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyMessage.<init>(CertificateVerify.java:566)
at
java.base/sun.security.ssl.CertificateVerify$T12CertificateVerifyProducer.produce(CertificateVerify.java:740)
at
java.base/sun.security.ssl.SSLHandshake.produce(SSLHandshake.java:436)
at
java.base/sun.security.ssl.ServerHelloDone$ServerHelloDoneConsumer.consume(ServerHelloDone.java:173)
at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
at
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
It looks like you recently fixed this error, which is great! I was wondering
where I can download a build that contains this fix, or when would such a build
be available?
Thanks,
John Gray
Entrust Datacard
-----Original Message-----
From: security-dev [mailto:[email protected]] On Behalf Of
Xuelei Fan
Sent: Tuesday, April 2, 2019 11:45 PM
To: Valerie Peng <[email protected]>; [email protected]
Subject: [EXTERNAL]Re: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException
when EC keys are stored in PKCS11
WARNING: This email originated outside of Entrust Datacard.
DO NOT CLICK links or attachments unless you trust the sender and know the
content is safe.
Good catch! I missed the update for SignatureScheme.
Here is the new webrev:
http://cr.openjdk.java.net/~xuelei/8217610/webrev.01/
Thanks,
Xuelei
On 4/2/2019 12:35 PM, Valerie Peng wrote:
Hmm, I didn't see the SignatureScheme.java in the webrev? The
stacktrace in the bug record shows the casting being inside SignatureScheme
class.
Did I miss something?
Valerie
On 3/28/2019 7:52 AM, Xuelei Fan wrote:
ping ...
Xuelei
On 3/22/2019 2:02 PM, Xuelei Fan wrote:
Hi,
Could I get the following update reviewed?
http://cr.openjdk.java.net/~xuelei/8217610/webrev.00/
For EC key exchange in TLS connections, the private key should use
the specified EC groups. The current code is calling
ECPrivateKey.getParams(). However, the private key may be not an
instance of ECPrivateKey, for example for non-extractable private
key in the SunPKCS11 provider.
To fix the tricky bug, in this update, if private key is an instance
of ECPrivateKey, use it; otherwise, try to check the groups in the
public key of the X.509 certificate bound to the private key.
No hardware to reproduce the issue, and no new regression test. The
update is straightforward. Please help to check the patch if you
can play with a hardware token.
Thanks,
Xuelei
