我只是 HTTPS 网站上众多使用 SSL/TLS 协议的用户之一。
出于安全考虑，我希望将 TLS 协商限制为最低 TLS1.1 和 AES 密码。原因请参阅 SSLLabs 和 OWASP。
但我知道旧版浏览器（WinXP 上的 IE 等）在这种情况下连接我的网站时会出现问题（协商失败，因此不会显示任何网站）。
我的问题是，我宁愿为我的访问者提供一个关于更新浏览器的后备页面（在不安全的线路上），而不是让他们不知道发生了什么（并因此在帮助台接到大量电话）。
当然，也可以选择启用较旧的协议和密码，然后将它们放入某个隔离区，如下面的链接所示。但这感觉像是一种变通方法，需要大量额外的工作设备。 https://devcentral.f5.com/questions/how-do-i-restrict-tls-negotiation-to-minimum-tls-v12
我的问题是：
- 如果协商失败，是否有其他我不知道的方法将浏览器发送到“后备”页面？
- 如果没有，是否可以将某些内容添加到 TLS 协议版本 1.3 中以解决此问题？例如，为应用层开放一个“后备”解密字段，以某种方式通知浏览器，如果无法进行握手，浏览器就知道应该回退到其他资源？（也许这更像是 IETF 的问题，但由于他们也阅读了这个论坛，所以我就在这里问吧 :)）。
注意。我见过一些网站实际上允许通过 http 进行连接，例如 http://example[.]com:443/，并在这种情况下提供一条消息，您应该使用 https 协议重试。类似这样的 ;)。
答案1
如果协商失败，是否有其他我不知道的方法将浏览器发送到“后备”页面？
不，因为这不是规范的一部分。
你能做的最好的事情是使用一种配置，在支持它的客户端上优先使用更好的密码，在不支持它的客户端上回退到较弱的密码。你可以使用以下方法测试你的配置SSL 实验室 SSL 测试
如果没有，是否可以将某些内容放入 TLS 协议版本 1.3 中以解决此问题？例如，开放一个“后备”解密字段，供应用层填写，以某种方式通知浏览器，如果无法进行握手，浏览器就知道应该回退到其他资源？（也许这更像是 IETF 的问题，但由于他们也阅读了这个论坛，所以我就在这里问吧 :)）。
我不认为他们读过这个...:)
答案2
我不认为这是一种解决方法，如果服务器首先协商出最佳密码，然后根据密码的质量决定向客户端提供哪个页面，例如安全页面或不安全密码的后备页面。在此后备页面上，它可以提供有关问题的信息或将客户端重定向到其他信息。
我认为在未来版本的 TLS 中构建类似的东西没有任何好处，因为使用安全性较低的密码来提供这些信息比根本不加密要好得多，就像在协商完全失败时所做的那样。
但是如果服务器能够支持轻松使用此行为，那就太好了，例如，一种区分安全和不太安全的密码的方法，并使得为后者添加错误页面变得容易。当然，所有人都希望 SSLabs 和其他公司能够检测到这种行为，这样他们就不会因为支持不安全的密码而因为这些错误消息而得到差评。