我只是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
我的问题是：
我不认为这是一个解决方法，如果服务器首先协商最好的密码，然后根据密码的质量决定哪个页面服务于客户端，例如安全页面或不安全密码的回退页面。 在此回退页面上，可以提供有关问题的信息或将客户端redirect到其他信息。
我认为在未来的TLS版本中构build类似的东西没有任何优势，因为提供这些信息的安全性比不encryption的要好得多，比如在协商完全失败的情况下完成。
但是，如果服务器增加了对这种行为的简单使用的支持，例如一种区分安全和安全性较低的密码的方法，并且可以很容易地为后一种情况添加错误页面。 当然，所有人都希望SSLabs和其他人能够检测到这种行为，以便在支持不安全的密码的时候不会因为这个错误消息而得到不好的印记。
有没有另外一种方法，我不知道在协商失败的情况下将浏览器发送到“回退”页面？
不，因为这不是规范的一部分
你所能做的最好的事情就是使用一个configuration，在支持它的客户端上使用更好的密码，而在不支持的客户端则使用更弱的密码。 您可以使用SSL实验室SSLtesting来testing您的configuration
如果没有的话，是否可以在TLS协议版本1.3中join一些东西来解决这个问题？ 比如为应用层打开的“回退”解密字段，通过某种方式告知浏览器，如果握手不可能，浏览器就知道应该回退到其他资源。 （也许更多的是IETF的问题，但是因为他们也读这个论坛，所以我只是在这里问:)）。
我不认为他们读了… 🙂