问题标签 [schannel]

据说要关闭一个schannel连接需要遵循以下步骤： 1）调用ApplyControlToken函数，指定SCHANNEL_SHUTDOWN控制令牌。

2）从ApplyControlToken收到SEC_E_OK返回值后，调用InitializeSecurityContext（Schannel）（客户端）或AcceptSecurityContext（Schannel）（服务器）函数，传入空缓冲区。

3) 就好像您的应用程序正在创建一个新连接一样继续进行，直到函数返回 SEC_I_CONTEXT_EXPIRED 或 SEC_E_OK 以指示连接已关闭。将最终输出信息（如果有）发送给远程方。

从链接Shutting Down an Schannel Connection 但是，我们是否需要从客户端和服务器传递信息。传递信息后，我们需要在远程端如何处理该信息。

在 Windows 10 中使用 SChannel SSPI 执行 DTLS 握手时 - 没有文档 - 应用程序应如何处理来自 AcceptSecurityContext (ASC) 或 InitializeSecurityContext (ISC) 的 SEC_I_MESSAGE_FRAGMENT 结果？

我知道我打算将收到的片段发送给对方并再次调用 ASC/ISC 以获取下一个片段，但是当我再次调用 ASC 时，这次输入为空的 SECBUFFER_TOKEN，我在输出令牌缓冲区中什么也没有收到，并且它返回 SEC_I_MESSAGE_FRAGMENT - 表明它正在等待输入数据。

大概我没有成功地向 ASC 表明我希望它给我下一个片段，那么我该怎么做呢？

我创建了一个独立示例，在此 GitHub 要点中重现了我的问题： https ://gist.github.com/haddoncd/381c5e9542e977ca238ff16229bd9a0e/c881132ced94995402b617f38a5c8b6f8669b637

我还在程序的 gist 示例输出中包含了详细显示导致问题的输入： https ://gist.github.com/haddoncd/381c5e9542e977ca238ff16229bd9a0e/c881132ced94995402b617f38a5c8b6f8669b637#file-example_output-txt

我正在尝试从 Windows 浏览器访问 SSL URL 到另一台运行 Tomcat 的机器，我在 Windows 机器上的系统事件日志中看到来自 Schannel 的错误 36887，并带有以下描述：

TLS 协议定义的致命警报代码为 70

根据 MS 文档：

我在 Windows 机器上打开了 Schannel 日志记录（最大 = 7），我可以看到 SSL 握手已正确协商，这来自事件日志：

这似乎与代码 70 错误相矛盾。

密码套件 0xC028 是 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384。我在 Tomcat 机器上进行了检查，可以看到这是可用的，并且两台机器上也都启用了 TLS1.2，因此成功的握手是有意义的。

与代码 70 错误关联的进程 ID 属于 lsass.exe - 我的 Windows 知识非常有限，所以我不知道它是做什么的。

我在 Tomcat 机器上的 catalina.out 日志中找不到任何东西，代码 70 似乎是在实际发送请求之前发生的。我确信证书都配置正确，因为我可以从其他机器成功访问 URL。

我该如何从这里进步？

我正在尝试使用 .Net SSLstream 在 Windows 上设置带有 PEM 证书密钥对的 2-Way SSL。但是，我不断收到以下 SChannel 错误：“创建 TLS 客户端凭据时发生致命错误。内部错误状态为 10013。”。SSL 握手总是失败。但是，当我使用具有相同证书和密钥的邮递员时，它可以正常工作。有谁知道邮递员在内部使用什么？OpenSSL，无聊的SSL等？我可以在 .Net 中使用任何替代 TLS 实现吗？

请参阅这篇文章以了解我尝试过的内容：SSL Handshake 在 C# 中失败，但在邮递员中有效

所以我正在编写一个 Schannel 服务器到 IOS Gmail 客户端应用程序 - IMAP 服务器。

我正在强制使用 TLS1.0（尝试使用 TLS1.0to1.3 - 1.3 似乎可以使用 algo_mismatch 但其他的也一样，我也尝试使用 SSL3.0，但阅读 gmail 不支持。

目前我无法克服似乎挂在recv. 我不知道我做错了什么 - 我还在我的（客户端设备 - IOS）上安装了证书。

我需要澄清 - 它第一次进入循环，成功结束（AcceptSecurityContextwith SEC_I_CONTINUE_NEEDED），但在send（我还检查了它的结果与cbBuffer大小匹配，所以它必须没问题）之后它会挂起recv。

这是握手部分：

这是我的主要功能：

这是整个片段供参考：

<local-ip>并<cert-name>隐藏我的真实本地 IP 和服务器/证书名称。

我有使用 CNG 密钥和提供者“Microsoft 平台密钥提供者”创建的客户端证书。CNG 密钥具有使用 CNG 参数 NCRYPT_UI_FORCE_HIGH_PROTECTION_FLAG 进行强密钥验证的密码。

我正在尝试将证书用于 TLS 连接，并且在我的 SChannel 客户端实现中，我在握手期间收到 PIN 提示，这是正常的。

