BEAST и TLS 1.0: проверяем SSL у клиентов и переводим nginx и Apache на RC4

На прошлой неделе Juliano Rizzo и Thai Duong показали на Ekoparty рабочий эксплойт для атаки на TLS 1.0 в режиме CBC. Назвали BEAST - Browser Exploit Against SSL/TLS. Уязвимость известна теоретически с 2002 года, но рабочая демонстрация - это уже другой разговор. Суть: атакующий в позиции MitM может расшифровать HTTPS-сессию, если браузер и сервер договорились о TLS 1.0 с CBC-шифром. Заголовки cookie - очевидная цель.

Для нас это значит одно: нужно пройтись по всем клиентам, у кого мы сопровождаем SSL-сервисы, и понять, где реально торчит уязвимая конфигурация.

Что смотрели

Первым делом составили список сервисов, где TLS вообще присутствует. Получилось три типовые категории:

• nginx перед веб-приложениями - у нескольких клиентов это основной SSL-терминатор.
• Apache с mod_ssl - старый добрый httpd, у части клиентов ещё не переехавших на nginx.
• Exchange OWA - корпоративная почта наружу, IIS с SSL, и вот тут всё веселее, потому что менять конфигурацию IIS без тестирования неприятно.

Для проверки текущего состояния прогнали openssl s_client по каждому хосту и посмотрели, какие шифры реально предлагает сервер. Дополнительно - nmap с --script ssl-enum-ciphers. Картина ожидаемая: везде TLS 1.0, CBC-шифры вроде AES128-SHA и DES-CBC3-SHA стоят на первых позициях.

RC4 как обходной путь

Правильный ответ на BEAST - переход на TLS 1.1 или 1.2, которые используют другую схему IV и CBC-атаке не подвержены. Проблема в том, что поддержка TLS 1.1 в браузерах сейчас - это не то чтобы повсеместно. IE8, который у большинства корпоративных клиентов стоит по умолчанию, с TLS 1.1 работает криво или вообще не работает без дополнительных телодвижений. Firefox и Chrome лучше, но гарантировать совместимость со всем зоопарком устройств мы не можем.

Поэтому краткосрочный обходной путь - принудительно поставить RC4 первым в списке шифров. RC4 - поточный шифр, к CBC-атаке отношения не имеет. BEAST через него не работает. Это временное решение, у RC4 есть свои известные слабости в теории, но на практике для данной задачи оно закрывает конкретную проблему здесь и сейчас.

nginx. В ssl_ciphers явно прописываем RC4 первым:

ssl_ciphers RC4:HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;

ssl_prefer_server_ciphers on здесь обязателен - иначе клиент может выбрать шифр из своего списка и выбрать CBC-вариант даже если сервер предлагает RC4.

Apache. Аналогично в SSLCipherSuite:

SSLCipherSuite RC4-SHA:RC4-MD5:HIGH:!aNULL
SSLHonorCipherOrder On

Exchange OWA оказался сложнее всего. IIS сам по себе управляется через реестр - HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL. Туда можно прописать отключение конкретных шифров, но это влияет на весь сервер, не только на OWA. На двух клиентах Exchange живёт на отдельной машине - там проще. На одном - Exchange и файловый сервер на одном железе, и трогать SCHANNEL там мы пока не стали: риск сломать что-нибудь в Kerberos или LDAP-over-SSL выше, чем польза от немедленного закрытия BEAST.

Что реально угрожает

Честно говоря, BEAST требует нескольких условий одновременно: атакующий должен быть в позиции MitM в сети пользователя, уметь инжектировать JavaScript в страницу жертвы и иметь достаточно времени для набора трафика. Это не «зашёл на сайт - взломали», это активная атака с контролем сетевого сегмента. На корпоративных клиентах с нормальным разделением сетей сценарий менее реальный, чем в открытых Wi-Fi-сетях.

Тем не менее - публичные сервисы вроде OWA, торчащего в интернет, и веб-приложений с авторизацией по cookie - это именно те цели, ради которых атака и проводится. Откладывать нет смысла.

Где сейчас и что дальше

По итогам нескольких дней работы:

• nginx и Apache у клиентов - переведены на RC4, проверены через s_client, совместимость с основными браузерами подтверждена.
• Exchange OWA - на двух из трёх инсталляций сделали, на третьей ждём выделенного окна обслуживания.
• Переход на TLS 1.1 - это следующий шаг, и он требует отдельного планирования: проверить поддержку на стороне клиентов, протестировать браузерную совместимость, убедиться что внутренние инструменты мониторинга работают корректно.

Самое неудобное в этой ситуации: правильное решение (TLS 1.1+) сейчас не ставится одним конфигом - нужна работа с клиентской стороной. А временное решение (RC4) устраняет именно этот вектор, но создаёт потенциальный задел для будущих головных болей с этим шифром.

Если вы ведёте SSL-сервисы и не уверены в их текущей конфигурации - это хороший повод для аудита защищённости. Пройтись по реальному списку шифров занимает пару часов, зато картина сразу становится конкретной.