Repository navigation
Ship Openssl MsQuic dll and utilize it in environments where schannel doesn't support tls1.3 #113244
Description
Description
Windows 10 lacks the schannel apis for tls1.3, this prevents httpclient from easily utilizing http3 on windows 10. MsQuic provides dlls compiled for windows that utilize openssl and allows http3 to work on windows 10.
Reproduction Steps
Setup a windows 10 environment
var Client = new HttpClient()
{
DefaultRequestVersion = HttpVersion.Version30,
DefaultVersionPolicy = HttpVersionPolicy.RequestVersionExact
};
Attempt to make a connection
Expected behavior
Connection attempts to be established
Actual behavior
Throws an exception
Regression?
No response
Known Workarounds
I'm currently using the harmony library to patch a function to intercept the unmanaged dll request and instead redirect it to the local application directory
internal static class HarmonyHelper
{
static Harmony harmony;
public static void Apply()
{
if (Environment.OSVersion.Version.Build < 22000)
{
harmony = new Harmony("com.dot.net.really");
var original = typeof(NativeLibrary).GetMethods().FirstOrDefault(r => r.Name == "TryLoad" && r.GetParameters().Length > 2);
harmony.Patch(original, prefix: new HarmonyMethod(Prefix));
}
}
static bool Prefix(ref string libraryName, System.Reflection.Assembly assembly, System.Runtime.InteropServices.DllImportSearchPath? searchPath, out IntPtr handle)
{
handle = IntPtr.Zero;
if (libraryName.EndsWith("\\msquic.dll"))
{
var target = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "msquic.dll");
if (File.Exists(target))
libraryName = target;
harmony.UnpatchAll("com.dot.net.really");
}
return true;
}
}
This is silly.
Another workaround is publishing as self-contained and manually replacing the msquic.dll
Configuration
No response
Other information
There is a pr that was closed ( #103351 ) that attempted to create a workaround for this, by allowing developers to indicate they want to load msquic.dll from the local directory.
I think that is a poor solution, it leaves shipping updated dlls up to the application developer where developers who target only windows11 can rely on the dotnet runtime.
I would suggest either
1)Ship the openssl version by default instead of the schannel version - this allows all the supported versions of windows to utilize quic/http3
2)Ship both the schannel and openssl dll and load based on the presence of the tls1.3 api
Activity
dotnet-policy-service commentedon Mar 7, 2025
Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.
ManickaP commentedon Mar 7, 2025
We cannot ship OpenSSL MsQuic as part of .NET runtime as it statically links parts of OpenSSL, which means that .NET would be responsible for security patches within OpenSSL and we don't have a way to do that.
That PR you linked is the only viable solution we could support Windows 10. You can +1 / comment on #101200 to let us know that there's an interest.
@rzikm maybe you could resurrect that PR when you have time?
I'll close this as won't fix due to security reasons.
rzikm commentedon Mar 10, 2025
@mastahg for what it's worth, you can already use the code in the PR description (without the appctx switch, as that one does not exist in main) and have the openssl msquic.dll automatically overwrite the one in the self-contained publish output. The only thing that the mentioned PR fixes is the opt-in for the ability to load msquic.dll from application directory, which would fix development loop (dotnet run) and framework-dependent (i.e. standard) publish on Windows 10.
As ManickaP said, we will never ship OpenSSL msquic.dll ourselves, so even if we resurrect the PR, there will still be manual action necessary on the app developers part.