基于不可协商的 SSL/TLS 协议或密码重定向浏览器

Question

我只是 HTTPS 站点上 SSL/TLS 协议的众多用户之一。

出于良好的安全原因，我想将 TLS 协商限制为使用 AES 密码的最低 TLS1.1。SSLLabs 和 OWASP 提供了原因。

但我知道旧浏览器（WinXP 上的 IE 等）在连接到我的网站时会出现问题（协商将失败，因此不会显示任何网站）。

我的问题是，我宁愿为我的访问者提供一个关于更新浏览器的后备页面（在不安全的线路上），而不是让他们对发生的事情一无所知（并在帮助台上接到大量关于此的电话）。

当然，可以选择启用旧协议和密码，然后将它们放入某个隔离站点，如下面的链接所示。然而，这感觉像是一种解决方法，其中涉及到大量额外的工作设备。 https://devcentral.f5.com/questions/how-do-i-restrict-tls-negotiation-to-minimum-tls-v12

我的问题是：

1. 如果协商失败，是否还有另一种我不知道的方式将浏览器发送到“后备”页面？
2. 如果没有，是否可以在 TLS 协议版本 1.3 中添加一些内容来解决此问题？例如为应用程序层打开的“回退”解密字段以某种方式通知浏览器，如果无法进行握手，浏览器知道它应该回退到其他资源？（对于 IETF 来说，可能更多是一个问题，但由于他们也阅读了这个论坛，所以我只会在这里提问:)）。

笔记。我见过实际上允许在 http 上连接的网站，例如 http://example[.]com:443/ 并在这种情况下提供消息，您应该使用 https 协议重试。类似的东西;)。

Answer 1

是否有另一种我不知道的方法可以将浏览器发送到“后备”页面，以防协商失败？

不，因为这不是规范的一部分
您可以做的最好的事情是使用一种配置，该配置在支持它的客户端上更喜欢更好的密码，而在不支持它的客户端上回退到较弱的密码。您可以使用SSL Labs SSL Test来测试您的配置

如果没有，是否可以在 TLS 协议版本 1.3 中添加一些内容来解决此问题？例如，为应用程序层开放的“后备”解密字段，以某种方式填充通知浏览器，如果握手不可能，浏览器知道它应该回退到其他资源？（也许对 IETF 来说是一个更多的问题，但由于他们也阅读了这个论坛，所以我就在这里问它:)）。

我认为他们没有读过……:)