Skip to content

[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

Closed
wants to merge 1 commit into from

Conversation

cdlliuy
Copy link

@cdlliuy cdlliuy commented Aug 3, 2023

Draft a possible fix for #89907

@ghost ghost added area-System.Net.Http community-contribution Indicates that the PR has been added by a community member labels Aug 3, 2023
@ghost
Copy link

ghost commented Aug 3, 2023

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

Draft a possible fix for #89907

Author: cdlliuy
Assignees: -
Labels:

area-System.Net.Http, community-contribution

Milestone: -

@ghost
Copy link

ghost commented Aug 3, 2023

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

Issue Details

Draft a possible fix for #89907

Author: cdlliuy
Assignees: -
Labels:

area-System.Security, community-contribution

Milestone: -

@adamsitnik adamsitnik requested a review from bartonjs August 3, 2023 11:16
@vcsjones
Copy link
Member

vcsjones commented Aug 3, 2023

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 null for >= HTTP 300 will break following redirects.

A more appropriate fix might be that in

if (SSL_set_tlsext_status_ocsp_resp(ssl, copy, len) != 1)

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.

@wfurt
Copy link
Member

wfurt commented Aug 3, 2023

we may still bail for anything > 400 @vcsjones ? The body is likely some kind of error message anyway.

@vcsjones
Copy link
Member

vcsjones commented Aug 3, 2023

still bail for anything > 400 @vcsjones ?

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.

@bartonjs
Copy link
Member

bartonjs commented Aug 3, 2023

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)

@bartonjs
Copy link
Member

bartonjs commented Aug 3, 2023

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.

@cdlliuy
Copy link
Author

cdlliuy commented Aug 4, 2023

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?
will "retrying the connection to ocsp responder" help here in case it is an intermittent failure.

Then, for the failed case, i.e. a bad response status code or bad content, does it still "return null" for DownloadOcsp request?
When "returning null", what will happen in client side? will client side fall back to client-driven ocsp? or just fail the https connection request?

@bartonjs
Copy link
Member

bartonjs commented Aug 4, 2023

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.

@bartonjs bartonjs closed this Aug 4, 2023
@ghost ghost locked as resolved and limited conversation to collaborators Sep 3, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Security community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants