TLS 1.2 服务器/客户端能否仅使用 TLS_RSA_WITH_AES_128_CBC_SHA？

Question

我正在将嵌入式 TLS 1.0 实施更新为 TLS 1.2（具有 1MB 或更少代码空间且没有操作系统的设备）。在这一点上，我有 AES-128 和 AES-256 CBC 密码与 SHA-1 和 SHA-256 摘要一起工作，以实现最小化。该库无法协商 SSLv2、SSLv3、TLS 1.0 或 TLS 1.1 连接。

我觉得这已经足够了，因为 RFC 5246 规定，“TLS_RSA_WITH_AES_128_CBC_SHA 现在是实施密码套件的强制性要求。”

然而，当我阅读安全博客上的各种帖子时，我看到一些建议会让用户禁用该套件，并且（例如）只允许 ECDHE_RSA 或 DHE_RSA 变体。

所以我的问题是，使用我们库的设备是否会与现代网络浏览器（作为服务器）和现代 https/smtps/pop 服务器（作为客户端）互操作。 是否存在无法协商 TLS_RSA_WITH_AES_128_CBC_SHA 连接的 TLS 1.2 客户端/服务器？

Answer 1

我不确定目前是否有许多支持 TLS 的服务器无法与 TLSv1.2 协商 TLS_RSA_WITH_AES_128_CBC_SHA，因为它是 TLSv1.2 的强制密码套件。

但是有一些事情要记住：

• TLS_RSA_WITH_3DES_EDE_CBC_SHA 对于 TLSv1.0 和 TLSv1.1 是必需的，但由于安全原因，它不再被每个服务器支持，
• Mozilla 建议（而且不是唯一一个）支持AES128 而不是AES256，
• DHE 或 ECDHE 允许的完美前向保密 (PFS) 现在是必备功能。

因此，如果我可以为您提供 4 个密码套件（与您的数量相同），我会说这些密码套件从最强到最弱：

1. TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
2. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
3. TLS_RSA_WITH_AES_128_GCM_SHA256
4. TLS_RSA_WITH_AES_128_CBC_SHA

我会说这 4 个密码套件带来了足够的安全性和与TLSv1.2 服务器的兼容性。

现在只支持TLSv1.2的问题是另一个问题，但是如果你有足够的空间，我建议你也添加TLSv1.0（TLSv1.1不提供额外的兼容性）。

PS：之所以青睐AES128 而不是AES256，是因为有些人认为AES256 增加的额外安全性（目前）毫无价值，而AES128 似乎更能抵抗定时攻击.

Answer 2

“所以我的问题是使用我们库的设备是否会与现代 Web 浏览器（作为服务器）和现代 https/smtps/pop 服务器（作为客户端）互操作。是否存在无法协商的 TLS 1.2 客户端/服务器TLS_RSA_WITH_AES_128_CBC_SHA 连接？”

是的，有很多实现都失败了。

最常见的：

1. 仍然发送 SSL2.0 Client Hello 的客户端
2. 仅支持 PFS 密码套件的客户端/服务器
3. 仍然不支持 TLS 1.2 的服务器
4. 不再支持 TLS 1.2 的服务器 - 因为这些服务器仅支持 TLS 1.3

我的建议是：

• 还支持 TLS 1.3（实现起来并不难，我做到了）
• 也支持 DHE

或者使用https://www.ssllabs.com/ssltest/index.html 之类的工具/网站并测试您的服务器的兼容性/安全性，直到对您来说足够为止。