Сначала нужно прояснить несколько вещей.

Задний план

Мы немного смешиваем две разные концепции: протокол и набор шифров. SSLv3 - это протокол, а прямая секретность - черта согласованного набора шифров. Выбор набора шифров зависит от клиента, сервера и протокола, который согласовывается.

Это означает, что вы не можете полагаться на версию протокола, чтобы решить, поддерживает ли браузер прямую секретность (это, вероятно, изменится с TLS 1.3). SSLv3 (по крайней мере, в качестве спецификации) поддерживает некоторые наборы шифров прямой секретности, такие как SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA (хотя на практике я не вижу браузеров, поддерживающих этот набор шифров). То же самое и о том, что версия TLS не требует использования прямой секретности.

Internet Explorer - интересный случай, потому что это единственный крупный браузер, в котором поддерживаемые шифры зависят от версии браузера. и версия винды. Это связано с тем, что Internet Explorer переносит все согласование и обработку HTTPS на компонент Windows, называемый SChannel. Чтобы Internet Explorer поддерживал данный протокол и набор шифров, SChannel сначала должен его поддерживать. Это немного затрудняет определение поддерживаемых наборов шифров и протоколов.

Существует одна версия Internet Explorer, которая поддерживает SSLv3, и ничего больше, это Internet Explorer 6. Он остается единственным браузером, который в некоторой мере не поддерживает TLS 1.0 (это не совсем так; IE6 поддерживает его, это просто не включен по умолчанию). Итак, столкнувшись с проблемой отображения страницы с ошибкой, единственный браузер, на который вы будете ориентироваться, - это Internet Explorer 6. Я полагаю, что другой браузер мог отключить поддержку всех версий TLS и оставить выбранным только SSLv3, но это будет означать, что большая часть веб-сайтов с поддержкой HTTPS не будет работать для них, так как многие уже полностью отключили поддержку SSLv3. На практике я не думаю, что вы встретите много браузеров, которые поддерживают только SSLv3, но не IE 6. IE 8 в Windows XP по умолчанию поставляется с TLS 1.0, а любая версия IE в Windows Vista или более поздних версиях поддерживает на минимум TLS 1.0. Internet Explorer 11 в Windows 8 и Windows 7 поддерживает (на момент написания) последнюю версию TLS 1.2.

Отображается сообщение "Извините, SSLv3 отсутствует!" страница: Что могло пойти не так?

Подойдя ближе к вашему вопросу, вас беспокоит отображение страницы пользователям, чей браузер хочет подключиться с помощью SSLv3. У этого есть свои плюсы и минусы. Во-первых, имейте в виду, что у SSLv3 есть проблема, которая называется ПУДЕЛЬ. Открытие POODLE позволило многим веб-сайтам полностью отключить поддержку SSLv3.

Это приводит к проблеме курицы и яйца. Если бы вы перенаправляли пользователей на основе согласованной версии протокола, ваш веб-сервер должен был бы поддерживать SSLv3 в первую очередь, чтобы обнаружить его присутствие и выполнить перенаправление. Однако, поступая так, вы можете подвергнуть этих клиентов ненужному риску. Если сервер должен принять соединение SSLv3, чтобы показать страницу пользователю, что SSLv3 не разрешен, активный злоумышленник может использовать это как возможность использовать очень слабые места SSLv3. Например, предположим, что клиент аутентифицируется на вашем веб-сайте по HTTPS с использованием TLS 1.0. IE не поддерживает TLS_FALLBACK_SCSV, и активный злоумышленник переводит браузер на SSLv3. Если ваш сайт использует файлы cookie для аутентификации, злоумышленник теперь принудительно переключил браузер на SSLv3 (который будет обслуживать ваше перенаправление ошибки). но он может раскрыть файл cookie аутентификации. Помните, что как только пользователь получает свой файл cookie аутентификации, браузеры отправляют эти файлы cookie вместе с каждым запросом. Кража файла cookie аутентификации - серьезное дело, и оно вполне возможно в этом сценарии и при использовании POODLE. Таким образом, даже если вы пытаетесь открыть простую страницу с ошибкой, существует риск, связанный с поддержкой SSLv3.

IIS не может сделать это самостоятельно

Итак, к вашему актуальному вопросу. Нет Информационные службы Интернета сам по себе не может перенаправить запрос на основе версии SSL / TLS или набора шифров. Это может быть сторонний модуль, но я не знаю об этом. Однако у вас есть несколько вариантов.

Не удалось исправить в балансировщике нагрузки

Вы можете разгрузить соединение с обратным прокси-сервером, который поддерживает перенаправление на основе наличия SSLv3 - я не знаю, как сделать это на основе фактического набора шифров. Я знаю, что HAProxy может - вероятно, есть другие, с которыми я просто не знаком. Я не буду вдаваться в подробности, но с HAProxy вы можете назначить ACL на основе версии SSL следующим образом:

acl sslv3 ssl_fc_protocol SSLv3

Когда у вас есть ACL, вы можете отправить их на конкретный сервер или обработать, как хотите.

Может исправить с помощью собственного модуля IIS

Другими вариантами могут быть поиск или разработка собственного модуля для IIS, который может это сделать. IMHO, IIS не имеет великолепной поддержки для настройки и поддержки SSL. Лично я бы переложил SSL на обратный прокси, но я знаю, что это не для всех.

Можно исправить, просто отключив поддержку протокола ниже TLS 1.0

Третий вариант - просто поддерживать только наборы шифров с прямой секретностью и как минимум TLS 1.0. Используя набор шифров AES128+EECDH:AES128+EDH с TLSv1, TLSv1.1 и TLSv1.2 получите вашу поддержку для большинство браузеры. Единственные браузеры, которые остались бы без внимания, - это любая версия Internet Explorer в Windows XP, поскольку Windows XP не поддерживает какой-либо разумный набор шифров, который поддерживает прямую секретность. Насколько мне известно, Windows XP поддерживает только DHE с DSS, о поддержке которого вы абсолютно не хотите беспокоиться.

Мой способ: отключена поддержка протокола SSL

Последнее решение, которое я выбрал. Поддержка устаревших протоколов и наборов шифров представляет собой риск - даже если они существуют только для отображения страницы с ошибкой.