Skip to content
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

Closed
ehrw1n opened this issue Nov 27, 2024 · 6 comments
Closed

Equivalent crypto support across platforms #110220

ehrw1n opened this issue Nov 27, 2024 · 6 comments

Comments

@ehrw1n
Copy link

ehrw1n commented Nov 27, 2024

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:

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

@dotnet-policy-service dotnet-policy-service bot added the untriaged New issue has not been triaged by the area owner label Nov 27, 2024
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member

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.

@bartonjs bartonjs closed this as not planned Won't fix, can't repro, duplicate, stale Nov 27, 2024
@dotnet-policy-service dotnet-policy-service bot removed the untriaged New issue has not been triaged by the area owner label Nov 27, 2024
@ehrw1n
Copy link
Author

ehrw1n commented Nov 27, 2024

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
Copy link
Author

ehrw1n commented Nov 27, 2024

@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
Copy link
Contributor

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants