[
https://issues.apache.org/jira/browse/ZOOKEEPER-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Istvan Toth updated ZOOKEEPER-4942:
-----------------------------------
Description:
The current behaviour is to overwrite the JVM global TLS certification
revocation properties based on ZK configuration.
This is a bad idea, as ZK is unlikely to be the only thing running in the JVM
(unless it is the ZK server process), and the ZK settings (Even the OCSP/CRL
disabled default settings) will apply to ALL connections in the JVM.
Ideally, ZK would just leave these properties alone, but that would break
backwards compatibility.
I propose the following fixes:
A. Change the default behaviour, so that if the _zookeeper.ssl.ocsp_
_zookeeper.ssl.crl_ properties are not defined then ZK skips changing the
certificate revocation related global settings, and relies on the JVM
System/Security properties.
B. Change the default behaviour, so that if the _zookeeper.ssl.ocsp_
_zookeeper.ssl.crl_ properties are set to a specific value (i.e. "system") ZK
skips changing the certificate revocation related global settings, and relies
on the JVM System/Security properties.
Option A. would be the more secure, as it doesn't overwrite the system
settings, but it does break backwards compatibiliry with existing ZK versions.
Option B. is less secure, as it requires explicit configuration not to clobber
the JVM global settings, but it is fully backwards compatible with existing
configurations.
was:
The current behaviour is to overwrite the JVM global TLS certification
revocation properties based on ZK configuration.
This is a bad idea, as ZK is unlikely to be the only thing running in the JVM
(unless it is the ZK server process), and the ZK settings (Even the OCSP/CRL
disabled default settings) will apply to ALL connections in the JVM.
Ideally, ZK would just leave these properties alone, but that would break
backwards compatibility.
I propose the following fixes:
A. Change the default behaviour, so that if the _zookeeper.ssl.ocsp_
_zookeeper.ssl.crl_ properties are not defined then ZK skips changing the
certificate revocation related global settings, and relies on the JVM
System/Security properties.
B. Change the default behaviour, so that if the _zookeeper.ssl.ocsp_
_zookeeper.ssl.crl_ properties are set to a specific value (i.e. "system") ZK
skips changing the certificate revocation related global settings, and relies
on the JVM System/Security properties.
Option A. would be the more secure, as it doesn't overwrite the system
settings, but it does break backwards compatibiliry with existing ZK versions.
Option B. is less secure, as it requires explicit configuration not to clobber
the system settings, but it is fully backwards compatible with existing
configurations.
> Add option to preserve JVM TLS certification revocation properties
> ------------------------------------------------------------------
>
> Key: ZOOKEEPER-4942
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4942
> Project: ZooKeeper
> Issue Type: Bug
> Components: security
> Reporter: Istvan Toth
> Assignee: Istvan Toth
> Priority: Major
>
> The current behaviour is to overwrite the JVM global TLS certification
> revocation properties based on ZK configuration.
> This is a bad idea, as ZK is unlikely to be the only thing running in the JVM
> (unless it is the ZK server process), and the ZK settings (Even the OCSP/CRL
> disabled default settings) will apply to ALL connections in the JVM.
> Ideally, ZK would just leave these properties alone, but that would break
> backwards compatibility.
> I propose the following fixes:
> A. Change the default behaviour, so that if the _zookeeper.ssl.ocsp_
> _zookeeper.ssl.crl_ properties are not defined then ZK skips changing the
> certificate revocation related global settings, and relies on the JVM
> System/Security properties.
> B. Change the default behaviour, so that if the _zookeeper.ssl.ocsp_
> _zookeeper.ssl.crl_ properties are set to a specific value (i.e. "system") ZK
> skips changing the certificate revocation related global settings, and relies
> on the JVM System/Security properties.
> Option A. would be the more secure, as it doesn't overwrite the system
> settings, but it does break backwards compatibiliry with existing ZK versions.
> Option B. is less secure, as it requires explicit configuration not to
> clobber the JVM global settings, but it is fully backwards compatible with
> existing configurations.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
