C++ openssl：设置密码列表

Question

我有一个使用 openssl 库的非常基本的 C++ 应用程序。应用程序向服务器发送请求，密码套件列表必须是下一个：

4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53

使用 SSL_set_cipher_list 和 SSL_set_ciphersuites 我正在设置密码列表。但是当我使用下一个列表时： TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256

TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

TLS_RSA_WITH_AES_128_GCM_SHA256

TLS_RSA_WITH_AES_256_GCM_SHA384

TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA

我收到 4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53-255。但我不明白 255 到底来自哪里？它不应该出现。

Answer 1

255 是一个特殊的密码套装标识符。在处理安全问题时阅读 RFC 总是很有用的。

RFC5746

3.3.重新协商保护请求信令密码套件值 SSLv3 和 TLS 1.0/TLS 1.1 规范都要求实现在不理解 ClientHello 之后忽略数据（即扩展）。但是，在这种情况下，某些 SSLv3 和 TLS 1.0 实现会错误地使握手失败。这意味着提供“renegotiation_info”扩展的客户端可能会遇到握手失败。为了增强与此类服务器的兼容性，本文档通过特殊的信令密码套件值 (SCSV) “TLS_EMPTY_RENEGOTIATION_INFO_SCSV”定义了第二种信令机制，代码点为 {0x00, 0xFF}。此 SCSV 不是真正的密码套件（它不对应于任何有效的算法集）并且无法协商。相反，它与空的“renegotiation_info”扩展具有相同的语义，如以下部分所述。因为 SSLv3 和 TLS 实现可靠地忽略未知密码套件，所以 SCSV 可以安全地发送到任何服务器。 SCSV 也可以包含在 SSLv2 向后兼容的 CLIENT-HELLO 中（参见 [RFC5246] 的附录 E.2）。

现在您知道名称 TLS_EMPTY_RENEGOTIATION_INFO_SCSV，您可以尝试排除它。但这可能行不通。