[QUIC] Certificate Validation with OpenSSL on Windows

[wegylexy]

Description

To support QUIC on older versions of Windows, the OpenSSL build of msquic may substitute. However, the raw certificate needs to be converted to PCERT_CONTEXT before loading into X509Certificate2. #51015 breaks this scenario due to loading the certificate in the wrong format.

Moreover, there should be better a way to disable certificate validation altogether and not attempt to load the certificate, than using a lambda that always returns true.

Configuration

Windows with OpenSSL build of msquic.dll, self-signed cert without chain.

Regression?

Skip this line https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicConnection.cs#L368 and return success.

Other information

SChannel on Windows 11 works, OpenSSL on Linux works. QUIC could otherwise be supported on older versions of Windows too.

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

#51015 breaks the OpenSSL alternative of msquic.dll on Windows where the newer SChannel is unavailable. When the cert validation callback always returns true (intended to bypass validation), .NET still tries to load the cert anyway, but assuming SChannel causes a crash. Skipping the Windows conditional branch results in a TLS alert of bad cert too.

Configuration

Windows with OpenSSL build of msquic.dll, self-signed cert without chain.

Regression?

Bypass certificate loading in HandleEventPeerCertificateReceived() in https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicConnection.cs#L368 and return success.

Other information

SChannel on Windows 11 works, OpenSSL on Linux works. QUIC could otherwise be supported on older versions of Windows too.

Author:	wegylexy
Assignees:	-
Labels:	area-System.Security, untriaged
Milestone:	-

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

#51015 breaks the OpenSSL alternative of msquic.dll on Windows where the newer SChannel is unavailable. When the cert validation callback always returns true (intended to bypass validation), .NET still tries to load the cert anyway, but assuming SChannel causes a crash. Skipping the Windows conditional branch results in a TLS alert of bad cert too.

Configuration

Windows with OpenSSL build of msquic.dll, self-signed cert without chain.

Regression?

Bypass certificate loading in HandleEventPeerCertificateReceived() in https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/MsQuicConnection.cs#L368 and return success.

Other information

SChannel on Windows 11 works, OpenSSL on Linux works. QUIC could otherwise be supported on older versions of Windows too.

Author:	wegylexy
Assignees:	-
Labels:	area-System.Net.Quic, untriaged
Milestone:	-

[wegylexy]

@bartonjs Could be security-related too as the exception is thrown from X509Certificate2Collection and X509Certificate2, given a raw cert from the OpenSSL build of msquic. Do they only work with SChannel on Windows?

[wfurt]

I'm not sure I understand the comment @wegylexy. On Windows with channel the Handle is basically raw pointer to memory. When this is called with openssl backend you basically give it pointer to random memory. It is not surprising that it would crash. If you build MsQuic yourself you could fix up the crypto to cover to PCERT_CONTEXT or set it to null.

[wegylexy]

@wfurt I see. So either msquic or .NET needs to convert the raw cert to PCERT_CONTEXT on Windows, and .NET QUIC should support OpenSSL build of msquic on older versions of Windows, because at least Windows 8.1 and some LTS servers have no ways to enable TLS 1.3 in SChannel. It's also risky to ask Windows 10 users to change the registry to just to enable QUIC for our .NET 6 apps.

[wfurt]

avoiding crash is easy. The real question is how you are going to do real validation and certificate management.
I added flag to MsQuic to specific if the certificates are expected in "portable" e.g. PKCS format or as a native platform pointer. microsoft/msquic#1453 tracks deferred work to support "portable" option on Windows/Schannel. When I look at it back then, Windows has all the needed functions to deal with the formats so can could also submit fix to upstream msquic to convert OpenSSL structures to native PCERT_CONTEXT.
Furher more, microsoft/msquic#1258 added option to do OpenSSL validation with Windows store. That should get you really close.

cc: @nibanks @ThadHouse

[wegylexy]

Finally found it!

runtime/src/libraries/System.Net.Quic/src/System/Net/Quic/Implementations/MsQuic/Interop/SafeMsQuicConfigurationHandle.cs

Lines 122 to 126 in 6ebdf24

	if (!OperatingSystem.IsWindows())
	{
	// Use certificate handles on Windows, fall-back to ASN1 otherwise.
	flags |= QUIC_CREDENTIAL_FLAGS.USE_PORTABLE_CERTIFICATES;
	}