CRL: Enforce proper handling of ASN1_DATE validation results #29107
Conversation
b2e49fc to
2a23d05
Compare
shahsb
left a comment
There was a problem hiding this comment.
This targets the CRL path. Do you suspect this issue might exist for other object types that we should also look at?
| * lastUpdate and treat missing or invalid values as a failure. | ||
| */ | ||
| if (crl->crl.lastUpdate == NULL) { | ||
| crl->flags |= EXFLAG_INVALID; |
There was a problem hiding this comment.
could you elaborate a little on the potential scenarios where the old behavior of accepting an invalid CRL could have been exploited? Understanding the real-world impact would be really valuable.
There was a problem hiding this comment.
This PR primarily addresses invalidityDate; its absence can have specific security and functional impacts during verification. Other time fields in the CRL are also validated, as this check is inexpensive (in case of ASN.1 parser failure, we simply test for NULL). There is some leniency, we can accept UTC where the RFC requires GENERALIZED TIME, but if the time is completely invalid, it makes sense to reject the CRL immediately rather than waiting for further checks during verification.
| && TEST_ptr_null((tss = crl_clear_err_parse(kInvalidDateSS))) | ||
| && TEST_true(err_chk(ERR_LIB_ASN1, ASN1_R_GENERALIZEDTIME_IS_TOO_SHORT)) | ||
| && TEST_ptr_null((utc = crl_clear_err_parse(kInvalidDateUTC))) | ||
| && TEST_true(err_chk(ERR_LIB_ASN1, ASN1_R_WRONG_TAG)); |
There was a problem hiding this comment.
This change looks great. I was wondering if we could add a few more test cases to cement the behavior? Specifically, testing for a wider variety of malformed date formats (like invalid time zones, bad characters, etc.) might help ensure we've covered all the bases. I can help draft these if that's useful.
There was a problem hiding this comment.
This would be a separate effort and PR. If you want to work on such test cases, that would be certainly welcome.
| */ | ||
| if (nid == NID_invalidity_date) { | ||
| if ((inv_date = X509V3_EXT_d2i(ext)) == NULL) { | ||
| crl->flags |= EXFLAG_INVALID; |
There was a problem hiding this comment.
Should we consider adding a note about these stricter validations in the CHANGES file or the relevant man pages (like openssl-crl)? It might save some time for users who suddenly find previously accepted CRLs are now being rejected, helping them understand why.
There was a problem hiding this comment.
Yes, good point. CHANGES.md entry should definitely be added.
There was a problem hiding this comment.
Good reminder. I still have some other CRL issues in the queue that also relate to error reporting and actually to openssl crl usability, but I was planning to open a PR for that later, once I have a PR ready that fixes the specific problems. There can definitely be a different opinion on this, but my plan was to save time and not touch the shared parts in every CRL PR.
| X509_CRL *tmm = NULL, *tss = NULL, *utc = NULL; | ||
| int test = 0; | ||
|
|
||
| test = TEST_ptr_null((tmm = crl_clear_err_parse(kInvalidDateMM))) |
There was a problem hiding this comment.
I'm curious if you've had a chance to test this with a variety of real-world or fuzzed CRLs to see if the new validation behaves as expected in all edge cases? If there's any area where I could help with validation testing, please let me know.
There was a problem hiding this comment.
I don’t have anything beyond the existing tests and the new ones I’ve added. There’s definitely room for additional CRLs that would cover the existing use cases and thoroughly cover the cases in the code (coverage).
shahsb
left a comment
There was a problem hiding this comment.
Does this user-visible failure change warrant a changelog entry?
|
@n13l Please rebase |
db17efc to
9d77f0f
Compare
ASN1 correctly validates date fields and reports errors to the error stack. Previously, even when validation failed, a CRL object was still returned and could, in some cases, be successfully used for verification. This change fixes that behavior by ensuring validation errors are properly handled and invalid CRLs are rejected. Fixes openssl#27445
9b47991 to
1cc03da
Compare
CRL: Enforce proper handling of ASN1_DATE validation results
ASN1 correctly validates date fields and reports errors to the error stack. Previously, even when validation failed, a CRL object was still returned and could, in some cases, be successfully used for verification.
This change fixes that behavior by ensuring validation errors are properly handled and invalid CRLs are rejected.
Fixes #27445
The change in behavior can also be observed in the command line, but unfortunately, in this case, only the top error in the stack is visible. If it also displayed the correct ASN1_R_GENERALIZEDTIME_IS_TOO_SHORT, it could be useful for the user.