-
Notifications
You must be signed in to change notification settings - Fork 5k
[ocsp stapling] reject incorrect http response if the status code is not 2xx #89908
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
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDraft a possible fix for #89907
|
Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones Issue DetailsDraft a possible fix for #89907
|
If the server really is indeed stapling a nonsense OCSP then I think a more appropriate fix would be to make sure that the stapled response is a well formed OCSP response, valid for the certificate, etc. This fix as written will still staple incorrect responses if happens to respond with non-OCSP content but with an HTTP 200 status code. Also, returning A more appropriate fix might be that in
We might consider parsing the content and, if it isn’t a parseable OCSP, then skipping the stapling. That still doesn’t address the problem where a wrong OCSP response might be stapled. |
we may still bail for anything > 400 @vcsjones ? The body is likely some kind of error message anyway. |
That seems reasonable, but not a complete fix. I would guess that there is greater than zero CAs out there that return an error result with an HTTP 200, or someone has a proxy, captive portal, etc. that intercepts HTTP requests and may return HTTP 200 pages. |
There should be a path when we download it where we crack the payload to extract the notAfter value. That path should be able to be enhanced to say not just "I didn't get a date from it" (it's optional), but also "it's not a valid response". I kinda thought it was already checking that, but apparently not. (Leaving a note in case someone has the time to dig before I do) |
So, I don't think the proposed fix would even help, since it should be hitting the same "we ignored this" case that should already be happening. If a bad response got in there, it sort of feels like some very wonky thing happened, like that array got overwritten? CryptoNative_X509DecodeOcspToExpiration looks like it might pass if there was a legitimate response plus some dangling garbage, which probably isn't what was intended, but also doesn't sound like the problem that was experienced. |
yeah, I agree the original fix won't work (and also break the redirect flow by typo. Checking status code>=400 is better than current) So the current idea is to validate the OCSP content, and cache the correct format only. Is my understanding correct? Then, for the failed case, i.e. a bad response status code or bad content, does it still "return null" for DownloadOcsp request? |
Since the proposed fix is not correct (it's invalidating the redirect handler code immediately below it), and doesn't feel like the right shape at all (an HTTP 200 with an error message is still "not a valid OCSP payload"), I'm going ahead and closing this PR. We'll continue discussion/investigation on the issue instead of the PR. |
Draft a possible fix for #89907