[
https://issues.apache.org/jira/browse/LOG4J2-2059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Remko Popma updated LOG4J2-2059:
--------------------------------
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|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. We can define a custom
{{ManagerFactoryParametersProvider}} interface that returns a
ManagerFactoryParameters object when requested, similar to how the current
PasswordProvider interface is able to load and provide the password on demand.
Our SslConfiguration would be constructed with a
ManagerFactoryParametersProvider, and this provider would generate the
ManagerFactoryParameters object required to initialize the KeyManagerFactory
and TrustManagerFactory.
was:
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.
> 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. We can define a custom
> {{ManagerFactoryParametersProvider}} interface that returns a
> ManagerFactoryParameters object when requested, similar to how the current
> PasswordProvider interface is able to load and provide the password on
> demand. Our SslConfiguration would be constructed with a
> ManagerFactoryParametersProvider, and this provider would generate the
> ManagerFactoryParameters object required to initialize the KeyManagerFactory
> and TrustManagerFactory.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
