Skip to content

Conversation

stoty
Copy link
Contributor

@stoty stoty commented Jun 18, 2025

No description provided.

Copy link
Contributor

@anmolnar anmolnar left a 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) {
Copy link
Contributor

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.

Copy link
Contributor Author

@stoty stoty Jul 7, 2025

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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

Copy link
Contributor

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?

Copy link
Contributor

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?

Copy link
Contributor Author

@stoty stoty Jul 17, 2025

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.

Copy link
Contributor

@anmolnar anmolnar Jul 17, 2025

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above

@stoty
Copy link
Contributor Author

stoty commented Jul 7, 2025

Included in #2276

@stoty stoty closed this Jul 7, 2025
@stoty stoty reopened this Jul 7, 2025
stoty added 2 commits July 7, 2025 19:56
add new property for tcnative OCSP setting
Copy link
Contributor

@anmolnar anmolnar left a 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.

Copy link
Contributor

@anmolnar anmolnar left a 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.

stoty added 2 commits July 8, 2025 20:11
use and honor OpenSSL.isOcspSupported()
Add more log messages
Remove comments about BoringSSL not supporting OCSP stapling
@stoty
Copy link
Contributor Author

stoty commented Jul 17, 2025

Thanks for the review @anmolnar .

It turns out that I have misread the tcnative/boringssl code, and current BoringSSL DOES support ocsp stapling.
I have removed the comments and docs stating that BoringSSL does not support stapling.

In any case, I have added checks for OpenSSL.isOcspSupported() and refactored the duplicate logic into a new method.
I have also added more logging and tried to make the logic simpler and easier to follow.

@stoty stoty requested a review from anmolnar July 17, 2025 05:59
Comment on lines 168 to 169
// Disabling OCSP for the builder is always safe.
// This is the same as the builder default, effectively a noop.
Copy link
Contributor

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);
}

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@stoty stoty requested a review from anmolnar July 18, 2025 04:46
Copy link
Contributor

@anmolnar anmolnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgmt. Thanks @stoty !

@anmolnar anmolnar merged commit 9d1d25c into apache:master Jul 18, 2025
16 checks passed
@anmolnar
Copy link
Contributor

Merged to master. branch-3.9 and branch-3.8 have conflicts, please create separate pull requests.

@stoty
Copy link
Contributor Author

stoty commented Jul 28, 2025

Is 3.8 active ?
My last patch was rejected from 3.8

stoty added a commit to stoty/zookeeper that referenced this pull request Jul 28, 2025
…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)
@stoty
Copy link
Contributor Author

stoty commented Jul 28, 2025

3.8 doesn't have tcnative support, so this is not relevant there.

I've opened #2282 for branch-3.9 @anmolnar .

anmolnar pushed a commit that referenced this pull request Jul 29, 2025
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants