Add support in Kestrel to configure signature algorithms and cipher suites on a per-SNI basis.

[avparuch]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

Kestrel currently allows configuration of a wide variety of TLS settings on a per-SNI basis via SslStream. (such as choosing the server TLS certificate for a given SNI, whether to negotiate a client certificate eagerly or in a delayed manner, the list of distinguished names to send in the TLS handshake, etc)

However, Kestrel does not allow the configuration of signature algorithms on any platform. Also, Kestrel does not allow configuration of cipher suites on Windows. HTTP.sys provides this functionality on Windows and I'm requesting this capability on Kestrel (on both Windows and Linux).

Note: The signature algorithms and cipher suites in Windows are centrally set via Schannel registry keys. Both Kestrel and HTTP.sys delegate to using settings chosen by Schannel. However, HTTP.Sys provides APIs to modify the centrally selected settings on a per-SNI basis - and that capability is what I'm requesting on Kestrel. For a multi-tenant reverse proxy, the ability to choose TLS settings on a per-SNI basis is crucial.

Describe the solution you'd like

I understand that the API shape exposed via ServerOptionsSelectionCallback is not quite the same as HTTP.sys. That is why I'm only describing how HTTP.sys achieves the capability I need. I'm not suggesting a particular API shape for how Kestrel may implement the feature.

The below code uses HTTP.sys APIs to configure signature algorithms and cipher suites on a per SNI basis.
Note: The code below is not meant to be used in production as-is. The intent is to provide a high-level overview of how per-SNI TLS settings are configured on HTTP.sys.

// Let's configure TLS settings for foo.com via HTTP.sys APIs. This is done in 2 steps.

// Step 1: On HTTP.sys, the TLS configuration for any SNI is created by invoking HttpSetServiceConfiguration 
// and passing in a record of type HttpServiceConfigSslSniCertInfo. This incantation creates the "normal" TLS settings on the SNI.

// Step 2: If we need to configure more advanced TLS settings on the SNI, this is done by invoking 
// HttpSetServiceConfiguration and passing in a record of type HttpServiceConfigSslSniCertInfoEx.

// In the below example, let's configure the "normal" TLS settings on foo.com.
// Then, we configure advanced TLS settings such as disabling: 
// 1) the Diffie-Helman KeyExchangeAlgorithm, 2) the RSA_PSS signature algorithm 3) the 3DES cipher suite on the foo.com SNI.

// Step 1: Configure "normal" TLS settings on foo.com.

// The HTTP.sys SNI config. We are going to stuff all the TLS settings into this config.
HTTP_SERVICE_CONFIG_SSL_SNI_SET config = {};

// Let's set Host in the HTTP.sys SNI config.
PCWSTR Host = L"foo.com";
config.KeyDesc.Host = (PWSTR)Host;

SOCKADDR_STORAGE addr = {};
SOCKADDR_IN* inAddr = (SOCKADDR_IN*)&addr;
inAddr->sin_port = htons(443);
inAddr->sin_family = AF_INET;
inAddr->sin_addr.S_un.S_addr = 0; // for HTTP.sys SNI configuration, address must be 0.

// Let's set the IP and port in the HTTP.sys SNI config.
config.KeyDesc.IpPort = addr;

// Let's set TLS flags in the HTTP.sys SNI config.
// There are various TLS settings that can be configured here. Please see lines 2491- 2509 of http.h for a full list of flags in the additional context section of this github issue.
// In this case, we are turning on client certificate negotiation and turning off QUIC.

config.ParamDesc.DefaultFlags = HTTP_SERVICE_CONFIG_SSL_FLAG_NEGOTIATE_CLIENT_CERT | HTTP_SERVICE_CONFIG_SSL_FLAG_DISABLE_QUIC;

// Let's set the thumbprint of foo.com and the certificate store in the HTTP.sys SNI config.
char thumbprint[] = { 0x98, 0x99, ... }; // Let's assume this array is filled out properly and contains a legitimate thumbprint.
config.ParamDesc.pSslHash = thumbprint;
config.ParamDesc.pSslCertStoreName = (PWSTR)L"MY";

// Finally, let's call HTTP.sys and pass in the config for foo.com.  Step 1 is complete!
HttpSetServiceConfiguration(NULL, HttpServiceConfigSslSniCertInfo, &config, sizeof(config), NULL);

// Step 2: Let's configure the advanced (extended) TLS settings on foo.com.

// The HTTP.sys extended SNI config.
HTTP_SERVICE_CONFIG_SSL_SNI_SET_EX configEx = {};

// Set Host and IP, port.
configEx.KeyDesc.Host = (PWSTR)Host;
configEx.KeyDesc.IpPort = addr;

// Create Crypto setting to disable.  
CRYPTO_SETTINGS settings[3] = {};

// Create Diffie-Helman Key Exchange setting.
settings[0].eAlgorithmUsage = TlsParametersCngAlgUsageKeyExchange;
UNICODE_STRING dhString;
RtlInitUnicodeString(&dhString, L"DH");
settings[0].strCngAlgId = dhString;

// Create RSA-PSS signature algorithm setting.
settings[1].eAlgorithmUsage = TlsParametersCngAlgUsageCertSig;
UNICODE_STRING rsapssString;
RtlInitUnicodeString(&rsapssString, L"SCH_RSA_PSS_PAD");
settings[1].strCngAlgId = rsapssString;

// Create 3DES cipher suite setting.
settings[2].eAlgorithmUsage = TlsParametersCngAlgUsageCipher;
UNICODE_STRING cipherString;
RtlInitUnicodeString(&cipherString, L"3DES");
settings[2].strCngAlgId = cipherString;

// Disable the above crypto settings.
TLS_PARAMETERS params[1] = {};
params[0].pDisabledCrypto = settings;
params[0].cDisabledCrypto = 3;

HTTP_TLS_RESTRICTIONS_PARAM restrictions = {};
restrictions.RestrictionCount = 1;
restrictions.TlsRestrictions = params;

configEx.ParamDesc.ParamType = ExParamTypeTlsRestrictions;
configEx.ParamDesc.HttpTlsRestrictionsParam = restrictions;

// Call HTTP.sys again and pass in the extended config for foo.com. Step 2 is complete!
HttpSetServiceConfiguration(NULL, HttpServiceConfigSslSniCertInfoEx, &configEx, sizeof(configEx), NULL);

Additional context

1. Regarding signature algorithms: Kestrel does not support configurability on any platform. Linking useful documentation that make this feature possible:

• Windows: https://learn.microsoft.com/en-us/windows/win32/api/schannel/ns-schannel-crypto_settings (This is what the above HTTP.sys code leverages to configure signature algorithms and cipher suites.)
• Linux: https://docs.openssl.org/3.0/man3/SSL_CTX_set1_sigalgs/. See: SL_CTX_set1_client_sigalgs()

2. Regarding cipher suites: I'm aware that SslServerAuthenticationOptions.CipherSuitesPolicy provides cipher suite configurability for Kestrel on Linux. However, this throws a PlatformNotSupported Exception on Windows.

3. Snippet from http.h for the various flags that can be used while configuring TLS settings on HTTP.sys (I refer to these flags in the code above and I wanted to provide a list of all possible flags):
   

[wfurt]

What is functional impact of this @avparuch? Can you please provide some specific examples? There is no support for this in SslStream so if anything the runtime work would need to come first. cc: @karelz @rzikm

[avparuch]

What is functional impact of this @avparuch? Can you please provide some specific examples? There is no support for this in SslStream so if anything the runtime work would need to come first. cc: @karelz @rzikm

This would be pertinent to reverse proxies that host multiple SNIs on behalf of origin customers. As a reverse proxy service, we expose various TLS 'knobs' to customers, and they configure their SNI as they see fit. For example: some customers want to configure their foo.com SNI with a certain set of cipher suites, a certain set of signature algorithms, certain TLS protocol versions, etc. This is mainly done to achieve combability with the calling clients of that SNI. I can't go into more details on which exact SNIs need which exact settings and why on a public forum - I'm happy to share that offline with you. FWIW, the example I shared in the code snippet is a real configuration of a customer (apart from the foo.com part - which is obviously made up)

[wfurt]

While I do understand the desire I'm wondering what happens if such option is not available. Would the handshake fail or what? And how common is this? Note that most Linux distributions only support modern ciphers and protocol versions e.g. this may not help with any legacy endpoint. Getting some examples of specific functional impact would be useful.

[wfurt]

One more note about the "cipher suites on Windows" - that is runtime platform limitation and AFAIK not fixable at Kestrel level. We would need to convince schannel team to provide suitable API and this is IMHO not right place to ask for it.

[avparuch]

While I do understand the desire I'm wondering what happens if such option is not available. Would the handshake fail or what? And how common is this? Note that most Linux distributions only support modern ciphers and protocol versions e.g. this may not help with any legacy endpoint. Getting some examples of specific functional impact would be useful.

Yes, the TLS handshake fails. I've attached Wireshark traces showcasing two specific examples: one failure case and one success case with the rsa_pss* signature algorithms.

Let me start by describing the failure case. In the attached file titled rsapssfailure.pcapng, navigate to TCP stream 499 to examine the relevant exchange:

In the CertificateRequest message above, the server advertises 12 signature hash algorithms. The client's TLS stack selects a rsa_pss* signature algorithm. At this point, the TLS handshake fails. The reason is: the client's trusted platform module (TPM) tries to use the chosen rsa_pss* algorithm to sign the client certificate and fails to do because the TPM is not compatible with the rsa_pss* signature algorithms.

This is not a legacy use case, the client is using the latest Windows 11 and a fairly modern TPM (that is incapable of using rsa_pss). There are millions of clients out there that falls into this category.

Let me describe the success scenario. The relevant Wireshark file is titled rsapssdisabledsuccess.pcapng—please navigate to TCP stream 17 to review the exchange.

In the above screenshot, the server no longer sends the rsa_pss* signature algorithms in the CertificateRequest Message. This time, the client's TLS stack picks the rsa_pkcs* signature algorithm. The TPM successfully uses this algorithm, allowing the TLS handshake to proceed without any issues. The client is same as the one above (latest Windows 11 with a fairly modern TPM).

[karelz]

Should we move the discussion into runtime repo? I want all requests on SslStream to be there (easier for planning).

[wfurt]

I was planing to open runtime API proposal for the signature algorithm list but there are more questions we need to answer before we can do that. We can have discussion issue + API proposal but perhaps it may be beneficial to chat little bit more here and have only on runtime issue to track (e.g. the API).

The signature list is really combination of signature algorithm (rsa(1), dsa(2), ecdsa(3)) and hash algorithm.
Buth how do you want to configure it @avparuch? Providing the exact combination would perhaps be most flexible. But we will run to same problem as CipheSuites on Windows. The TLS setting allows 16 entires at max and it does not seems like you can specify exact combination. We can also accept that and make it Linux only feature.

Instead, we could also simply specify both lists and .NET can make the mash behind the scenes. But I'm not sure that would be sufficient. Also we just obsoleted HashAlgorithm so we would need to bring it back to live or come up with equivalent.
Any thoughts on this @rzikm?

BTW my current thinking is that we would add to to SslCertificateTrust where we currently configure list for CN to send in certificate request. It may be stretch but it seems like this would be least evil for typical case.

[wfurt]

and could you possibly use the CN list to send the desired cert @avparuch ? It seems like it has distinct issuer - at least in the provided case.

[rzikm]

Providing the exact combination would perhaps be most flexible.

I am not sure about that, from what I see above Schannel has ability to disable specific algorithms on demand, so if user specifies exact combinations he wants to use, it might not be possible to map it to disabling specific algorithms (i.e. there is no way to say that a certain hash algorithm may ONLY be used only in combination with specific signature algorithm).

