EC Keys fail when Private key material is protected in TLS connections

[jogray72]

It looks like the issue has recently been fixed and is scheduled for release in openJDK 13, but we are hoping adoptOpenJDK will pick up this fix in the adoptOpenJDK11 (LTS) version.

https://bugs.openjdk.java.net/browse/JDK-8217610

Mac OS 10.11, but also CentOS 7 and Windows 7, 8.1, 10 (and presumably all other versions of windows). openjdk version "11.0.2" 2019-01-15 OpenJDK Runtime Environment AdoptOpenJDK (build 11.0.2+9) OpenJDK 64-Bit Server VM AdoptOpenJDK (build 11.0.2+9, mixed mode)

OpenJDK contains a bug where a EC keys used in a TLS connection cause a ClassCastException:

java.lang.ClassCastException: class sun.security.pkcs11.P11Key$P11PrivateKey cannot be cast to class java.security.interfaces.ECPrivateKey (sun.security.pkcs11.P11Key$P11PrivateKey is in module jdk.crypto.cryptoki of loader 'platform'; 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$T13CertificateVerifyMessage.(CertificateVerify.java:867)

We also observed a similar error with what looks to be the same root cause in our own Java toolkit product (using TLS 1.2):

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)

It is also reported here: https://bugs.openjdk.java.net/browse/JDK-8222358

[karianna]

@jogray72 I'm not sure what fix version 11-pool relates to, but when it is fixed upstream then AdoptOpenJDK will pick it up in a nightly and/or release build as appropriate (probably 11.0.4 at this stage). If you'd like to have that bug fix expedited then you can look at one of our support options - https://adoptopenjdk.net/support.html

[jogray72]

Thanks for the reply Martijn!

I was wondering if there is a planned release schedule somewhere. For example, when do you think 11.0.4 would be released?

Cheers,

John Gray

On Mon., Apr. 15, 2019, 3:24 p.m. Martijn Verburg, notifications@github.com wrote:

@jogray72 https://github.com/jogray72 I'm not sure what fix version 11-pool relates to, but when it is fixed upstream then AdoptOpenJDK will pick it up in a nightly and/or release build as appropriate (probably 11.0.4 at this stage). If you'd like to have that bug fix expedited then you can look at one of our support options - https://adoptopenjdk.net/support.html

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/openjdk-build/issues/1041#issuecomment-483384433, or mute the thread https://github.com/notifications/unsubscribe-auth/Agu86NuVXyouHXPZvK8RWVkz8UfDSf1Iks5vhNHcgaJpZM4cwpRt .

[karianna]

16th of July.

[jogray72]

Hi Martijn,

The adoptOpenJDK 11.0.4 version came out and it doesn't appear to have the fix for https://bugs.openjdk.java.net/browse/JDK-8222358 like we were hoping it would.

I don't understand the process of when fixes get into adoptOpenJDK. You had mentioned in a previous e-mail that you didn't know what "11-pool" is. I know even less than you do about how this works as I'm not an Oracle developer. I tried searching online about what 11-pool means but couldn't find any information. I would guess it is some type of holding tank of issues that maybe get added into the upstream?

If we wanted to pursue the support route, how do we do this? I have seen the code fix, and it is literally 1 line of code that needs to get fixed (it caused a fatal ClassCast exception which prevents our applications from working) so it is pretty major issue for us.

Cheers,

John Gray

On Tue, Apr 16, 2019 at 3:20 AM Martijn Verburg notifications@github.com wrote:

16th of July.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/AdoptOpenJDK/openjdk-build/issues/1041#issuecomment-483542142, or mute the thread https://github.com/notifications/unsubscribe-auth/Agu86CjdR5108EnMM4OUYOmOTKbYZM75ks5vhXnWgaJpZM4cwpRt .

[karianna]

Hi @jogray72 - thanks for re-opening - it is disappointing that this didn't get picked up but I think I understand how/why.

I think what 11-pool represents is a group of issues that anyone can pick up to fix in the JDK 11 Updates project (which Red Hat now actually now leads). I suspect what happened here is that the original Oracle author/engineer didn't have the time/capacity to backport and threw it in that pool.

I'm not sure that pool gets actively looked at by anyone - but I've raised the question upstream.

www.adoptopenjdk.net/support.html lists the support options (including vendors that provide paid support for fixes like this).

Once more question - would you be willing to use a nightly build that had the fix?

[sxa]

@karianna Did you get an answer to asking this question upstream? I don't believe it went into 11.0.5 either

[karianna]

@karianna Did you get an answer to asking this question upstream? I don't believe it went into 11.0.5 either

I can't log into JBS at the minute :-(

[karianna]

@karianna Did you get an answer to asking this question upstream? I don't believe it went into 11.0.5 either

I can't log into JBS at the minute :-(

I can't get in either....