App-level security policy for certificate revocation check

[zivcaspi]

A major change from the .NET Framework networking libraries to .NET is the elimination of an app-level service point management. This is usually a good thing. One aspect in which it's lacking, however, is that there's no option for applications that host multiple 3rd-party libraries to enforce security policies on outgoing connections, such as checking the TLS certificate revocation list before agreeing to communicate with a web service.

Some library authors (for example, Azure SDK for .NET) provide the means for the hosting application to inject such policies into the library (for example, by injecting IHttpClientFactory.) Unfortunately, many libraries do not have this ability, leaving the application developer having to choose between security and functionality.

We need a way for applications to force a specific policy on CRL checks. The least-disruptive way I can think of to do this is as follows:

1. .NET to provide a public static get/set property:

public class SslClientAuthenticationOptions {
    public static System.Security.Cryptography.X509Certificates.X509RevocationMode? 
        OverrideCertificateRevocationCheckMode
            { get; set; }
}

2. Modify SslClientAuthenticationOptions.CertificateRevocationCheckMode.get so that it will return OverrideCertificateRevocationCheckMode, if that value has been set, if the current value of CertificateRevocationCheckMode is NoCheck. This prevents "downgrade attacks" by libraries.

(As far as I understand, this will have another benefit -- allowing users of HttpClient/HttpClientHandler to benefit from X509RevocationMode.Offline.)

[dotnet-policy-service]

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

[wfurt]

Any thoughts on this @bartonjs @GrabYourPitchforks @blowdart ?
This is certainly not first case when somebody wants to enforce policy more globally.

[blowdart]

Of course a policy that can be set globally can be unset globally by code lurking in a nuget package, so it's 50% a security improvement and 50% a security vulnerability.

If you're going to do it you probably need to have a "soft fail" option as well, where if the call times out it's taken as success.

Partly this is needed is due to it being incredibly hard for library authors to know what to do about http clients, or client factories, or configuration, heck, I've hit that myself and had a two page word doc rant I never sent 🤷‍♂️, and so library devs just don't give any extensibility points. There's a lack of written guidance and samples for that.

[bartonjs]

I think mutable static options are always a terrible idea.

If there's a desire for forcing something in a process, it should be AppContext or Environment Variable. Read once, never can change again.

[blowdart]

Like we did with binary formatter.

But then can you override it on a per client basis? And again we're back to having to audit all your dependencies

[zivcaspi]

Of course a policy that can be set globally can be unset globally by code lurking in a nuget package, so it's 50% a security improvement and 50% a security vulnerability.

The goal is not to protect against rogue code running in your process -- if you have that then nothing can help you (as the failure of the security model of .NET Framework shows.) The goal is to strengthen the security policy of innocent libraries that do not stand up to the stricter security policy of the application.

If you want to protect against rogue libraries that try to downgrade a security policy, we can modify the policy set functionality to ignore downgrade requests.

[zivcaspi]

I think mutable static options are always a terrible idea.

If there's a desire for forcing something in a process, it should be AppContext or Environment Variable. Read once, never can change again.

I'm not against an app switch similar to the new-and-improved timer switch that was added to .NET Framework timers (for example). Note that controlling such a setting via an environment variable adds complexity to the app's author (who now needs to change the launch process to set the variable instead of controlling the setting in the app's package.)

[zivcaspi]

Like we did with binary formatter.

But then can you override it on a per client basis? And again we're back to having to audit all your dependencies

No, you can't override it per client; that's the whole point.

[blowdart]

Like we did with binary formatter.
But then can you override it on a per client basis? And again we're back to having to audit all your dependencies

No, you can't override it per client; that's the whole point.

Then I am absolutely against such a feature. It breaks the promises HttpFactory makes and stops developers making informed, such as self-signed certs common in container scenarios or performance-based decisions.