We should also be thinking about other platforms (Mac, Android), attempts to introduce a new API which we can make work (well) on only a single platform is going to be a lot more difficult.

BTW my current thinking is that we would add to to SslCertificateTrust

This sounds like it might work for client auth (i.e. list sent in server's CertificateRequest), but I am not sure if this is the best place for configuring the algorithms the server is supposed to use (these are not sent, but affect alg selection by the server). Also, the case when we would want to configure signature algorithms and not the trusted root certs becomes a bit weird to construct.

I agree that we need to gather more information about the expected usage (allowlist/denylist, comibations/separately, ...) before we start creating API proposals.

[avparuch]

and could you possibly use the CN list to send the desired cert @avparuch ? It seems like it has distinct issuer - at least in the provided case.

The Distinguished names/issuer hint being distinct is just happenstance in the illustration :) It has no influence on the signature suite that client uses for the client certificates.

[avparuch]

I was planing to open runtime API proposal for the signature algorithm list but there are more questions we need to answer before we can do that. We can have discussion issue + API proposal but perhaps it may be beneficial to chat little bit more here and have only on runtime issue to track (e.g. the API).

The signature list is really combination of signature algorithm (rsa(1), dsa(2), ecdsa(3)) and hash algorithm. Buth how do you want to configure it @avparuch? Providing the exact combination would perhaps be most flexible. But we will run to same problem as CipheSuites on Windows. The TLS setting allows 16 entires at max and it does not seems like you can specify exact combination. We can also accept that and make it Linux only feature.

Instead, we could also simply specify both lists and .NET can make the mash behind the scenes. But I'm not sure that would be sufficient. Also we just obsoleted HashAlgorithm so we would need to bring it back to live or come up with equivalent. Any thoughts on this @rzikm?

BTW my current thinking is that we would add to to SslCertificateTrust where we currently configure list for CN to send in certificate request. It may be stretch but it seems like this would be least evil for typical case.

The ideal case would be having the capability to configure the explicit list of signature algorithms for the SNI . But, I understand the limitations on Windows and the API shape might have to use the 'exclusion semantics' (this is exactly what http.sys provides).

I see 2 options:

1. Since there are no blockers on Linux (SSL_set1_sigalgs, SSL_CTX_set1_sigalgs), we can define the 'ideal/right' API for Linux only and make it throw PNSE on Windows (there is already precedent for this for cipher suites in .NET on Windows).
2. Use 'exclusion semantics' and expose the same API for both platforms.

I lean towards the first option.

[karelz]

@rzikm can you please push on this discussion to get to closure -- I'd like to know in some reasonable timeframe what do we need to build in SslStream to enable @avparuch's scenarios. Thanks!

[rzikm]

@bartonjs do you have an opinion here? Seeing the different semantics on Linux and Windows APIs, I don't think we can support this feature reasonably well on both platforms at the same time.

Given that there already is a precedent in CipherSuitesPolicy on Linux, I also lean towards exposing "allowlist" of signature algorithms on SslStream(Client|Server)AuthenticationOptions, and make the feature throw PNSE on other platforms.

As for specific API shape, I think list of specific combinations seems to be the easiest to use, and we would translate it to list of identifier pairs that would fit to SSL_CTX_set1_sigalgs, unless @bartonjs has better ideas.

[bartonjs]

Of the algorithms listed in https://datatracker.ietf.org/doc/html/rfc8446#section-4.2.3, the filter is always "what certificate(s) have you made available". The only exception I see is the rsaEncryption OID, which is split into rsa_pkcs1_* and rsa_pss_rsaes*. So it feels like you just need two booleans for an rsaEncryption certificate: AllowPkcs1, AllowPss. If either of them is off for the certificate option then you might need to tell the underlying provider something.

Since the industry seems to be saying "making RSA have options was a mistake", I don't anticipate the need on anything else... so just a way to capture those options for however an SNI candidate certificate gets registered/returned.