macOS: Can HttpClient do custom cert handling with libcurl+openssl10?

[bartonjs]

Gedankenexperiment:

• If OpenSSL/1.0 is the reported backend, run the OpenSSL initializer.
• Still fail client auth certificates (non-exportable private keys can't marshal into OpenSSL, and other problems could exist, so just block it)
• If OpenSSL/1.0 is the reported backend, register the callbacks/etc as normal.
• For the EE (server identity) cert and any presented intermediates, extract the certificate bytes to pass to new X509Certificate2(byte[]).
• Build the X509Chain
• Apply chain and hostname checks
• Call the callback.

[bartonjs]

cc @stephentoub

[karelz]

@bartonjs can you please set milestone? Or does it need discussion first?

[bartonjs]

Since this will enable a workaround on macOS where none currently exists, this seems pretty worthwhile for 2.0. Of course, it's entirely experimental, so it's possible that it can't be done at a shipping quality in the time remaining.

[joeyaiello]

Just wanted to 👍 this with the context that it would unblock PowerShell/PowerShell#3648 which would help a non-trivial amount of our customers and partners use PowerShell Core 6.0 on macOS. Feel free to ping me offline if you need more formal justification.

[stephentoub]

@joeyaiello, just to be sure, https://github.com/dotnet/corefx/issues/19709 would also unblock PowerShell, right? It looks like SkipCertificateCheck just uses delegate { return true; }, so once #21672 is implemented, PowerShell could just assign this delegate instead of that one, and it wouldn't require the end user to work around it by changing out the libcurl being used. (To be clear, I would still like to see this issue implemented, as it addresses a larger set of problems albeit with a more complicated workaround on the user's part.)

[joeyaiello]

@stephentoub that sounds right to me, but I would need @daxian-dbw to confirm. Going to linkback to #21672 in that issue as well.

Thanks!

[karelz]

@bartonjs is the one you created workaround for? If not what else is left? Do you plan to finish it before vacation or should we give it to someone else?

[bartonjs]

@karelz I haven't had a chance to start yet, honestly. If new problems would stop being discovered and distracting me, I'd probably be able to finish it. But it's looking iffy.

[leecow]

Discussed in shiproom based on input from @stephentoub. Plan to work on for 2.1 and backport if it does turn out to be blocking.

[karelz]

@stephentoub did you mean to close it? Or leave it open for 2.1?

[karelz]

I think this was meant to track the 2.1 work ... reopening. @stephentoub please let me know if I misunderstood.

[tritao]

Any news when we can expect a fix for this one?

We're hitting this in really basic HTTP client code.

[karelz]

@bartonjs do you plan to work on it for 2.1?
cc @Priya91

[bartonjs]

I was given to understand that this would be rendered moot by the managed HTTP handler. So I guess I thought this issue was closed. Though apparently it's assigned to me, and open 😄.

[karelz]

ManagedHandler will be just opt-in in 2.1. One day, it will be default.

Given the number of upvotes (22), I wonder if there is something targeted we could/should do for 2.1 -- given that we were even considering backporting it into servicing of 2.0 (https://github.com/dotnet/corefx/issues/19718#issuecomment-303532816).

[karelz]

We discussed it with @bartonjs couple of weeks ago.
We came to conclusion there is nothing reasonable we can do here, except to wait for SocketsHttpHandler, which is coming in 2.1 (maybe even as default).

Anyone can give it a try with SocketsHttpHandler in 2.1 Preview1 - see blog post with details how to turn it on (heads up: the way how to turn it on will change in Preview2).