Open mddddb opened 1 year ago
Tagging subscribers to this area: @dotnet/ncl See info in area-owners.md if you want to be subscribed.
Author: | mddddb |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `area-System.Net.Http`, `untriaged` |
Milestone: | - |
Tagging subscribers to this area: @dotnet/ncl, @vcsjones See info in area-owners.md if you want to be subscribed.
Author: | mddddb |
---|---|
Assignees: | - |
Labels: | `api-suggestion`, `area-System.Net.Security`, `untriaged` |
Milestone: | - |
@karelz @wfurt @ManickaP
API proposal LGTM, the only question is whether we want to have an async certificate selection callback as well, while we are at it. Thoughts? @wfurt.
Not critical for 8.0, but would be nice to get it in an LTS release. Putting to Future for now.
I think the changes in HttpClientHandler are possibly problematic. AFAIK we did not change the shape for long time for compat reasons. It would also expose it for all platform handlers and I'm not sure if that really doable.
SocketsHttpHandler
already expose SslClientAuthenticationOptions
so it can be used directly.
Having two almost same functions is not great. But we can make them mutual exclusive in validation.
Simple workaround IMHO would be letting handshake always to continue and do extra validation after it is done. In practice, this what we do anyway (the callback runs after handshake is completed at TLS level) at the moment I would assume failure would be rare case (e.g. mostly you connecting to valid sites)
Note that with 7.0 one can influence the default validation via CertificateChainPolicy e.g. disable all online check to avoid interference.
I don't think we would be able to implement the async callback in AndroidMessageHandler
and NSUrlSessionHandler
without blocking. I suggest making this API specific to SocketsHttpHandler
.
@karelz @wfurt @ManickaP, just curious, is there any update on the planning for this?
@mddddb we currently do not have plans for implementing it. It will not fit into 8.0 for sure. We can revisit it for 9.0+, however given the troubles it brings and the low demand (no upvotes on top post), I may be cut eventually.
Background and motivation
It is currently possible to have a custom remote certificate validation for HttpClient using https://github.com/dotnet/runtime/blob/4cbe6f99d23e04c56a89251d49de1b0f14000427/src/libraries/System.Net.Http/src/System/Net/Http/HttpClientHandler.cs#L261 and https://github.com/dotnet/runtime/blob/a5f3676cc71e176084f0f7f1f6beeecd86fbeafc/src/libraries/System.Net.Security/src/System/Net/Security/SslClientAuthenticationOptions.cs#L26 However, it is currently impossible to have async validation without sync-over-async, since the signature of the delegate is as below:
public delegate bool RemoteCertificateValidationCallback(object sender, X509Certificate? certificate, X509Chain? chain, SslPolicyErrors sslPolicyErrors);
I.e.
Original discussion: https://github.com/dotnet/runtime/discussions/78761
API Proposal
API Usage
Alternative Designs
No response
Risks
Replacing the current sync callback is a breaking change. But introducing a new one and having 2 callbacks for the same reason is not a good solution either