RemoteCertificateValidationCallback for HttpWebRequest

[justcoding121]

The current implementation of HttpWebRequest in .Net 4.6 lacks RemoteCertificateValidationCallback similar to that of SslStream class. This makes mutual authentication impossible, especially when client becomes aware of mutual authentication enforced by server only after SSL handshake has been initiated.

Currently all certificate callbacks for HttpWebRequest is managed by ServicePointManager class, I request to include this feature in corefx releases.

Please see this question in SO.

[davidsh]

cc: @CIPop @SidharthNabar

Your comment is about .NET Framework 4.6 (Desktop) which isn't being tracked specifically in this GitHub repo. The implementation in this repo is about CoreCLR/CoreFx implementation of the System.Net.Http API surface.

HttpWebRequest in CoreFx is implemented differently. The ServicePointManager architecture is not part of CoreFx. In fact, HttpWebRequest is implemented on top of the System.Net.Http.HttpClient API surface in CoreFx and uses a different architecture for the underlying HTTP stack.

HttpWebRequest API surface, part of the System.Net.Requests package/contract is considered a 'legacy' API. We encourage developers to look at System.Net.Http package and associated APIs. In particular for Windows developers, the System.Net.Http.WinHttpHandler package API has a similar property delegate that can be used for SSL certificate validation callbacks. We also plan to "promote" this property to the platform-agnostic HttpClientHandler class in System.Net.Http.

We do not plan to add API surface such as RemoteCertificateValidationCallback to the HttpWebRequest API surface neither for .NET Framework 4.6 (Desktop) nor CoreFx implementations since we encourage devs to move to System.Net.Http.

[davidsh]

Also, for completeness, on .NET Framework (Desktop), there is the WebRequestHandler API that also has SSL certificate validation callback:

https://msdn.microsoft.com/en-us/library/system.net.http.webrequesthandler(v=vs.110).aspx

WebRequestHandler is only available for .NET Framework and not CoreFx.

[justcoding121]

That sounds interesting.

As I understand WebRequestHandler on .Net desktop developer should set client certificate before request is made. Or we can set it to automatic in that case it would pick it from local certificate store.

But would it allow for client to provide client certificate after handshake was initiated like that in SslStream? It would be nice to have that feature in the platform agnostic version we are developing here in future.

Thanks for clarifying. @davidsh

[davidsh]

For .NET Desktop, the WebRequestHandler allows for both manual (explicit) client SSL certificate to be set, or automatic selection. You should be careful when using automatic. If there are multiple client SSL certificates in the local per-user MY (personal) store, it will pick the first one. A certificate stored in the MY store must have the right characteristics to be classified as a "client" SSL certificate. For example, the private key must be attached to it. And usually the EKU=Client attribute is on the X509 certificate.

In terms of this question:

But would it allow for client to provide client certificate after handshake was initiated like that in SslStream?

It is not really relevant. The Http APIs are CLIENT-side APIs and not SERVER-side. So, you already know the client SSL certificate used since you are providing it to be sent to a SERVER. The SslStream APIs, on the other hand, can operate in both client and server mode and hence it makes sense in that API to expose, on the SERVER side of the API, the client certificate that was sent by the CLIENT.

[justcoding121]

@davidsh I understand. I was using HttpWebRequest to write a light weight HTTPS proxy server, which was working quite well except for the mutual authentication part. Because I am not sure if server would require Mutual Authentication during handshake in first place, and second I have to inform the client to get the client certificate instead of getting it from local store.

As you suggested its not relevant, because I am using the wrong Api to talk to server. Using SslStream directly would be my best bet. I am closing this. Thanks again!