...服务器应该首先提供最强的密码，然后才提供较弱的密码。

只要服务器只支持足够强大的密码，就安全性而言，谁选择密码实际上并不重要。与安全性不同，其他标准是相关的，通常是从客户端或服务器的角度来看的性能。仅使用“更强”的密码可能会增加感知值，但不会增加实际值（仍然假设服务器仅支持足够的字符串密码）。

另请参阅TLS 标准是否要求在协商要使用的密码时始终使用服务器端首选项？ 关于为什么人们更喜欢客户端密码顺序或为什么不喜欢。

从安全角度来看，我认为该命令无关紧要。唯一相关的是密码是否被认为是安全的；这就是为什么通常应该从服务器列表中删除弱密码的原因。请记住，客户端将从服务器提供给客户端的内容中进行选择，并且由客户端根据他们实现的内容或他们拥有的硬件来选择一个。我知道在 openssl 中您可以选择订单，拥有它看起来不错，但客户可以根据他们的要求从该列表中选择一个。

标准 TLS 协商过程*没有来回，客户端发送支持的密码套件列表，服务器选择一个。根据标准，服务器应该尊重客户的偏好，但很多人不这样做。

让客户端选择密码是有正当理由的，例如对于不支持硬件加密的低功耗客户端，chacha20 可能比 AES 更快，但如果低功耗客户端确实具有对 AES 的硬件支持，那么它可能会更好选项。

当您需要支持旧客户端时，问题就来了。您有时会遇到这样的情况：如果可以避免的话，您宁愿不使用密码套件，但您不能完全禁用它，因为它会削减您需要支持的客户端。

理想情况下，您会让客户端在同样好的密码套件之间进行选择，但如果它们是唯一的选择，则只使用不太好的密码套件。可悲的是，我不知道有任何服务器软件实际上支持这样做，服务器强制密码套件顺序的选项是全部或全部。

* 虽然有些客户端会使用不同的密码列表进行多次连接尝试。