search

dotnet / runtime

.NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.
https://docs.microsoft.com/dotnet/core/
MIT License
14.57k stars 4.55k forks source link

investigate TLS13 on MacOS #1979

Open wfurt opened 4 years ago

wfurt commented 4 years ago

It seems like on Catalina TLS1.3 works out of the box - at least with Safari. However, when I try to use in .NET I get the following error:

System.Net.Http.HttpRequestException: The SSL connection could not be established, see inner exception.
 ---> System.Security.Authentication.AuthenticationException: Authentication failed, see inner exception.
 ---> Interop+AppleCrypto+SslException: bad protocol version
   --- End of inner exception stack trace ---

This may be because API we currently use is marked as obsolete or there may be something missing since TLS1.3 support got out before Catalina. And all TLS1.3 tests are disabled on all versions of MacOS.

related to https://github.com/dotnet/runtime/issues/1720

wfurt commented 4 years ago

It seems like we will need to rewrite PAL to use new Network framework API. That should fix iOS as well.

https://mailarchive.ietf.org/arch/msg/tls/5QjzTilqjomSyzENtgfaAqQOhbA/

karelz commented 4 years ago

Triage: Will require PAL rewrite on Mac -- out of scope of 5.0. The new Catalina API will help also iOS and light up TLS 1.3 there.

chucker commented 2 years ago

Is this still current? In a .NET 6 console app with macOS 12.3 against a host that only seems to support TLS 1.3, I still get the same stacktrace as above. .NET info:

.NET SDK (reflecting any global.json): Version: 6.0.201 Commit: ef40e6aa06 Runtime Environment: OS Name: Mac OS X OS Version: 12.3 OS Platform: Darwin RID: osx.12-x64 Base Path: /usr/local/share/dotnet/sdk/6.0.201/ Host (useful for support): Version: 6.0.3 Commit: c24d9a9c91 .NET SDKs installed: 6.0.201 [/usr/local/share/dotnet/sdk] .NET runtimes installed: Microsoft.AspNetCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.3 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
wfurt commented 2 years ago

yes, it is @chucker. #27727 has more detail but it is essentially same work. It is not clear at this moment if it is even feasible.

bhoffman-splunk commented 2 years ago

Not to add pressure, but I am more and more encountering TLS 1.3-only systems. This is especially true for internal, greenfield APIs that companies build, since they can "start secure" from the beginning. Any work around (such leveraging OpenSSL as is done in Linux) would be tremendously helpful.

wfurt commented 2 years ago

Is there need for client, server or both? I was thinking about some fallback because to allow HTTP2 for macOS developers (https://github.com/dotnet/runtime/issues/27727) We generally do that for HTTP3/Quic (preview in 6.0) so we have some parts already in a place. if we go down this path, it would probably be opt-in feature with dependency on OpenSSL from Brew/MacPorts. Would that be acceptable?

chucker commented 2 years ago

@wfurt client in my case. macOS as a server is uncommon. But server might still be useful (if less important) for developers who run Kestrel on a Mac?

wfurt commented 2 years ago

And yes, the server part would be for Mac developers (like me). Production deployment of Kestrel on macOS is unlikely IMHO.

Just to elaborate more since the use case here is different from https://github.com/dotnet/runtime/issues/27727.

Aside testing and support, the biggest challenge with using OpenSSL on macOS is integration with keychain and certificate management. Using Apple's AP allows to use private keys that are non-exportable and private keys are not in core dumps. And Apple packages LibreSSL instead of OpenSSL and that is not binary compatible. So dependency management is going to be hard.

The new Apple's api makes it very difficult (and maybe impossible) for SslStream to consume. Based on testing @filipnavara did, client may be easier and there may some possibilities. The challenge would be moving forward with client if there is not solution for the server. That would effectively mean we would need to maintain both PAL layers.

bhoffman-splunk commented 2 years ago

@wfurt sorry for not being more clear. This is for clients.

As a client, not being able to make encrypted connections to TLS 1.3-only services/servers is by far the bigger issue. I'm finding companies start a new green-field API or service, and configure it to only use TLS 1.3. Writing .NET code that can talk to services configured like this will only grow with time.

At this point I'm literally shelling out from .NET to run "ncat + openssl" via the Process class to make requests for me and get the response, which is super clumsy and slow.

wfurt commented 2 years ago

ok. thanks for the feedback @bhoffman-splunk and @chucker. I'm not sure if this fits to 7.0 but I'll try to take another look and I'll sync up with with @filipnavara.

filipnavara commented 2 years ago

I am gonna be away for the next week but happy to discuss it when I get back.

davidkaya commented 1 year ago

Hi, are there any plans on supporting TLS 1.3 on macOS in future .NET releases?

Our usecase is that we have customers with 10s of thousands of users using our software (.NET 6) on their macOS. The server side is deployed on a Windows Server which has only TLS 1.3 enabled. The software deployed on workstations currently cannot communicate with the server side due to the TLS 1.3 requirement.

wfurt commented 1 year ago

triage: we should investigate for 8.0

filipnavara commented 1 year ago

Here's a link to the example on how to "misuse" the framer API in Network.framework to perform client-side TLS: https://gist.github.com/filipnavara/d5fb55bdb5edcceb1981f73078b855c4

(I'll be happy to answer any questions about it once I get back from holiday at the beginning of December.)

lini commented 10 months ago

Hi there, It seems that TLS1.3 support for macOS clients is not coming in the .NET 8.0 release this year. Currently we have to use a third party library (Bouncy Castle) to workaround this on our mac clients, but it is not a perfect solution - e.g. the performance penalty for high network throughput threads is high. What is the current status of this feature - is the implementation possible at all using the Apple native APIs?

wfurt commented 10 months ago

It is on 9.0 wish list for me. We simply run out of time in 8.0 and it is not trivial effort. Based on prototypes from @filipnavara it should be doable at least for the client side. While not ideal I would be OK for me doing only half for now - just to make some progress. ALPN was like that for a while until https://github.com/dotnet/runtime/issues/27727 plugged server side in 8.0. But in the mean time HttpClient (and others) could connect to HTTP/2 servers.

lewing commented 8 months ago

@wfurt see https://github.com/dotnet/installer/issues/17588

rzikm commented 8 months ago

Triage: big effort, unclear implementation direction (the new API does not make it easy to get TLS messages in a buffer so that we can push them to the provided inner stream ourselves). But would be great for platform compatibility.

elias-ik commented 4 months ago

Its 2024, and we still can't call TSL1.3 APIs? Any plans?

jozefizso commented 4 months ago

We are writing troubleshooting utility in .NET to verify our app can correctly connected using IPv4 and IPv6 and using different TLS protocols.

On macOS the app reports only TLS v1.2 connection.

Will TLS 1.3 really be ready in .NET 9?

wfurt commented 4 months ago

It is still high on the priority list. However, it is not clear if it is even doable because of Apple's new AI shape.

pmauchle commented 3 weeks ago

Does anybody have a workaround for this problem that works in combination with HttpClient and consumes TLS 1.3 APIs?

wfurt commented 3 weeks ago

you would need TLS terminating proxy @pmauchle. It is probably doable but tricky. I really wish we can make progress but realistically we don't have resources to get it done in 9.