我正在尝试找出最好的方法来选择提供哪些密码套件，以及问题可能是什么。
据我了解，在 SSL 握手期间，客户端（通常）会选择两端都支持的最安全的算法。但是，提供低强度算法的含义是什么？协商肯定不能被加密，因此 MITM 可以强制连接到最弱的通用密码套件吗？
为 HTTPS 选择密码套件
信息安全
tls
密码选择
2021-08-30 06:41:33
2个回答
客户端建议，但服务器选择。客户端发送它支持（并且愿意使用）的密码套件列表。该列表应该按偏好排序。服务器通过在此列表中选择一个密码套件进行响应。表现良好的服务器会尝试遵循客户端的偏好，但这并不是强制性的。最终，服务器选择。
在握手结束时，Finished发送消息，这些消息被加密并使用协商的秘密进行 MAC 化。这些消息的内容是根据完整握手消息计算的哈希值，包括客户端支持的密码套件列表。这意味着 MitM 无法更改该列表而不会在某些时候被抓住。
（但是，在存在TLS FalseStart的情况下，这并不完全正确：可以说服客户端使用它支持的最弱密码套件发送他的请求。但这里真正的弱点是客户端愿意支持弱密码套件，并不是说 MitM 攻击者对密码套件的选择有一定程度的控制。即使使用 FalseStart，攻击者的外部更改也会被服务器检测到，并且不会响应请求，更不用说响应了。 )
（SSLv2 没有在其 Finished 消息中包含密码套件列表，它被吹捧为 SSLv2 的“大缺陷”之一。）
如果您担心资源使用情况并且没有启用 AES-NI 的 CPU 以及支持的软件，请使用 RC4。Google 将 RC4 用于大多数（如果不是全部）服务。如果您在硬件和软件链上都支持 AES-NI，那么请使用 AES-256。