Thanks. I'll give it a try later today and let you know if it is working.
Thanks for the prompt response! John Gray Entrust Datacard -----Original Message----- From: Xuelei Fan [mailto:[email protected]] Sent: Thursday, April 11, 2019 10:33 AM To: John Gray <[email protected]>; Valerie Peng <[email protected]>; [email protected] Cc: Greg Patel <[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. 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
