[
https://issues.apache.org/jira/browse/ZOOKEEPER-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17981699#comment-17981699
]
Istvan Toth commented on ZOOKEEPER-4942:
----------------------------------------
FYI [~andor]
> 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)
