Consider doing certificate revocation checking by default for SslStream/HttpClient

[rzikm]

By default, both SslStream and HttpClient will not perform any revocation checking. We should consider changing to a secure defaults.

Note that there is some inconsistency in different ways to configure Chain verification.

X509ChainPolicy specifies Online by default

runtime/src/libraries/System.Security.Cryptography/src/System/Security/Cryptography/X509Certificates/X509ChainPolicy.cs

Line 128 in 6249fd2

_revocationMode = X509RevocationMode.Online;

However, SslAuthenticationOptions do not

runtime/src/libraries/System.Net.Security/src/System/Net/Security/SslClientAuthenticationOptions.cs

Line 14 in 1815306

private X509RevocationMode _checkCertificateRevocation = X509RevocationMode.NoCheck;

runtime/src/libraries/System.Net.Security/src/System/Net/Security/SslServerAuthenticationOptions.cs

Line 12 in 1815306

private X509RevocationMode _checkCertificateRevocation = X509RevocationMode.NoCheck;

And, by their extension, neither will SocketsHttpHandler. This leads to inconsistent behaviors, consider following

{
    System.Console.WriteLine("default HttpClient");
    using HttpClient client = new HttpClient();
    var response = await client.GetAsync("https://www.microsoft.com");
}

{
    System.Console.WriteLine("default SocketsHttpHandler");
    using HttpClient client = new HttpClient(new SocketsHttpHandler { });
    var response = await client.GetAsync("https://www.microsoft.com");
}

{
    System.Console.WriteLine("default SocketsHttpHandler with default ctor chain policy");
    using HttpClient client = new HttpClient(new SocketsHttpHandler
    {
        SslOptions = {
            CertificateChainPolicy = new X509ChainPolicy()
        }
    });
    var response = await client.GetAsync("https://www.microsoft.com");
}

When I add debug console log of the effective revocation check mode, I get

❯ dotnet run
default HttpClient
ChainPolicy.RevocationMode = NoCheck
default SocketsHttpHandler
ChainPolicy.RevocationMode = NoCheck
default SocketsHttpHandler with default ctor chain policy
ChainPolicy.RevocationMode = Online

Despite not explicitly configuring revocation check mode in either case.

Note that this is also in line with new analyzers for CA5399: Enable HttpClient certificate revocation list check analyzer.

[dotnet-policy-service]

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

[dotnet-policy-service]

Added needs-breaking-change-doc-created label because this issue has the breaking-change label.

1. Create and link to this issue a matching issue in the dotnet/docs repo using the breaking change documentation template, then remove this needs-breaking-change-doc-created label.

Tagging @dotnet/compat for awareness of the breaking change.

[tmds]

@rzikm this can give some issues on distros that have SHA1 disabled (like RHEL 9) when accessing certain websites (like redhat.com and blob.core.windows.net). See #97973.

cc @omajid

[rzikm]

Thanks for mentioning that, there are also some other downsides:

• this will break users in isolated network environments where outbound CRL checks are blocked
• possible perf impact (unless OCSP stapling or some other mechanism is used, client has to make an outbound network request during each handshake).

All of which should weigh on the decision, and should be documented, should we make the change.

[HighPerfDotNet]

Too big of a change for default and I think it was correct to have it off by default.

[rzikm]

cc @bartonjs since this touches certificate validation.

[vcsjones]

unless OCSP stapling

For what it's worth, OCSP (and thus stapling) is kind of disfavored in public WebPKI now. Let's Encrypt for example will shut down their OCSP responders in August 2025, favoring CRL.

[rzikm]

@vcsjones that might be getting a little off topic, but I would like to know the motivation behind that, is there some article which explains it?

[vcsjones]

@rzikm

is there some article which explains it?

This is Let's Encrypt's announcement: https://letsencrypt.org/2024/12/05/ending-ocsp/ and has some further links back to when they initially announced their intention to do so.

CA/B Forum ballot SC063 is the ballot that made CRL mandatory, and OCSP optional.

The general gist of it is, OCSP leaks too much privacy information, OCSP stapling failed to be widely deployed and is often best effort. It has holes, and privacy advocates don't like holes. The fix for that was "must staple", but that was even less widely deployed.

The general direction of WebPKI is to issue short-lived certificates. If a certificate's lifetime is short, shorter than the nextUpdate of CRLs, then short-lived certificates are not required to include CRL or OCSP at all. Their lifetime is shorter than when most clients would get up-to-date revocation information anyway.

Here is a link to the SC063 ballot: https://cabforum.org/2023/07/14/ballot-sc063v4-make-ocsp-optional-require-crls-and-incentivize-automation/

The primary mechanism of certificate invalidation for these short-lived certificates would be through certificate expiry. CAs may optionally revoke short-lived certificates. The initial maximum certificate validity is aligned with the existing maximum values for CRL “nextUpdate” and OCSP response validity allowed by the BRs today.

Let's Encrypt will start offering six day certificates soon. https://letsencrypt.org/2025/01/16/6-day-and-ip-certs/

I've mostly singled out Let's Encrypt here, but they tend to lead advances in policy changes, and the general WebPKI community feels that short lived certificates is a better solution than revocation.

This actually brings us to an on-topic question:

If a major CA is going to start issuing certificates that has no revocation information in it at all, what is the behavior of Online revocation checking? Does it pass, because there is no revocation information, or does it fail, saying "I can't check for revocation information"?

[bartonjs]

I'm of (at least) two minds.

• Security-wise, using the more security-focused default is better.
• Compat-wise, changing things is bad.

Checking revocation takes more time (generally negligent) and memory (sometimes a lot, thanks to what I'd consider poor CRL hygiene and how malloc works), and sometimes involves the most flaky of all computer things: the network.

If you get the CRL (or OCSP Response) you can get a clear "revoked", which should obviously fail the connection. For OCSP you can get an authoritative "not revoked", and for CRL you can get "not on the CRL, so not revoked by inference" giving a clear "this step says don't fail". OCSP can also give the ever unhelpful "I don't know" (e.g. I'm an OCSP endpoint and the latest CRL I was fed is too old, so I can't give answers), and both of them can just fail to connect/communicate. So, what do we do about the unclear state?

By default, X509Chain says "you asked for revocation, and I don't know the answer, so... fail" (fail-closed). If we were just starting .NET I assume we'd start HttpClient in "check revocation, and fail-closed". However, we're not. So compat rears its ugly head and says "maybe we should fail open". Okay, so you set the appropriate flags on the policy instance and it can now fail open. So, cool. Now someone who has MITM and a compromised key just needs to block access to the revocation endpoint. Which they can do, since they have MITM. Whee, the exact scenario we wanted to fail for doesn't fail. (Of course, someone with a pre-cached CRL (or OCSP Response) will see the revocation).

So, yeah, it's tricky. A complicated (and browser-like) answer could be to look at the SNI hostname, and if it's in the Alexa Top 100 (or whatever list) then require revocation... but then you have to figure out how to get and maintain your list.

The general gist of it is, OCSP leaks too much privacy information,

That's why .NET on Linux checks 1) stapled OCSP (no privacy leak, good performance), 2) CRL (no privacy leak, uses more memory, "almost always" cached), 3) live OCSP (potential privacy leak, low memory, more likely to involve a network request)

[bartonjs]

Alexa Top 100

And today I've learned that is an almost 3 years out of date reference, as it stopped being published in May 2022. Who knew?