ssl - 在 TLS 连接握手期间，客户端从哪里获取密码套件列表？

Question

客户端从哪里获取它要向服务器提出的密码套件列表？
例如，看起来在同一台机器上，两个不同应用程序的客户端可以提出不同的密码套装列表。
为了限制问题的范围，我想了解 RabbitMQ Client 和 TLS1.2。
更多说明
所以我在我的机器上安装了 RabbitMQ 服务，然后在 C# 代码中我尝试在没有任何密码套装配置的情况下连接(例如 var connection = factory.CreateConnection())。
所以在这里我的 C# 应用程序可以被视为客户端。
请注意，我询问的是客户端在“Client Hello”消息中发送的密码。
附言在某处我读到rabbitmq内部使用openssl，所以当我运行命令'openssl ciphers -s -tls1_2'时，当我在wireshark中看到rabbitmq客户端hello的密码套装时，我得到了一个不同的列表。此外，我在机器上没有任何覆盖密码的组策略。

Answer 1

见 https://tls13.ulfheim.net/获得 TLS 1.3 交换的漂亮图形表示。
在第二条消息中，ClientHello ，客户端除其他外提供它支持的密码列表。它在哪里得到它？在应用程序中硬编码或在决定连接后动态计算等。这一切都取决于应用程序，因此您需要调查其代码源/配置。
如果以 openssl s_client 为例作为 TLS 客户端，您拥有 -cipher和 -ciphersuites配置选项以指定连接时要宣布的特定密码。
如果你稍后在交流中查看，有一个 ServerHello服务器宣布将使用哪个密码套件。
这是怎么发生的？通常，服务器有自己的首选密码列表，按“质量”排序(加密强度，如优先 256 位而不是 128 位和/或其他属性，如优先 PFS 而不是非 PFS)，并根据它从客户端获得的信息，它试图选择双方都支持的“最佳”，这不一定总是可能的。
现在，当您在特定应用程序 (Google Chrome) 中添加评论时，您可以在 https://source.chromium.org/chromium/chromium/src/+/main:third_party/boringssl/src/ssl/ssl_cipher.cc;l=1152?q=cipher&ss=chromium%2Fchromium%2Fsrc 看到定义一个名为“ssl_create_cipher_list”的函数，其目标是构建密码列表，从所有已编译的列表开始，然后应用各种规则来启用/禁用一些并按有意义的顺序对它们进行排序。当然，这在很大程度上取决于应用程序的完成方式，但您当然可以在其他工具包中找到类似的操作。
最后，请注意 TLS 1.2(密码)和 TLS 1.3(密码套件)之间存在很大差异。它们是不相交的集合，当 TLS 1.2 在野外有“无数”密码时(例如，参见 https://www.openssl.org/docs/man1.1.1/man1/ciphers.html 以了解其中的很多)，TLS 1.3 仅定义了 5 个密码套件(参见 https://datatracker.ietf.org/doc/html/rfc8446#appendix-B.4)，其中一个是强制实现的，所以客户端和服务器之间自动协商的整个问题变得几乎没有实际意义。
正如您明确提到的 tls1.2 作为标签，请注意，今天没有真正的理由不使用 1.3(这就是为什么我的第一个链接是专门针对 1.3 的 - 握手例程在 1.2 中不同，但对于与您的密码问题)，您将从简化的操作、更好的密码学和更少的漏洞中获得很多好处。