8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts#13762
8179502: Enhance OCSP, CRL and Certificate Fetch Timeouts#13762jnimeh wants to merge 8 commits intoopenjdk:masterfrom
Conversation
|
/issue 8179502 |
|
/csr needed |
|
👋 Welcome back jnimeh! A progress list of the required criteria for merging this PR into |
|
@jnimeh This issue is referenced in the PR title - it will now be updated. |
Webrevs
|
| } | ||
|
|
||
| // Determine if "ms" is on the end of the string | ||
| boolean isMillis = propVal.toLowerCase().endsWith("ms"); |
There was a problem hiding this comment.
Shall we allow the s suffix as well? This makes it clear that a value is in seconds.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
Okay, we can make that change.
|
I think you should also apply the cert and CRL timeouts to the |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
I think you should also apply the cert and CRL timeouts to the
LDAPCertStoreimplementation, using the JNDI properties:com.sun.jndi.ldap.connect.timeoutandcom.sun.jndi.ldap.read.timeout.
I will look into this.
There was a problem hiding this comment.
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(); |
There was a problem hiding this comment.
You should call privilegedGetProperty here instead of System.getProperty so the call is wrapped in doPrivileged when an SM is active.
|
|
||
| // Next check to make sure the string is built only from digits | ||
| if (propVal.matches("^\\d+$")) { | ||
| int timeout = Integer.parseInt(propVal); |
There was a problem hiding this comment.
Is this guaranteed never to throw NumberFormatException? It might be safer to catch it just in case.
There was a problem hiding this comment.
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.
|
@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) |
| if (dbg != null) { | ||
| dbg.println("Warning: Unexpected " + nfe + | ||
| " for timeout value " + propVal + | ||
| ". Using default value of " + def + " msec."); | ||
| } |
There was a problem hiding this comment.
This would also be useful debug for the else case on line 214-216 if the value is not an integer.
There was a problem hiding this comment.
Sounds good, I can add that.
| // allowed when downloading CRLs | ||
| private static final int DEFAULT_CRL_READ_TIMEOUT = 15000; | ||
|
|
||
| // Default connect and read timeouts for CA certificate fetching (15 sec) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Yes, I can make a follow on for that.
There was a problem hiding this comment.
seanjmullan
left a comment
There was a problem hiding this comment.
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.
|
@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: 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
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 |
|
/integrate |
|
Going to push as commit 2836c34.
Your commit was automatically rebased without conflicts. |
This set of enhancements extends the allowed syntax for the
com.sun.security.ocsp.timeout,com.sun.security.crl.timeoutandcom.sun.security.crl.readtimeoutSystem 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.timeoutandcom.sun.security.cert.readtimeoutwhich 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 thecom.sun.security.enableAIAcaIssuersproperty is true (default false).JBS: https://bugs.openjdk.org/browse/JDK-8179502
CSR: https://bugs.openjdk.org/browse/JDK-8300722
Progress
Issues
Reviewers
Reviewing
Using
gitCheckout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/13762/head:pull/13762$ git checkout pull/13762Update a local copy of the PR:
$ git checkout pull/13762$ git pull https://git.openjdk.org/jdk.git pull/13762/headUsing Skara CLI tools
Checkout this PR locally:
$ git pr checkout 13762View PR using the GUI difftool:
$ git pr show -t 13762Using diff file
Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/13762.diff
Webrev
Link to Webrev Comment