[jira] [Updated] (LOG4J2-2059) Refactor classes in core.net.ssl to allow non-KeyStore Providers

["Remko Popma (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/LOG4J2-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Remko Popma updated LOG4J2-2059:
--------------------------------
    Priority: Minor  (was: Major)

> Refactor classes in core.net.ssl to allow non-KeyStore Providers
> ----------------------------------------------------------------
>
>                 Key: LOG4J2-2059
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2059
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: Appenders, Core
>            Reporter: Remko Popma
>            Priority: Minor
>
> 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|http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/ManagerFactoryParameters.html]. 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|http://docs.oracle.com/javase/7/docs/api/javax/net/ssl/KeyStoreBuilderParameters.html], which is a KeyStore-based  ManagerFactoryParameters implementation. 
> To avoid keeping the password data resident in memory we want to [clear the password array|http://docs.oracle.com/javase/7/docs/api/java/security/KeyStore.PasswordProtection.html#destroy()] 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, similar to how the current PasswordProvider interface is able to load and provide the password on demand.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)