SChannel 中的密码套件选择

Question

我已经实现（Windows 10.0.17763.0/VS2017/C++）一个客户端/服务器应用程序，它使用 schannel 进行安全通信。现在的要求是仅使用一组密码套件来进行某些客户端和服务器之间的通信。

使用 BCryptAddContextFunction/BCryptRemoveContextFunction API，我可以更改 SChannel 中支持的密码，但这是一个系统范围的设置，不仅适用于我的应用程序。 为了以编程方式控制它，我尝试在 AcquireCredentialsHandle 中使用 ALG_ID。 以下是我的应用应该支持的唯一密码套件。

• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

所以我构造了如下所示的 ALG_ID。

std::vector<ALG_ID> algos       = { CALG_AES_256 , CALG_AES_128 , CALG_SHA_384 , CALG_SHA_256,CALG_ECDH_EPHEM,CALG_DH_EPHEM };
schannelCred.cSupportedAlgs     = static_cast<DWORD>(algos.size());
schannelCred.palgSupportedAlgs  = &algos[0];

使用 wireshark，我发现下面是我的应用程序使用上述 ALG_ID 在客户端 hello 中提出的密码套件，

• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

问题是，

1. 我如何只允许 AES_GCM 批量加密？当我将 CALG_AES 添加到列表中时，AES_GCM 和 AES_CBC 都被允许。
2. 如何控制签名？添加 CALG_ECDH_EPHEM 启用了 TLS_ECDHE_ECDSA 和 TLS_ECDHE_RSA，我只需要 TLS_ECDHE_RSA。 将 CALG_RSA_SIGN 添加到 ALG_ID 删除了 TLS_ECDHE_ECDSA，但它开始允许 TLS_RSA_* 密码套件。

Answer 1

在调用 AcquireCredentialsHandle 函数时，您可以使用 SCH_CREDENTIALS 结构而不是 SCHANNEL_CRED。

您使用一组 CRYPTO_SETTINGS 结构创建 TLS_PARAMETERS。每个 CRYPTO_SETTINGS 结构都定义了密钥交换、签名、摘要和批量密码算法的限制。然后，您可以选择满足您的应用要求的组合。此结构 (SCH_CREDENTIALS) 与 SCHANNEL_USE_BLACKLIST 标志 /approach 一起使用，禁用指定 TLS 会话不需要的内容。通过 CRYPTO_SETTINGS 结构的 eAlgorithmUsage 和 strCngAlgId 成员的正确组合，我认为您可以实现 TLS 会话的所需行为。

请参阅 https://docs.microsoft.com/en-us/windows/win32/api/schannel/ns-schannel-sch_credentials

https://docs.microsoft.com/en-us/windows/win32/api/schannel/ns-schannel-tls_parameters

例如，如果您在具有适当 eAlgorithmUsage 成员值的限制之一中包含 AES_CBC，在本例中为 TlsParametersCngAlgUsageCipher，则应将其作为批量加​​密算法从会话中排除。确保从该 eAlgorithmUsage 的限制中排除 AES_GCM。

关于控制签名算法，具有 TlsParametersCngAlgUsageSignature 值的 CRYPTO_SETTINGS 结构 eAlgorithmUsage 成员限制使用分配给 strCngAlgId 成员的算法作为该会话的签名算法。您还可以确定要限制的最小和最大长度。

最后，

“Protocols 项下注册表项中的 DisabledByDefault 值不优先于包含 Schannel 凭据数据的 SCHANNEL_CRED 结构中定义的 grbitEnabledProtocols 值。” (https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/restrict-cryptographic-algorithms-protocols-schannel)。

该 TLS 会话的 TLS_PARAMETER 结构的 grbitDisabledProtocols 成员也是如此。

如果您详细说明了签名算法、密钥交换、批量加密和摘要的正确组合限制，您可以将不需要的算法从密码套件中的特定位置过滤掉。

Answer 2

使用 CNG 函数：此处的示例 https://github.com/MicrosoftDocs/win32/blob/docs/desktop-src/SecAuthN/prioritizing-schannel-cipher-suites.md

此外，“在协商密码套件时，客户端会发送带有密码套件列表的握手消息 它会接受。服务器从列表中选择并发送回握手消息，指示它将接受哪个密码套件。尽管客户端可能会使用它认为最强大的密码套件对列表进行排序，但服务器可能会忽略偏好顺序并选择 客户提出的任何密码套件。服务器可能有自己的密码套件偏好顺序，它可能与客户端的不同。因此，不能保证谈判会以最强的通用套件达成。如果没有通用的密码套件 客户端和服务器，连接被中止。” -

NIST 特别出版物 800-52 修订版 2 传输选择、配置和使用指南 层安全 (TLS) 实现，第 3.3.1 节密码套件。 克里·A·麦凯 大卫·A·库珀 计算机安全部 信息技术实验室 本出版物可从以下网站免费获取： https://doi.org/10.6028/NIST.SP.800-52r2