-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Recover from failed OCSP download. #96448
Conversation
Tagging subscribers to this area: @dotnet/ncl, @bartonjs, @vcsjones Issue DetailsWhen performing OCSP stapling by server and we get invalid response from the OCSP server (either because we don't get any data back or parsing the OCSP response fails), the server will never try to fetch OCSP again because the This PR moves the This has a potential pitfall when the given OCSP server is unhealthy (and consistently returning bad response), then we would potentially issue many requests to it. But I understand that if server does not send OCSP staple then clients may fetch the staple themselves, so I am not 100% sure if mitigation from our side changes much. @bartonjs, @vcsjones, what do you think? If we should mitigate it, what mechanism do you suggest? exponential back-off, or maybe even a simple rate-limiting of max 1 request per x minutes?
|
src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs
Show resolved
Hide resolved
Very naive question - do servers ever request these from other servers, and if so, so they use this code? Just curious whether this is a case where Kestrel may have its own policy. |
if you mean if this is used in "server-to-server" scenarios, then yes. Technically, the initiator of the connection still acts the role of a client. and the receiver of the connection (the machine acting the server role) will run this code and send an OCSP staple if OCSP stapling was enabled (by SslStreamCertificateContext.Create with right parameters). Clients are requesting OCSP staple from the server by adding a specific extension to the ClientHello when initiating the connection. Right now, there is no API to control this extension from .NET (not even sure if it is present on all underlying platforms). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
BTW do we have test gap? With 5s delay we should be able to craft a test, right? |
The testing is not going to be straightforward because most of the code is private. I filed #96791 to track test coverage and will look into it some more once we fix the more urgent issues. |
* Recover from failed OCSP check. * Add 5s back-off after failed OCSP querry
* Recover from failed OCSP check. * Add 5s back-off after failed OCSP querry
* Add entire issuer chain to trusted X509_STORE when stapling OCSP_Response (#96792) * Add entire issuer chain to trusted X509_STORE when validating OCSP_Response * Code review feedback * More code review feedback * Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs Co-authored-by: Jeremy Barton <jbarton@microsoft.com> * Fix compilation * Always include root certificate --------- Co-authored-by: Jeremy Barton <jbarton@microsoft.com> * Recover from failed OCSP download. (#96448) * Recover from failed OCSP check. * Add 5s back-off after failed OCSP querry * Don't shorten OCSP expriation on failed server OCSP fetch (#96972) * Don't shorten OCSP expriation on failed server OCSP fetch * Code review feedback --------- Co-authored-by: Jeremy Barton <jbarton@microsoft.com>
* Recover from failed OCSP download. (#96448) * Recover from failed OCSP check. * Add 5s back-off after failed OCSP querry * Do not OCSP staple invalid OCSP responses * Add entire issuer chain to trusted X509_STORE when validating OCSP_Response Code review feedback More code review feedback Update src/libraries/System.Net.Security/src/System/Net/Security/SslStreamCertificateContext.Linux.cs Co-authored-by: Jeremy Barton <jbarton@microsoft.com> Fix compilation Always include root certificate * Fix compilation * Don't shorten OCSP expriation on failed server OCSP fetch (#96972) * Don't shorten OCSP expriation on failed server OCSP fetch * Code review feedback --------- Co-authored-by: Kevin Jones <kevin@vcsjones.com> Co-authored-by: Carlos Sánchez López <1175054+carlossanlop@users.noreply.github.com>
* Recover from failed OCSP check. * Add 5s back-off after failed OCSP querry
Fixes #96770
When performing OCSP stapling by server and we get invalid response from the OCSP server (either because we don't get any data back or parsing the OCSP response fails), the server will never try to fetch OCSP again because the
SslStreamCertificateContext._pendingDownload
field still contains the previous task. As a consequence, the server will stop sending OCSP staples after the failure.This PR moves the
_pendingDownload = null
assignment to a place where it is guaranteed to execute.This has a potential pitfall when the given OCSP server is unhealthy (and consistently returning bad response), then we would potentially issue many requests to it. But I understand that if server does not send OCSP staple then clients may fetch the staple themselves, so I am not 100% sure if mitigation from our side changes much. @bartonjs, @vcsjones, what do you think? If we should mitigate it, what mechanism do you suggest? exponential back-off, or maybe even a simple rate-limiting of max 1 request per x minutes?