Skip to content
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

[release/8.0] Fix server-side OCSP stapling on Linux #96838

Merged
merged 3 commits into from
Jan 16, 2024

Conversation

rzikm
Copy link
Member

@rzikm rzikm commented Jan 11, 2024

Backport of PR #96792, PR #96448, PR #90200 and PR #96972.

Fixes #96770, #96659 and #89907

Description

Regression: No, .NET 6 didn't have OCSP staple feature.
Customer: Internal partner team - blocking migration from Windows to Linux.

OCSP (Online Certificate Status Protocol) stapling is an optimization where instead of clients individually retrieving revocation status of the server certificate, server will fetch the OCSP response itself and send it to clients during connection handshake. The authenticity of the response is assured by a digital signature.

First bug in .NET 7.0+ ... An invalid response can get cached and the server would fail to refresh it. The server would then keep sending the old, cached and potentially malformed OCSP response. This bug is triggered when either:

Second bug in .NET 7.0+ ... Validation of OCSP response always fails when the method of "delegated signing" is used (delegated signing means that the OCSP response is signed by a special certificate delegated by the server certificate issuer).

  • Note that validation when receiving OCSP response on client-side is not affected by this bug and is extensively tested, only the server part is affected by the bug.
  • Server validating the OCSP response before sending it out is only to play nice and not send invalid OCSP responses out. This bug DOES NOT create security vulnerability because clients are expected to independently validate the OCSP response themselves.
    Fixed in main by PR Add entire issuer chain to trusted X509_STORE when stapling OCSP_Response #96792

The two issues mentioned above may lead to following undesired behaviors:

  • Server caches an invalid OCSP staple (e.g. error page due to OCSP server outage), and keeps sending it out.
  • Server stops refreshing the OCSP staple and keeps sending the old one even after its validity expired.
  • Server sends out OCSP staple which it does not consider valid

Customer Impact

Android clients cannot connect to .NET 7+ servers affected by this bug because the OCSP information may get outdated (and not refreshed) and Android 9+'s application default security restrictions don't allow HTTP connections by default.

Regression

No, sending OCSP staples from .NET servers is a new feature in .NET 7.

Testing

Locally reproduced affected scenario and extensively tested manually.

Customer validated private 7.0 bits.

There is extensive existing test coverage on client-side OCSP usage/validation. Missing E2E server-side automated test coverage is planned for upcoming weeks.

Risk

Small to medium. Code touched by this PR is not used in other code paths than OCSP, so only "Sending OCSP staples from a server" scenario is affected.

rzikm and others added 2 commits January 11, 2024 14:20
…onse (dotnet#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 check.

* Add 5s back-off after failed OCSP querry
@ghost
Copy link

ghost commented Jan 11, 2024

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

Issue Details

Description

Customer Impact

Regression

Testing

Risk

Package authoring signed off?

IMPORTANT: If this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.

Author: rzikm
Assignees: rzikm
Labels:

area-System.Net.Security

Milestone: -

@carlossanlop
Copy link
Member

I see this is still a draft. Friendly reminder that Tuesday January 16th 4pm is the Code Complete deadline for the February Release. If all requirements are met, please merge your PR before that date and time to ensure this fix gets included in that Release. Otherwise it will have to wait until March.

@rzikm rzikm marked this pull request as ready for review January 15, 2024 08:27
@rzikm rzikm requested a review from bartonjs January 15, 2024 08:28
@karelz karelz added Servicing-consider Issue for next servicing release review Servicing-approved Approved for servicing release os-linux Linux OS (any supported distro) and removed Servicing-consider Issue for next servicing release review labels Jan 15, 2024
@karelz
Copy link
Member

karelz commented Jan 16, 2024

Approved by Tactics (@SteveMCarroll) on 1/15 via email - label updated to Servicing-approved.

@carlossanlop
Copy link
Member

@karelz @rzikm can we get a sign-off for this PR as well?

@rzikm rzikm requested a review from wfurt January 16, 2024 19:25
Copy link
Member

@wfurt wfurt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

* Don't shorten OCSP expriation on failed server OCSP fetch

* Code review feedback
@wfurt wfurt merged commit 85c2772 into dotnet:release/8.0-staging Jan 16, 2024
118 of 121 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Feb 16, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Net.Security os-linux Linux OS (any supported distro) Servicing-approved Approved for servicing release
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants