Skip to content
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

8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts #13762

Closed
wants to merge 8 commits into from

Conversation

jnimeh
Copy link
Member

@jnimeh jnimeh commented May 2, 2023

This set of enhancements extends the allowed syntax for the com.sun.security.ocsp.timeout, com.sun.security.crl.timeout and com.sun.security.crl.readtimeout System properties. These properties retain their current behavior where a purely numeric value is interpreted in seconds, but now the numeric value may also be appended with "ms" (case-insensitive) to be interpreted as milliseconds.

This enhancement also adds two new System properties: com.sun.security.cert.timeout and com.sun.security.cert.readtimeout which follow the same new allowed syntax. These timeouts only come into play when an AIA extension on a certificate is followed for pulling the issuing authority certificate and only when the com.sun.security.enableAIAcaIssuers property is true (default false).

JBS: https://bugs.openjdk.org/browse/JDK-8179502
CSR: https://bugs.openjdk.org/browse/JDK-8300722


Progress

  • Change must be properly reviewed (1 review required, with at least 1 Reviewer)
  • Change must not contain extraneous whitespace
  • Commit message must refer to an issue
  • Change requires CSR request JDK-8300722 to be approved

Issues

  • JDK-8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts
  • JDK-8300722: Enhance OCSP, CRL and Certificate Fetch Timeouts (CSR)

Reviewers

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762
$ git checkout pull/13762

Update a local copy of the PR:
$ git checkout pull/13762
$ git pull https://git.openjdk.org/jdk.git pull/13762/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 13762

View PR using the GUI difftool:
$ git pr show -t 13762

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13762.diff

Webrev

Link to Webrev Comment

@jnimeh
Copy link
Member Author

jnimeh commented May 2, 2023

/issue 8179502

@jnimeh
Copy link
Member Author

jnimeh commented May 2, 2023

/csr needed

@jnimeh jnimeh marked this pull request as ready for review May 2, 2023 21:14
@bridgekeeper
Copy link

bridgekeeper bot commented May 2, 2023

👋 Welcome back jnimeh! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

@openjdk openjdk bot added the csr Pull request needs approved CSR before integration label May 2, 2023
@openjdk
Copy link

openjdk bot commented May 2, 2023

@jnimeh This issue is referenced in the PR title - it will now be updated.

@openjdk
Copy link

openjdk bot commented May 2, 2023

@jnimeh an approved CSR request is already required for this pull request.

@openjdk
Copy link

openjdk bot commented May 2, 2023

@jnimeh The following label will be automatically applied to this pull request:

  • security

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

@openjdk openjdk bot added the security security-dev@openjdk.org label May 2, 2023
@openjdk openjdk bot added the rfr Pull request is ready for review label May 2, 2023
@mlbridge
Copy link

mlbridge bot commented May 2, 2023

Webrevs

}

// Determine if "ms" is on the end of the string
boolean isMillis = propVal.toLowerCase().endsWith("ms");
Copy link
Contributor

Choose a reason for hiding this comment

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

Shall we allow the s suffix as well? This makes it clear that a value is in seconds.

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, all the existing documentation already states that they are in seconds. That was why I didn't add any additional suffixes. The goal was to make it so folks don't need to make any changes if the existing seconds-level granularity is sufficient for them.

Copy link
Contributor

Choose a reason for hiding this comment

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

I don't mean not to support bare numbers. It's just a little unfair that millisecond has a suffix but second does not. We can support all of "1", "1s", and "1000ms".

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, we can make that change.

@seanjmullan
Copy link
Member

I think you should also apply the cert and CRL timeouts to the LDAPCertStore implementation, using the JNDI properties: com.sun.jndi.ldap.connect.timeout and com.sun.jndi.ldap.read.timeout.

Copy link
Member

Choose a reason for hiding this comment

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

I see there is no way to individually control the OCSP read and connect timeouts like there is for certs and CRLs. Perhaps this isn't as big an issue, but when you set the OCSP timeout, it really means 2x what you set.

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I noticed that too. I wasn't sure if we needed to make a change there. I opted to leave well-enough alone since nobody was asking for it and it's one less property to keep track of. All of these property sets end up with a max latency of connect-timeout + read-timeout, and by default they are set to the same values. So in practice much of the time they are all 2x.

It's easy enough I think to make a separate property for com.sun.security.ocsp.readtimeout and then the existing .timeout property would be for connect timeouts (keeping in line with the other props). I don't think it will introduce significant risk but I will highlight that in the CSR.

Copy link
Member Author

Choose a reason for hiding this comment

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

I think you should also apply the cert and CRL timeouts to the LDAPCertStore implementation, using the JNDI properties: com.sun.jndi.ldap.connect.timeout and com.sun.jndi.ldap.read.timeout.

I will look into this.

Copy link
Member Author

Choose a reason for hiding this comment

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

I've added the OCSP readtimeout property, seems to be working well. As discussed offline we'll hold off on the LDAP changes for now.

def = 0;
}

String propVal = System.getProperty(prop, "").trim();
Copy link
Member

Choose a reason for hiding this comment

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

You should call privilegedGetProperty here instead of System.getProperty so the call is wrapped in doPrivileged when an SM is active.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good catch. Will fix.


