Представлен эксплойт, способный блокировать работу любого SSL-сервера

Выходит я нормальный админ :D ROTFL :D :D :D

Спасибо!!! :)

Андрейка близок к истине :) http://habrahabr.ru/blogs/infosecurity/128833/

Там написано, не очень цензурно, чтобы скрипт-кидди шли подальше. Скрипт-кидди это такой термин (буквально "скриптовые сосунки"), который означает нехороших людей, которые скачивают эксплойт и компилируют его не читая или не понимая исходного кода. Еще там есть рекомендация прочитать исходный код. Обычно коды эксплойтов пишутся так, что в них есть небольшие ошибки, очевидные специалисту, и неочевидные тем самым скрипт-кидди. Это своеобразная такая защита от дурака.

Объясняю суть уязвимости:

даже если вы будете долго следить за одинаковыми подключениями к ssh и одинаковыми попытками войти с одним и тем же логином и паролем вы будете видеть в tcpdump разные пакеты с разными данными,

т.к. при каждом подключении стороны кроме сертификата еще и _совместно_ генерируют соль, специфичную именно для этой сессии.

Используется для этого алгоритм Дифи-Хеллмэна с модификациями.

http://ru.wikipedia.org/wiki/%D0%90%D0%BB%D0%B3%D0%BE%D1%80%D0%B8%D1%82%D0%BC_%D0%94%D0%B8%D1%84%D1%84%D0%B8_%E2%80%94_%D0%A5%D0%B5%D0%BB%D0%BB%D0%BC%D0%B0%D0%BD%D0%B0

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

Отключение ssl-renegotiation делает принципиально невозможным использование нескольких SSL сертификатов на одном IP.

Это минус.

Но благо эту возможность пока никто и не использовал массово (несколько сертификатов на 1 Ip в смысле)

После отключения ssl-renegotiation каждое рукопожатие будет отдельной tcp сессией.

И каждую сессию сможет выловить обычный пакетный фильтр, и отправить атакующего в бан.

Это плюс.

Но у нас есть целые мелкие города, которые выходят наружу через провайдерский NAT. И банки будут банить доступ в свой клиент банк целыми офисами, домосетями, городками... Масштабно.

Это минус.

В общем эта уязвимость в очередной раз намекает на то что на ipv6 придется переходить обязательно, а NAT допускать не выше чем уровень квартиры.

hvosting или покупать аппаратные решения, которые легко тянут overk 290k коннектов multi ssl и передают http на backend

Тут вопрос не в коннектах одновременно, для поддержания которых требуется оперативка и расходы на шифрование уже готовым ключем, а в "коннектах в секунду".

Основной проблемой тут думаю является проверка на простоту очень больших чисел.

290k - это как раз в секунду

Эксплойт рабочий - проверял на nginx 1.0.8

Чтобы работал на новых версиях nginx нужно

закомментировать всего несколько строк :)

http://pastebin.com/nxRqXCNh

Кладет 4-х ядерный Xeon только в путь.

hint: TCP reconnect for every handshake

Вероятно можно настроить firewall на отсечение,

выложите конфиг если получится.

Хм... у меня завести не удалось говорит:

SSL: error:00000000:lib(0):func(0):reason(0)

Потом иногда промелькивает:

Handshakes 0 [0.00 h/s], 184 Conn, 74 Err

Ну и сервер понятно что вообще никак не замечает этого...

Погуглил чуть-чуть, грят это неправильная работа с openssl. Попробую на другой машине.

На другой машине грит: OPENSSL LIBRARIES ARE TO OLD :)

babnicks добавил 28.10.2011 в 10:51

Эксплойт завелся для SSL1, апач лег "на ура".

Завести для nginx с SSL3 пока не удается, буду пробовать ибо проблема-то действительно суровая.

babnicks добавил 28.10.2011 в 12:09

Вы не правы... Комментировать эту проверку бесполезно, при этом не будут создаваться новые коннекты.

Создания новых коннектов я добился, но что-то сервер упорно не кладется... Сейчас эксперементирую, результаты отпишу.

Я достаточно написал, чтобы догадаться как запустить,

чтобы работало. Подсказка: параметр -l