-
Notifications
You must be signed in to change notification settings - Fork 4.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Equivalent crypto support across platforms #110220
Comments
Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones |
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. |
It's hard to say "never", but it's not likely that either of your proposals would ever happen.
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)
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.
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. |
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. |
@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. |
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:
Proposed Solutions:
Related tickets:
Would appreciate support for either bundled OpenSSL builds or the ability to configure alternative crypto providers via .NET Generic Host.
The text was updated successfully, but these errors were encountered: