-
Enhancement
-
Resolution: Unresolved
-
P4
-
None
-
None
-
generic
-
generic
A DESCRIPTION OF THE PROBLEM :
As a JCE provider implementor, we face a critical interoperability issue with SunJSSE due to its reliance on internal sun.security.internal.spec classes (e.g., TlsMasterSecretParameterSpec, TlsKeyMaterialParameterSpec, TlsPrfParameterSpec) during TLS operations. While SunJSSE uses public JCE APIs like KeyAgreement.getInstance("TlsKeyMaterialGenerator") to instantiate cryptographic primitives, it subsequently initializes these generators with internal spec classes from the restricted sun.security.internal.spec package.
Core Issue:
Third-party JCE providers cannot directly reference these internal classes, forcing them to use reflection to:
Access class definitions
Instantiate objects
Read critical TLS handshake parameters (client/server random, PRF algorithm, etc.)
This creates an unavoidable dependency on reflection even when using public JCE APIs. JDK 9+'s module system now blocks this reflection by default, causing fatal exceptions during TLS handshakes (e.g., java.lang.reflect.InaccessibleObjectException).
Example Workflow Breakdown:
SunJSSE calls KeyAgreement.getInstance("TlsKeyMaterialGenerator", {third-party-provider})
Initializes the generator with init(spec), where spec is an instance of sun.security.internal.spec.TlsKeyMaterialParameterSpec
Third-party provider receives this spec object but cannot cast/access it without reflection due to package restrictions
Impact:
JDK 8: Operates with warnings (WARNING: Illegal reflective access)
JDK 9+: Fails with exceptions (java.lang.reflect.InaccessibleObjectException)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Remove All JCE Providers:
Ensure that all existing JCE providers are removed from the Java environment to isolate the issue.
Configure a Third-Party JCE Provider:
Update the Java security configuration to include only the third-party JCE provider.
Attempt a TLS 1.2 Handshake:
In JDK 8: Observe warnings about illegal reflective access but handshakes complete
In JDK 9+: Observe fatal exceptions when reflection is used
With reflection disabled: Observe the error javax.net.ssl.SSLException: Could not compute secret
Examine the Root Cause:
Verify that SunJSSE is passing internal spec classes during the TLS handshake process
Confirm that these classes cannot be accessed through any public API
As a JCE provider implementor, we face a critical interoperability issue with SunJSSE due to its reliance on internal sun.security.internal.spec classes (e.g., TlsMasterSecretParameterSpec, TlsKeyMaterialParameterSpec, TlsPrfParameterSpec) during TLS operations. While SunJSSE uses public JCE APIs like KeyAgreement.getInstance("TlsKeyMaterialGenerator") to instantiate cryptographic primitives, it subsequently initializes these generators with internal spec classes from the restricted sun.security.internal.spec package.
Core Issue:
Third-party JCE providers cannot directly reference these internal classes, forcing them to use reflection to:
Access class definitions
Instantiate objects
Read critical TLS handshake parameters (client/server random, PRF algorithm, etc.)
This creates an unavoidable dependency on reflection even when using public JCE APIs. JDK 9+'s module system now blocks this reflection by default, causing fatal exceptions during TLS handshakes (e.g., java.lang.reflect.InaccessibleObjectException).
Example Workflow Breakdown:
SunJSSE calls KeyAgreement.getInstance("TlsKeyMaterialGenerator", {third-party-provider})
Initializes the generator with init(spec), where spec is an instance of sun.security.internal.spec.TlsKeyMaterialParameterSpec
Third-party provider receives this spec object but cannot cast/access it without reflection due to package restrictions
Impact:
JDK 8: Operates with warnings (WARNING: Illegal reflective access)
JDK 9+: Fails with exceptions (java.lang.reflect.InaccessibleObjectException)
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Remove All JCE Providers:
Ensure that all existing JCE providers are removed from the Java environment to isolate the issue.
Configure a Third-Party JCE Provider:
Update the Java security configuration to include only the third-party JCE provider.
Attempt a TLS 1.2 Handshake:
In JDK 8: Observe warnings about illegal reflective access but handshakes complete
In JDK 9+: Observe fatal exceptions when reflection is used
With reflection disabled: Observe the error javax.net.ssl.SSLException: Could not compute secret
Examine the Root Cause:
Verify that SunJSSE is passing internal spec classes during the TLS handshake process
Confirm that these classes cannot be accessed through any public API