为了避免 PIN 提示，我尝试使用以下代码模板将 PIN 设置为证书上下文，如此链接 Windows C++ 加密 API：如何禁用智能卡的 pin 代码 UI 中 所述。我确保使用 CRYPT_ACQUIRE_CACHE_FLAG | CRYPT_ACQUIRE_PREFER_NCRYPT_KEY_FLAG 在检索 HCRYPTPROV_OR_NCRYPT_KEY_HANDLE 并通过设置属性 NCRYPT_PIN_PROPERTY 设置 PIN 的方法中。因此，将来将为设置 PIN 的相同证书上下文打开相同的 Ncrypt 密钥。

将证书上下文提供给 SCHANNEL_CRED，并传递给 AcquireCredentialsHandle()。但我看到 AcquireCredentialsHandle() 正在从证书上下文中打开 NCrypt 密钥的新对象，最后在握手过程中再次询问 PIN。

我的目标是避免在握手期间出现此 PIN 提示，因为我会以编程方式提供它。如果有人可以帮助我，我将非常感激。

我正在开发一个需要升级才能在 Windows 上使用 TLS 1.3 的 TLS 客户端。有没有人使用 SChannel API 成功实现了 TLS 1.3？

我需要了解如何处理新结构 SCH_CREDENTIALS 以及从服务器处理 SEC_I_RENEGOTIATE 的正确方法。任何拥有显示 TLS 1.3 与 SChannel 握手的示例客户端/服务器代码的人都会非常有帮助。

Windows 2022 和 TLS 1.3 的插件问题很少：

1. 当 EncryptMessage() 和 send() API 与 TLS 1.3 一起使用时；send() 以多个块发送数据，但有效负载很小。示例：一个 30 字节的缓冲区在第一轮发送 3 个字节，在第二轮迭代中发送 27 个字节。QueryContextAttributes() 返回最大大小，例如 16384。因此，期望几百字节的任何数据都应该一次性发送。

直到 TLS 1.2；SChannel 一次性发送所有此类数据，例如 30 个字节等。这是 TLS 1.3 预期的吗？或者这是我们处理 Encrypt() + send() 的方式中的错误

2. 我从注册表启用了 SChannel 日志。使用 TLS 1.3 握手；事件查看器将几个参数指示为 0。下面显示了 TLS 1.2 和 TLS 1.3 的示例。这是预期的吗？

对于 TLS 1.3 握手：

TLS 客户端握手成功完成。协商的密码参数如下。

协议版本：未知密码套件：0x1302 交换强度：0 位上下文句柄：0x1a1ccf646f0 目标名称：localhost

对于 TLS 1.2 握手：

TLS 客户端握手成功完成。协商的密码参数如下。

协议版本：TLS 1.2 CipherSuite：0xC030 交换强度：384 位上下文句柄：0x1a1ccf201f0 目标名称：checkappexec.microsoft.com 本地证书主体名称：

协议版本在 TLS 1.3 日志中显示为“未知”。交换强度在 TLS 1.3 握手日志中显示为 0。

使用 TLS 1.2，我们可以看到有效值 (384) 和协议版本。

目前，我们在 Linux 机器上使用 rsyslog 使用 TLS 1.2 发送消息，内部使用 GnuTLS 库将 syslog 消息发送到我们的托管服务器之一，该服务器使用 windows SCHANNEL 方法接受 TLS 数据。当客户端向服务器发送超过 16K 的数据时，我们会收到“无法解密，错误代码：80090308”。在将数据保存在扩展缓冲区上时，在下一个周期数据解密期间也注意到了同样的问题。

我正在尝试找出用于 Web 服务器上 TLS 握手的密码套件版本。

1. 在Windows 和 Windows Server 中启用 Schannel 事件日志记录之后，我将注册表设置为 0x05（信息、成功和错误），并且可以在事件查看器中查看日志。
2. 我还可以找到Event ID 36880: An SSL (client or server) Handshake Completed Successfully事件，其中我可以看到如下内容：

CipherSuite版本（在本例中为 0xC030）是我感兴趣的。

为了进一步测试这是否正常工作，我使用 OpenSSL 使用特定密码套件执行 TLS 握手。

我可以看到握手确实成功了。但是，在检查 EventViewer 时，我仍然看到 CipherSuite 版本为 0xC030而不是预期的 0x009C 的SCHANNEL 事件（使用支持的密码套件来识别密码套件的十六进制值）。

尽管与特定密码套件进行了握手，但为什么我在 EventViewer 中看不到正确的密码套件版本的任何指示？

感谢您的帮助，谢谢！

我正在开发 TLS 1.2 客户端。客户端无法与服务器建立安全上下文。它正在发送带有某些扩展的 ClientHello。然后它从服务器接收多条消息：ServerHello、Certificate、Server Key Exchange和。之后，客户端使用错误代码重置连接。CertificateRequestServer Hello Doneunexpected_message

Chrome 浏览器可以很好地与同一目标主机建立安全上下文。ClientHello我看到它在其消息中发送了更多的扩展。

除了默认插入的消息外，如何向我的 ClientHello 消息添加扩展？客户端是 C++，它使用 Schannel 与服务器通信，并多次调用该函数InitializeSecurityContext()来sspi.h建立安全上下文。

非常感谢被剪断的 C++ 代码的小样本，以及任何可以帮助我了解客户问题所在的建议。