Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-2059

Refactor classes in core.net.ssl to allow non-KeyStore Providers

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Appenders, Core
    • Labels:
      None

      Description

      Refactor classes in the core.net.ssl package so that an SSL context can be created with a KeyManagerFactory and TrustManagerFactory initialized from either KeyStores or from a ManagerFactoryParameters implementation.

      Background

      With LOG4J2-1896, classes in core.net.ssl were improved to avoid keeping passwords resident in memory where possible.

      The mechanism to achieve this (a custom PasswordProvider interface) manages secrets in a way that is specific for KeyStore-based providers. We want to manage secrets in a way that allows for other providers.

      During investigation it turned out that to Java has already standardized this. The KeyManagerFactory and TrustManagerFactory needed for SSL can be initialized with either a KeyStore or a ManagerFactoryParameters. There is no need for a custom generic interface to manage secrets.

      Implementation
      The same parameters that are currently used to create and load the KeyStore and TrustStore can also be used to construct a KeyStoreBuilderParameters, which is a KeyStore-based ManagerFactoryParameters implementation.

      To avoid keeping the password data resident in memory we want to clear the password array once the SSL context is created.

      Log4j2 has use cases that require the ability to reconnect when the session is lost. One way to support this is to create a new ManagerFactoryParameters instance every time a new SSL context is created. We can define a custom ManagerFactoryParametersProvider interface that returns a new ManagerFactoryParameters object when requested, similar to how the current PasswordProvider interface is able to load and provide the password on demand. The password data in that ManagerFactoryParameters object can then be erased when the new SSLContext is created. Our SslConfiguration would be constructed with a ManagerFactoryParametersProvider, and this provider would generate the ManagerFactoryParameters object required to initialize the KeyManagerFactory and TrustManagerFactory.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                rpopma Remko Popma
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated: