[EXTERNAL]Re: RFR [13] JDK-8217610: TLSv1.3 fail with ClassException when EC keys are stored in PKCS11

[John Gray]

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:xuelei.fan at oracle.com] 
Sent: Thursday, April 11, 2019 10:33 AM
To: John Gray <John.Gray at entrustdatacard.com>; Valerie Peng <valerie.peng at oracle.com>; security-dev at openjdk.java.net
Cc: Greg Patel <Greg.Patel at entrustdatacard.com>
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:security-dev-bounces at openjdk.java.net] On 
> Behalf Of Xuelei Fan
> Sent: Tuesday, April 2, 2019 11:45 PM
> To: Valerie Peng <valerie.peng at oracle.com>; 
> security-dev at openjdk.java.net
> 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