JDK-8353153 : Providing access to internal TLS spec classes in SunJSSE for 3-party JCE provider
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: generic
  • CPU: generic
  • Submitted: 2025-03-28
  • Updated: 2025-04-25
  • Resolved: 2025-04-19
Related Reports
Relates :  
JDK-8353682 - Refactor TLS to use KEM for key exchange
Description
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
Comments
Over the years, we've kept the internal JSSE/JCE bridge APIs as Sun internal, with talk of maybe(?)/someday(?) making them public. i.e. sun/security/internal/spec TlsKeyMaterialParameterSpec TlsPrfParameterSpec TlsKeyMaterialSpec TlsRsaPremasterSecretParameterSpec TlsMasterSecretParameterSpec These APIs are only used for SSLv3/TLSv1-1.2 PRF and Key Generation in JSSE. The TLSv1.2 protocol is in the process of being frozen (no new features/projects will be considered by IETF[1]), and of course SSLv3-TLSv1.1 are EOLd and shouldn't be used. There have been some libraries (e.g. Jipher/BC) which have worked around this as mentioned. Even though they use the private sun.* APIs, we have no plans to remove the APIs at this point. The TLSv1.3 implementation no longer uses these APIs, so these APIs would only be useful for the decreasing number of TLSv1.2 folks who want to implement such a third party provider. Backporting this API to earlier JDKs also seems really unlikely, so it would like only be available for those using the more modern versions of the JDK. The new KDF API might give implementers the ability to do the TLS-PRF. With such an API, we could write a TLS-PRF implementation and hook it into SunJSSE if we wanted to do the work. But I don't feel an urgent need to make these APIs public. It's a fair amount of work for limited forward benefit, especially as TLSv1.3 continues its adoption/uptake. [1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/
19-04-2025