Очень быстрый, поскольку он в основном объясняется в разделе Как отключить SSL 3.0 на веб-сайтах, ролях и виртуальных машинах Azure , но есть несколько моментов, которые стоит добавить. О — на всякий случай, если POODLE был для вас новостью, вернитесь и прочитайте мой пост на Все, что вам нужно знать об ошибке POODLE SSL с прошлой недели.
Возвращаясь к руководству Nazim, приведенному выше для веб-сайтов Azure, вы можете либо установить расширение сайта, чтобы отключить SSL 3, либо создать правило перезаписи URL, которое просматривает пользовательский заголовок в запросе. Я считаю, что последний всегда предпочтительнее, так как он помещает его прямо в конфиг сайта. Разверните его где-нибудь еще позже, и конфигурация все еще хороша (при условии, что это веб-сайт Azure, который распознает настройку). Я вижу, что некоторые люди предпочитают расширение сайта, так как это означает, что вам не нужно повторно развертывать сайт, но если вы беспокоитесь об этом, у вас, вероятно, есть более серьезные проблемы!
Теперь, прежде чем развертывать исправление, давайте удостоверимся, что SSL 3 действительно включен, потому что лично мне нравится видеть доказательства того, что изменения, которые я делаю, действительно что-то делают. Вот проверка сайта Qualys SSL Labs перед любыми изменениями:
Здесь мы видим, что SSL 3 все еще жив и работает, и, действительно, очень удобное предупреждение о риске POODLE. Теперь давайте возьмем исправление, которое представляет собой правило перезаписи URL, которое выглядит так:
<!-- Defending against POODLE -->
<rule name="Block SSL3.0" patternSyntax="Wildcard" stopProcessing="true">
<match url="*" />
<conditions>
<add input="{HTTP_X_FORWARDED_SSL30}" pattern="1" />
</conditions>
<action type="CustomResponse" statusCode="403" subStatusCode="900" statusReason="Forbidden" statusDescription="SSLv3 connections are forbidden by this site" />
</rule>
Это просто конфигурация Назима, и это очень прямое правило переписывания. Он просматривает запрос, поступающий на сайт, и, если у него есть заголовок с именем «{HTTP_X_FORWARDED_SSL30}», он просто возвращает HTTP 403. Почему? Хороший вопрос…
Все это связано с тем, что веб-сайты Azure представляют собой PaaS-предложение, в то время как у вас есть контроль над сайтом, но у вас нет контроля над базовой конфигурацией ОС, и именно здесь вы обычно отключаете SSL 3. Кроме того, SSL — это прекращается до сервера, на котором фактически работает сайт, и это делается в общей инфраструктуре (это также, где вышеупомянутый заголовок добавляется к запросу до того, как он попадает на сайт). Суть в том, что вы, как отдельное лицо, не можете контролировать конфигурацию SSL. Добавляя этот новый заголовок при прекращении действия SSL, веб-сайт может узнать, какая версия протокола была использована, и действовать соответствующим образом. Это довольно изящный маленький трюк на самом деле.
Так почему бы просто не выключить его вообще? Я имею в виду отключить его на конечной точке SSL перед веб-сайтами Azure? В любом случае, многое не сломается, потому что никто больше не использует его, верно? Почти никто и в этом заключается проблема. Оказывается, люди немного раздражаются, если вы ломаете их вещи, даже если это всего лишь небольшой процент людей и небольшой процент вещей. Ясно, что ребята из Azure посмотрели на ситуацию и взвесили последствия ее полного отключения по сравнению с тем, что может произойти, если ее эксплуатируют, и почувствовали, что лучшее промежуточное звено — сделать ее настраиваемой. Да, это означает, что бездействие делает вас уязвимым, и это не так агрессивно, как, скажем , подход CloudFlare, но, безусловно, это было бы взвешенное решение. SSL 3 умрет естественной смертью в какой-то момент и неизбежно будет отключен с полной остановкой, но, очевидно, Microsoft считает, что это слишком рано, чтобы сделать это по всем направлениям в Azure.
Двигаясь дальше, я нажал на изменение конфигурации, давайте теперь проверим, что SSL Labs сканирует:
Хорошо, что дает? Мы все еще в состоянии ПУДЕЛЬ!
Вот в чем дело — когда вы «отключаете» SSL 3, используя этот подход, вы на самом деле не отключаете его. Помните, как я сказал, что SSL прекращает работу сайта выше по течению, и вы на самом деле имеете контроль только над самим сайтом? С точки зрения сканирования, SSL-соединение с использованием v 3 работает, так как оно успешно завершается на устройстве перед веб-сайтом Azure. То, что сайт затем ответит 403, похоже, не влияет на этот тест.
Так что же делать? Ну, во-первых, давайте удостоверимся, что изменение действительно работает, и это простая задача. Вот сайт с перенаправлением URL-адреса, загруженный в Internet Explorer:
Бизнес там как обычно, просто отлично. Теперь давайте настроим некоторые настройки:
Видишь, куда это идет? Мы заставляем IE говорить только по SSL 3 (это проще всего настроить в браузере Microsoft), давайте посмотрим, как это работает сейчас:
И есть 403 — веб-сайт не обработал запрос, как обычно, когда он поддерживал SSL 3, скорее правило URL переписывания вступило в силу и ответило первым.
Так это действительно решает проблему? Что-то вроде. POODLE эксплуатируется, глядя на то, как веб-сервер отвечает на запросы, отправленные через SSL 3, поэтому в этом отношении эта проблема пресечена (хорошо, только одна собачья аналогия) в зародыше. С другой стороны, SSL-соединение все еще можно «сделать», так как согласование с конечной точкой SSL все еще может происходить в версии v 3. Не имеет значения, является ли это тестом Qualys SSL Labs или даже просто прямым соединением с использованием OpenSSL вы, скорее всего, обнаружите, что многие из этих тестов сообщат, что SSL 3 включен, поскольку они просто ищут подтверждение связи v 3 для подтверждения или опровержения его присутствия.
Для многих людей проблема может заключаться в том, что им скажут, что их веб-сайт Azure по-прежнему поддерживает SSL 3 и поэтому терпит неудачу при любой корпоративной политике, разработанной для работы с POODLE. Здесь вполне может потребоваться некоторое объяснение: «Да, успешное рукопожатие все еще может происходить через SSL 3, но нет, сайт больше не подвержен риску атаки POODLE, поскольку он не вернет действительный ответ». До тех пор, пока Microsoft не попыталась убить тех немногих оставшихся зависимостей SSL 3, до тех пор, пока не будет устранен этот баланс, оценщикам рисков на веб-сайтах Azure потребуется некоторая объективность.
Обновление, 23 октября 2014 года: в комментариях произошла отличная дискуссия, и вполне справедливо возникли проблемы, которые я не очень хорошо решил, поэтому позвольте мне уточнить здесь и сейчас:
Ответив 403, когда ресурс запрашивается через SSL 3, веб-сайт больше не будет отображать страницу входа и больше не будет предлагать возможность установки и, следовательно, кражи cookie. Конечно, он не должен отвечать 403, теперь, когда есть заголовок запроса, который можно прочитать, вы можете реализовать любое поведение, которое вам нравится, но в качестве позиции по умолчанию, что, безусловно, нарушает сайт до такой степени, что вы больше не можете войти , Тем не менее, он не защищает запросы, которые уже имеют cookie. Кроме того, он также не защищает пользователей, которые не понижают соединение во время входа в систему, но защищают его после входа, будь то по стечению обстоятельств или умному хакерскому замыслу.
Другая вещь, на которую стоит обратить внимание, это то, что ответ SSL Labs действительно указывает на нечто важное: шифр RC4 имеет приоритет над CBC, который является уязвимым шифром в атаке POODLE. Это упомянуто в сообщении «POODLE смягчено» выше, а затем объяснено далее вниз по странице. Если кто-то получит MitM’d и его соединение будет успешно понижено до SSL 3 после того, как он войдет в систему и уже получит файл cookie с ценностью, он будет общаться через RC4, который, хотя и признан имеющим свои собственные проблемы, не является набором шифров, описанным в рекомендации.
В конечном счете, SSL 3 должен быть отключен, и, как я уже говорил выше, это неизбежно произойдет в какой-то момент. Хотя приведенные выше меры не являются идеальными, они значительно поднимают планку, чтобы атака была успешной.