Equivalent crypto support across platforms

[ehrw1n]

Hi! I've encountered a limitation with Schannel in my .NET Core application. The challenge is that I can't control which TLS versions/ciphers are available on client Windows machines running my SignalR.Client app.

Issue:

• Schannel is Windows-specific and necessarily lags behind browser capabilities
• Can't enforce minimum TLS requirements across all client machines
• Browser connections work fine as they use their own TLS implementation

Proposed Solutions:

• Add OpenSSL builds for .NET SDK/Runtime on Windows/macOS
• Implement runtime crypto provider selection, allowing apps to bundle their preferred TLS library

Related tickets:

• Allow linking to a different openssl library #38015
• investigate TLS13 on MacOS #1979
• Support Windows 10 for System.Net.Quic #101200

Would appreciate support for either bundled OpenSSL builds or the ability to configure alternative crypto providers via .NET Generic Host.

[dotnet-policy-service]

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

[teo-tsirpanis]

Unfortunately neither of the proposed solutions are likely to be accepted by the .NET team.

Judging from the linked azure-signalr issue, the issue that you are facing is likely something different and would not need OpenSSL support on Windows.

[bartonjs]

It's hard to say "never", but it's not likely that either of your proposals would ever happen.

Add OpenSSL builds for .NET SDK/Runtime on Windows/macOS

Our stance is that we use the system cryptography libraries. We used to use OpenSSL on macOS (very early days of .NET Core), but moved off of OpenSSL there when Apple stopped including it in the OS.

I feel I can say "cryptography is the most complicated part of the .NET shared runtime" without too much fear of contradiction. Adding in either two new variants (Windows+OpenSSL, macOS+OpenSSL), or making our Windows and macOS builds support "or" is "unjustified" complexity in an already complex area. (Right now you're the only one who wants this, that means it's a lot of complexity to make one person happy)

bundled OpenSSL builds

If anything is "never", it's this. We absolutely do not bundle/redistribute cryptographic libraries. Since we use Microsoft release channels we only distribute security updates on "Patch Tuesday". OpenSSL doesn't have the same schedule as we do, so an OpenSSL security bug might be known and disclosed for 4-6 weeks before we'd have a chance of getting a new build released.

This is part of why we only use system cryptography libraries, it keeps the hyper-critical component on an update schedule that people already understand.

Even if we did have the ability to use OpenSSL on Windows, it would be up to someone else to bring the library there, and to update it.

configure alternative crypto providers via .NET Generic Host

We don't have one build of .NET that has all possible cryptographic interconnects; we have different builds for Windows, macOS, iOS, Android, and Unix/Other. Each one only knows how to talk to one provider for TLS/SSL and certificates. Making a "we have everything, and you can influence the choice" would be a massive undertaking... and again, there just isn't enough demand to justify it.

[ehrw1n]

Not re-opening, just sharing a concluding comment.

Thank you for the quick and clear answer. The clarity is appreciated and I can follow your reasoning.

I'll explore using a custom .NET Core build to enable the Linux code path on Windows. If that's too challenging or leads to a complex fork, I'll consider migrating the app away from Azure SignalR and C#. I chose C# because our web frontend already uses SignalR, and there weren't suitable SignalR implementations for any of the other AOT-compiled languages we're experienced with.

[ehrw1n]

@teo-tsirpanis if you have an idea what it could be other than Windows 10 Schannel limitations, I would appreciate a comment from you in the other ticket.

[MichalPetryka]

@teo-tsirpanis if you have an idea what it could be other than Windows 10 Schannel limitations, I would appreciate a comment from you in the other ticket.

As far as I understand, @teo-tsirpanis means that you should see an automatic downgrade to 1.2 on Windows 10 and not errors like the Azure issue mentions.

Personally, I find the .NET Crypto stack mostly useless for stuff that isn't basic operations like SHA2 exactly due to the restrictions coming from lack of OS support on platforms like Windows 10. Most of the cases where I needed to do some cryptographic operations ended up with me shipping a native library like OpenSSL and PInvoking into it from my app cause otherwise I wouldn't be able to access the stuff I needed at all.