Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8353153

Providing access to internal TLS spec classes in SunJSSE for 3-party JCE provider

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Won't Fix
    • Icon: P4 P4
    • None
    • None
    • security-libs

      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


            wetmore Bradford Wetmore
            webbuggrp Webbug Group
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: