Redirecionar o navegador com base em protocolo ou criptografia SSL não-negociável

Question

Sou apenas um dos muitos usuários dos protocolos SSL / TLS em um site HTTPS.

Por boas razões de segurança, gostaria de restringir a negociação TLS ao TLS1.1 mínimo com cifras AES. Razões estão disponíveis no SSLLabs e OWASP.

Mas eu sei que os navegadores mais antigos (IE no WinXP etc.) terão problemas nesse caso se conectando ao meu site (a negociação falhará, portanto nenhum site será exibido).

Meu problema é que eu gostaria de fornecer aos meus visitantes uma página de fallback (em uma linha insegura) sobre a atualização do navegador do que deixá-los em branco sobre o que aconteceu (e receber muitas chamadas no helpdesk sobre isso ).

Existe, é claro, a opção que habilita os protocolos e cifras mais antigos e depois os coloca em algum site de quarentena, como sugere o link abaixo. Isso, no entanto, parece uma solução alternativa, para a qual uma carga de dispositivos extras de trabalho está envolvida.   link

Minha pergunta é:

1. Existe outra maneira que não sei para enviar navegadores para uma página de 'fallback' no caso de a negociação falhar?
2. Se não, seria possível colocar algo na versão 1.3 do protocolo TLS para corrigir esse problema? Tal como um campo de decriptação de 'fallback' que está aberto para a camada de aplicação preencher com alguma forma de informar os navegadores que se o handshake não seria possível, o navegador sabe que deve recorrer a algum outro recurso? (talvez mais de uma pergunta para o IETF, mas desde que eles também leem este fórum, eu vou perguntar aqui:)).

Answer 1

Eu não acho que seja uma solução alternativa, se o servidor primeiro negociar a melhor cifra possível e, em seguida, decidir com base na qualidade da cifra qual página exibir para o cliente, por exemplo, a página segura ou a página de fallback para cifras inseguras. Nesta página de fallback, ele pode fornecer informações sobre o problema ou redirecionar o cliente para outras informações.

Eu não vejo nenhuma vantagem em construir algo como isso em uma versão futura do TLS, porque é muito melhor fornecer essas informações com uma codificação menos segura do que não criptografada, como seria feito se a negociação falhou completamente.

Mas seria bom se os servidores adicionassem suporte para facilitar o uso desse comportamento, por exemplo, uma maneira de distinguir entre cifras seguras e menos seguras e facilitar a adição de páginas de erro para o último caso. E, claro, todos querem que SSLabs e outros possam detectar esse comportamento para que eles não fiquem com marcas ruins quando suportarem cifras inseguras apenas para essas mensagens de erro.

    

Answer 2

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

Não, como isso não faz parte da especificação
A melhor coisa que você pode fazer é usar uma configuração que prefira melhores cifras em clientes que a suportem, e recorra a cifras mais fracas em clientes que não o façam. Você pode testar sua configuração usando o Teste SSL SSL Labs

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 :)).

Eu não acho que eles leiam isso ...:)