-
Notifications
You must be signed in to change notification settings - Fork 7.3k
ZOOKEEPER-4940: Enabling zookeeper.ssl.ocsp with JRE TLS provider errors out #2270
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please replace the condition. Lgtm.
sslContextBuilder.enableOcsp(config.getBoolean(getSslOcspEnabledProperty())); | ||
SslProvider sslProvider = getSslProvider(config); | ||
sslContextBuilder.sslProvider(sslProvider); | ||
if (sslProvider == SslProvider.OPENSSL || sslProvider == SslProvider.OPENSSL_REFCNT) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please use OpenSsl.isOcspSupported()
instead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OpenSsl.isOcspSupported() only tells us if the loaded native OpenSSL library supports OCSP, @anmolnar .
That does not help with original problem, ie. when we try to set it when the provider is not set to OpenSSL.
We COULD use OpenSsl.isOcspSupported() to log a warning if we try to set it while it is not supported.
TCnative will just ignore the setting in that case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also note that I have slightly changed this logic in the latest #2277 PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've also added code to log a warning in that case in #2277
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about using OpenSsl.isAvailable()
and OpenSsl.isOcspSupported()
together?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stoty did you see this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OpenSsl.isAvailable() is completely irrelevant. It only tells if the OpenSSL provider is present on the classpath (perhaps with some sanity checks).
We COULD make a different check for it, but Netty will handle this and error out anyway (whether enableOcsp is called or not), so I don't see any added value.
The actual error that we want to fix is the error that we get when netty is configured to use the JRE PROVIDER and
we're calling enableOCSP().
I have some doubts about whether OpenSSL.enableOcsp() does what we would expect it to do, but as this is the API we have, we should use it.
Even if it returns a wrong result (i.e. true for BoringSSL), that only means that the setting will be silently ignored. We can't fix that from our side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it errors out only for JRE provider, why don't we check the other way around like provider != JDK
? But anyways, let's keep this check if there's no better way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checking for JDK would also work.
I prefer checking for the implementations that are known to implement the feature, as this would keep working in the (highly theoretical) case that new provider is added to netty.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, let's go with that.
sslContextBuilder.enableOcsp(config.getBoolean(getSslOcspEnabledProperty())); | ||
SslProvider sslProvider = getSslProvider(config); | ||
sslContextBuilder.sslProvider(sslProvider); | ||
if (sslProvider == SslProvider.OPENSSL || sslProvider == SslProvider.OPENSSL_REFCNT) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see above
Included in #2276 |
zookeeper-server/src/main/java/org/apache/zookeeper/common/ClientX509Util.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think using TriState property for this is a little bit overkill. We could just set it to "true" if zk property is set to true, otherwise don't do anything. Anyway, lgtm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry. Please rename the property.
use and honor OpenSSL.isOcspSupported() Add more log messages Remove comments about BoringSSL not supporting OCSP stapling
Thanks for the review @anmolnar . It turns out that I have misread the tcnative/boringssl code, and current BoringSSL DOES support ocsp stapling. In any case, I have added checks for OpenSSL.isOcspSupported() and refactored the duplicate logic into a new method. |
// Disabling OCSP for the builder is always safe. | ||
// This is the same as the builder default, effectively a noop. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about this too. Why do we bother with TriState property if the default is obviously that the feature is disabled? We're trying to cover a highly unlikely case if ever in the future the enabled OCSP Stapling feature will become the default.
Instead - strictly fixing the bug only - we could do:
if (tcnative && ocspEnabled && tcnativeOcspStapling && OpenSsl.isOcspSupported()) {
builder.enableOcsp(ocspEnabled);
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could do even less if not introducing the new config setting for stapling. If OCSP is enabled in the config and tcnative
is in use, then we enabled OCSP stapling. This is the simplest bugfix I can think of and it covers all mentioned - currently broken - use cases as well and it's fully backward compatible.
wdyt?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it would fix the original issue.
However we want to phase out the exisitng OCSP setting (at least for the client), as it relies on setting a JVM global system property. If we phase that out, there will still be a need to somehow set this property, and that's what the new property is for.
If you prefer, we can remove the new property from this patch and it back in a follow-up patch that deals with the JVM globals.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, I prefer to go with smaller steps.
I don't think you can get rid of the original property entirely, because there must be a way to set pbParams.setRevocationEnabled(true)
, but we can discuss that in a different patch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgmt. Thanks @stoty !
Merged to master. |
Is 3.8 active ? |
…ors out add docs add new property for tcnative OCSP setting rename property factor out the stapling handling code to a new method use and honor OpenSSL.isOcspSupported() Add more log messages Remove comments about BoringSSL not supporting OCSP stapling rearrange code to make patch smaller add comment for clarification remove new property Reviewers: anmolnar Author: stoty Closes apache#2270 from stoty/ZOOKEEPER-4940 (cherry picked from commit 9d1d25c)
ZOOKEEPER-4940: Enabling zookeeper.ssl.ocsp with JRE TLS provider errors out add docs add new property for tcnative OCSP setting rename property factor out the stapling handling code to a new method use and honor OpenSSL.isOcspSupported() Add more log messages Remove comments about BoringSSL not supporting OCSP stapling rearrange code to make patch smaller add comment for clarification remove new property Reviewers: anmolnar Author: stoty Closes #2270 from stoty/ZOOKEEPER-4940 (cherry picked from commit 9d1d25c) Author: stoty Closes #2282 from stoty/ZOOKEEPER-4940-3.9
No description provided.