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

Xuelei Fan xuelei.fan at oracle.com
Thu Apr 11 14:33:08 UTC 2019


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



More information about the security-dev mailing list