Redirect browser based on non-negotiable SSL/TLS protocol or cipher

I’m just one of the many many users of the SSL/TLS protocols on a HTTPS site.

For good security reasons I'd like to restrict the TLS negotiation to minimum TLS1.1 with AES ciphers. Reasons are available at SSLLabs and OWASP.

But I know that older browsers (IE on WinXP etc.) will have issues in that case connecting to my website (negotiation will fail, thus no website will be shown).

My issue is that I'd rather like to provide my visitors with a fallback page (on a insecure line) about updating the browser than leaving them in the blank about what happend (and getting loads of calls on the helpdesk about this).

There is of course the option enabling the older protocols and ciphers and afterwards putting them into some quarantaine site like the link below suggests. This however feels like a workaround, for which a load of extra work devices are involved. https://devcentral.f5.com/questions/how-do-i-restrict-tls-negotiation-to-minimum-tls-v12

My question is:

1. Is there another way that I do not know to send browsers to a 'fallback' page in case the negotiation fails?
2. If not, would it be possible to put something into the TLS protocol version 1.3 to fix this issue? Such as a 'fallback' decryption field that is open for the application layer to fill in with some way of informing browsers that if the handshake would not be possible the browser knows it should fallback to some other resource? (maybe more of a question for the IETF, but since they also read this forum, I'll just ask it here :)).

Note. I've seen websites that actually allow connecting on http like http://example[.]com:443/ and providing a message in that case you should retry with https-protocol. Something like that ;).

Solution 1:

Is there another way that I do not know to send browsers to a 'fallback' page in case the negotiation fails?

No, as this is not part of the specification
The best thing you can do is using a configuration which prefers better ciphers on clients which support it, and falls back to weaker ciphers on clients that don't. You can test your configuration using SSL Labs SSL Test

If not, would it be possible to put something into the TLS protocol version 1.3 to fix this issue? Such as a 'fallback' decryption field that is open for the application layer to fill in with some way of informing browsers that if the handshake would not be possible the browser knows it should fallback to some other resource? (maybe more of a question for the IETF, but since they also read this forum, I'll just ask it here :)).

I don't think that they read that... :)

Solution 2:

I don't think that it is a workaround, if the server first negotiates the best cipher it can and then decides based on the quality of the cipher which page to serve to the client, e.g. the secure page or the fallback page for insecure ciphers. On this fallback page it can provide information about the problem or redirect the client to other information.

I don't see any advantages to build something like this into a future version of TLS, because it is much better to provide these information with a less secure cipher than not encrypted at all, like it would be done if the negotiation failed completely.

But it would be nice if servers added support for easy use of this behavior, e.g. a way to distinguish between secure and less secure ciphers and make it easy to add error pages for the latter case. And of course all want that SSLabs and others can detect this behavior so they don't get bad marks when supporting insecure ciphers just for this error messages.