Remko Popma created LOG4J2-2059:
-----------------------------------
Summary: 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
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)
