Я всего лишь один из многих пользователей протоколов SSL / TLS на сайте HTTPS.
Из соображений безопасности я хотел бы ограничить согласование TLS минимумом TLS1.1 с шифрованием AES. Причины доступны на SSLLabs и OWASP.
Но я знаю, что в старых браузерах (IE на WinXP и т. Д.) В этом случае возникнут проблемы с подключением к моему веб-сайту (переговоры не удастся, поэтому веб-сайт не будет отображаться).
Моя проблема в том, что я бы предпочел предоставить своим посетителям резервную страницу (в небезопасной строке) об обновлении браузера, а не оставлять их в поле зрения о том, что случилось (и получать множество звонков по этому поводу в службу поддержки).
Конечно, есть возможность включить старые протоколы и шифрование, а затем поместить их на какой-нибудь карантинный сайт, как предлагает ссылка ниже. Однако это похоже на обходной путь, для которого требуется множество дополнительных рабочих устройств. https://devcentral.f5.com/questions/how-do-i-restrict-tls-negotiation-to-minimum-tls-v12
У меня вопрос:
Я не думаю, что это обходной путь, если сервер сначала согласовывает лучший шифр, который он может, а затем решает в зависимости от качества шифра, какую страницу обслуживать клиенту, например защищенная страница или резервная страница для незащищенных шифров. На этой резервной странице он может предоставить информацию о проблеме или перенаправить клиента на другую информацию.
Я не вижу никаких преимуществ для встраивания чего-то подобного в будущую версию TLS, потому что гораздо лучше предоставить эту информацию с помощью менее безопасного шифра, чем вообще не зашифрованного, как если бы согласование полностью не удалось.
Но было бы неплохо, если бы серверы добавили поддержку для легкого использования этого поведения, например. способ различать безопасные и менее безопасные шифры и упростить добавление страниц ошибок для последнего случая. И, конечно же, все хотят, чтобы SSLabs и другие могли обнаружить это поведение, чтобы они не получали плохих оценок при поддержке небезопасных шифров только для этих сообщений об ошибках.
Есть ли другой способ, который я не знаю, чтобы отправить браузеры на «резервную» страницу в случае неудачного согласования?
Нет, так как это не входит в спецификацию
Лучшее, что вы можете сделать, - это использовать конфигурацию, которая предпочитает лучшие шифры на клиентах, которые ее поддерживают, и возвращается к более слабым шифровам на клиентах, которые этого не делают. Вы можете проверить свою конфигурацию, используя SSL Labs SSL Test
Если нет, можно ли что-нибудь добавить в протокол TLS версии 1.3, чтобы исправить эту проблему? Например, «резервное» поле дешифрования, которое открыто для уровня приложения, чтобы заполнить его каким-либо способом информирования браузеров о том, что, если рукопожатие невозможно, браузер знает, что он должен вернуться к какому-то другому ресурсу? (возможно, это больше вопрос для IETF, но поскольку они также читают этот форум, я просто задам его здесь :)).
Не думаю, что они это читают ... :)