[release/8.0-staging] Fix calculation of channel bindings hash in managed NTLM implementation

[filipnavara]

Backport of #95898 to release/8.0-staging

Fixes #95725

Customer Impact

Reported by customers in issue #95898 and by eM Client in #95725 (comment) - they cannot connect to Microsoft Exchange and quite a few other host providers on Android client (which uses ManagedNtlm by default).

Authenticating to HTTPS servers using NTLM fails with "Unauthorized" error code when Extended Authentication option is enabled on the server. This is an increasingly common setting on Microsoft Exchange deployments. The bug affects primarily the Android platform where the Managed NTLM implementation is used. We also allow the Managed NTLM as opt-in on macOS and Linux which would be likewise affected if the developer chooses to enable the System.Net.Security.UseManagedNtlm app context switch (which is rare).

Regression

No

Testing

Validated by eM Client on private Exchange instance in Azure VM + against one of the largest host providers in Germany.
The fix has been in .NET 9 since December 2023 and there were no observed issues.

Note: There are no unit tests, the set up is too complicated to test it meaningfully.

Risk

Low; the modified code path is in platform specific code for a single authentication scheme.

[filipnavara]

/cc @rzikm @wfurt

We have another customer of our product affected by this issue. They provided a test account on their server and we verified that the fix resolves the issue.

[rzikm]

LGTM.

Removed Servicing-Consider for now, in case @karelz wants to edit the template first.

[vitek-karas]

/fyi @simonrozsival

[JeroenBer]

Yes we urgently need this for our customers. Not only for Android but also iOS and macOS since the unmanaged implementations cause crashes and are not usable (#97966)

[dotnet-policy-service]

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

[JeroenBer]

@rzikm , not sure how this works but I see the PR is missing the "Servicing-approved" label before it can be merged. Who can do this ?

[rzikm]

@JeroenBer I am keeping eye on this issue. The earliest this fix can get released is in July servicing release, and deadline for that release is mid June, we are still on track for that release.

[JeroenBer]

@rzikm Thanks for keeping an eye on this. A lot of our customers are waiting for this. July is still a long time but please let's make that. If there's anything we can do to speed this up, like creating a service case at Microsoft, then please let me know.

[rzikm]

Creating a service case is unlikely to speed things up.

.NET has monthly cadence of servicing releases (with release dates coinciding with patch Tuesdays). Around the time one release is released, next one is branched off and starts to be prepared.

Restarting the process mid-way to include additional fixes would be costly (I don't know the figures, it's just my assumption based on my observations).

At any rate, there is potentially a way to unblock you and your customers earlier by using a private build of System.Net.Security.dll containing the fix. We use the process for validating that the fix is working. For desktop platforms the steps are simple (self-contained publish of the app+ overwriting the changed dll), I can provide you with the right dll for macOS if this option is available for you.

Unfortunately, I don't know if a similar process is possible for mobile platforms. Maybe @simonrozsival knows.

[simonrozsival]

Unfortunately, I don't know if a similar process is possible for mobile platforms.

It is possible to use custom runtime build in a mobile app, but I wouldn't recommend it. An example how to use custom dll on Android (or other mobile platforms) is shown here in the "Known workarounds" section: #95295

[JeroenBer]

Well in that case please try to get this fix in the July servicing release.

[rzikm]

Approved via email on 6/3 and on 6/6 (with corrected customer info).

[JeroenBer]

@rzikm this is merged into dotnet:release/8.0-staging I think, does this mean it will come into the next servicing release in July ?

For Android / iOS / macOS does this come available with a workload update for android / ios / macos or does this come available with a SDK update ?
I mean Android / iOS / macOS have their own runtimes or is this something that is shared between all runtimes ? Or is this not in the runtime ?

[wfurt]

The libraries are shared across all runtimes. For Android, the managed implementation is the only one option because there is no GSSAPI. For iOS & macOS you need to subscribe to it.

[JeroenBer]

Thanks for the info, so just updating the SDK and rebuilding would be enough then ? No need to update workloads for android etc. For iOS / macOS we opted in for managed NTLM.

[wfurt]

Thanks for the info, so just updating the SDK and rebuilding would be enough then ? No need to update workloads for android etc. For iOS / macOS we opted in for managed NTLM.

yes. cc @filipnavara just in case I missed something.

[filipnavara]

It’s correct. SDK update is all that’s needed.