// Next check to make sure the string is built only from digits
if (propVal.matches("^\\d+$")) {
int timeout = Integer.parseInt(propVal);
Copy link
Member

Choose a reason for hiding this comment

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

Is this guaranteed never to throw NumberFormatException? It might be safer to catch it just in case.

Copy link
Member Author

@jnimeh jnimeh May 22, 2023

Choose a reason for hiding this comment

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

I'll change this to catch NFE, but I'm pretty sure the pattern will only ever return true if the string is comprised solely of digits from start to end - I could never get a string that would pass when it shouldn't. But point taken, better safe than sorry.

@jnimeh
Copy link
Member Author

jnimeh commented May 22, 2023

@seanjmullan if you have a chance would you mind taking a quick look at the release note for this change? (https://bugs.openjdk.org/browse/JDK-8308582)
It is pretty close to the CSR solution text, but I tried to trim it down a little. It's still pretty long, but there's a lot to convey.

Comment on lines 207 to 211
if (dbg != null) {
dbg.println("Warning: Unexpected " + nfe +
" for timeout value " + propVal +
". Using default value of " + def + " msec.");
}
Copy link
Member

Choose a reason for hiding this comment

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

This would also be useful debug for the else case on line 214-216 if the value is not an integer.

Copy link
Member Author

Choose a reason for hiding this comment

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

Sounds good, I can add that.

@@ -127,8 +128,12 @@ class URICertStore extends CertStoreSpi {
// allowed when downloading CRLs
private static final int DEFAULT_CRL_READ_TIMEOUT = 15000;

// Default connect and read timeouts for CA certificate fetching (15 sec)
Copy link
Member

Choose a reason for hiding this comment

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

Does 15 seconds make sense as the default timeout, especially for certs? CRLs are generally larger than certs, so a longer read timeout makes sense.

I'm ok with keeping these default values the same for consistency, but I think we should re-evaluate each of these default timeouts and compare them to other products/technologies to see if some adjustments may be needed - can you file a follow-on RFE for that?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, I can make a follow on for that.

Copy link
Member Author

Choose a reason for hiding this comment

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

@openjdk openjdk bot removed the csr Pull request needs approved CSR before integration label May 23, 2023
Copy link
Member

@seanjmullan seanjmullan left a comment

Choose a reason for hiding this comment

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

Looks good. I think there may be value in moving some of the test code into the testlibrary, like the AIA and CRL https servers so other tests can use it, but we can explore that more later if the opportunity arises.

@openjdk
Copy link

openjdk bot commented May 23, 2023

@jnimeh This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts

Reviewed-by: mullan

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 18 new commits pushed to the master branch:

  • 9e196b3: 8308565: HttpClient: Sanitize logging while stopping
  • 582ddeb: 8308545: java/net/httpclient/ShutdownNow.java fails with "stream 1 cancelled"
  • 1cfb265: 8307814: In the case of two methods with Record Patterns, the second one contains a line number from the first method
  • eb11508: 8308281: Java snippets in the FFM API need to be updated
  • 26227a6: 8305073: Fix VerifyLoopOptimizations - step 2 - verify idom
  • 80d7de7: 8305582: Compiler crash when compiling record patterns with var
  • e559613: 8308500: ZStatSubPhase::register_start should not call register_gc_phase_start if ZAbort::should_abort()
  • bdd2402: 8260943: C2 SuperWord: Remove dead vectorization optimization added by 8076284
  • 4f0f776: 8308403: [s390x] separate remaining_cargs from z_abi_160
  • 06b0a5e: 8302652: [SuperWord] Reduction should happen after loop, when possible
  • ... and 8 more: https://git.openjdk.org/jdk/compare/8474e693b4404ba62927fe0e43e68b904d66fbde...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

@openjdk openjdk bot added the ready Pull request is ready to be integrated label May 23, 2023
@jnimeh
Copy link
Member Author

jnimeh commented May 23, 2023

/integrate

@openjdk
Copy link

openjdk bot commented May 23, 2023

Going to push as commit 2836c34.
Since your change was applied there have been 28 commits pushed to the master branch:

  • 8ffa264: 8306698: Add overloads to MethodTypeDesc::of
  • 6b27dad: 8301154: SunPKCS11 KeyStore deleteEntry results in dangling PrivateKey entries
  • ed0e956: 8308716: ProblemList java/util/concurrent/ScheduledThreadPoolExecutor/BasicCancelTest.java with genzgc on windows-x64
  • bddf483: 8303942: os::write should write completely
  • ab241b3: 8306706: Support out-of-line code generation for MachNodes
  • 710453c: 8308016: Use snippets in java.io package
  • e9320f3: 8308116: jdk.test.lib.compiler.InMemoryJavaCompiler.compile does not close files
  • 97d3b27: 8307523: [vectorapi] Optimize MaskFromLongBenchmark.java
  • bb0ff48: 8305091: Change ChaCha20 cipher init behavior to match AES-GCM
  • c0c4d77: 8308544: Fix compilation regression from JDK-8306983 on musl libc
  • ... and 18 more: https://git.openjdk.org/jdk/compare/8474e693b4404ba62927fe0e43e68b904d66fbde...master

Your commit was automatically rebased without conflicts.

@openjdk openjdk bot added the integrated Pull request has been integrated label May 23, 2023
@openjdk openjdk bot closed this May 23, 2023
@openjdk openjdk bot removed ready Pull request is ready to be integrated rfr Pull request is ready for review labels May 23, 2023
@openjdk
Copy link

openjdk bot commented May 23, 2023

@jnimeh Pushed as commit 2836c34.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

@jnimeh jnimeh deleted the JDK-8179502 branch December 12, 2023 19:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
integrated Pull request has been integrated security security-dev@openjdk.org
3 participants