[
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 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.
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. 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.
> 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 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.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
