☰

HaProxy - prefer-client-ciphers 是否意味着客户端可以选择服务器不支持的密码？

tag-icon • tag-icon ssl haproxy cipher
HaProxy - prefer-client-ciphers 是否意味着客户端可以选择服务器不支持的密码？

考虑这样的设置：

global
    # intermediate configuration
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    ssl-default-bind-options prefer-client-ciphers no-sslv3 no-tlsv10 no-tlsv11 no-tls-tickets

绑定选项设置prefer-client-ciphers。客户端可以选择，但是该选择是否仅限于我提供的绑定密码？

HaProxy 文档没有说明：https://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-prefer-client-ciphers

答案1

这个答案不是专门基于 Haproxy 而是基于一般的 TLS 行为：

TLS 客户端和 TLS 服务器各自都有一个可以支持/接受的密码列表，这些列表按各自的偏好排序。

在 TLS 握手期间，客户端会发送其支持的密码列表，然后服务器必须决定实际使用哪种密码。
只要各自的列表之间有重叠，就有可能挑选出每个人都支持的密码，并建立连接。

然而，即使存在这样的重叠，它们各自列表的顺序（即各自的偏好）也可能不同。

这种几乎普遍存在的设置（在不同的软件中名称不同，也常常用相反的视角来看）决定了谁的偏好应该获胜。

长期以来，服务器运营商之间的典型争论一直是“服务器端获胜，不要让愚蠢的客户端选择我们列表末尾的一些弱密码”（除非绝对必要）。
然而，最近出现了一种趋势，即“不要包含任何我们认为弱的密码，让客户端自己选择；低端客户端（物联网、低端移动设备等）可能会从选择 ChaCha20 而不是 AES 中受益匪浅”。

TL;DR 不，所选的密码必须是客户端和服务器都支持的密码，否则将无法建立连接，无论根据该设置谁的偏好获胜。

相关内容