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

Не понял я про какие параметры Вы говорите, заработало для apache оно сразу.

Но вы сказали имхо не правильно, комментировать те строки бесполезно, при отключенном renegotiation работать оно не станет.

Надо делать так, чтобы для каждого handshake происходил tcp реконнект, в конце функции ssl_handshake_io прописываем и ничего не комментируем:

/* удалил дабы не искушать */ ;)

У меня на виртуалке дает около 900 шейков в секунду, при этом nginx грузится на 99%, но из браузера все равно стабильно отдает страницы.

Попробовал на живом серваке 4 x Xeon, ему вообще пофиг...

Возможно что с одной машины просто не получится его положить, в оригинале говорится о том, что надо несколько машин, может дело в этом.

Только вот я в упор не могу понять в чем тогда exploit, если делать каждый раз TCP-реконнект, то это ведь просто обычное поднятие ssl соединение и его последующее отключение.

Ну да, оно дает нагрузку, но никакого exploit'а все-таки с отключенным renegotiation нет и nginx в этом плане не уязвим.

Вобщем пока не вкурил я смысла всего этого для nginx... А вот для апача действительно все очень плохо...

Если я не прав, то поправьте.

Какой у Вас был SSL на nginx который Вы положили?

ssl_protocols SSLv3 TLSv1;

Ну я несколько приукрасил насчет положил, но 100% CPU

как бы подразумевает такую возможность при правильном

подходе. Загрузка страниц ощутимо тормозит.

Комментирование дает тот же эффект что и ваши строки,

легко проверить через вставку fprintf в tcp_connect и PEER_disconnect.

PEER_disconnect сам меняет p->state = STATE_TCP_CONNECTING.

Разницы особой нет, по крайней мере для nginx.

Ну это другое дело, а то я прям испугался, полез срочно проверять что и как 😂

Комментировать там не верно исходя из логики работы программы (я ее расковырял полностью).

Сначало разбераться не хотелось и я сделал как Вы написали и получил "SSL: error:00000000:lib(0):func(0):reason(0)" :)

Пришлось ковырять ;)

А вот p->state == STATE_TCP_CONNECTING действительно можно не писать, само присвоится, но это не важно...

Вобщем имхо резьюм такой:

Никакого exploita в случае с nginx нет, apache действительно ложится капитально...

"SSL: error:00000000:lib(0):func(0):reason(0)" генерит вызов SSLERR("SSL");

в функции SSL_set_rw, так что логика работы SSL не нарушена :)

Не путайте следствие с причиной, происходит ошибка при renegotiation так как nginx его не поддерживает вот и выдается ошибка...

Чтобы ошибки не было надо "передернуть" коннект, обозначенным способом.

Посмотрите в SSL_set_rw - там все что надо передергивается само,

если SSL_do_handshake зафэйлится.

Мой вариант у вас nginx на 100% CPU не грузил разве?

Ваш вариант выдает ошибки SSL и не показывает сколько текущих коннектов и какая скорость h/s.

То что в случае ошибки оно само передергивается, я не спорю :) Но хочется видеть процесс и его скорость...

С точки зрения заложенной в программу логики правильно НЕ комментировать :)

Интересно мерить h/s это и есть критичная велечина, у меня на VPS она = 927.81 h/s

Как говорится, вам шашечки или ехать? 😂

Для тестов пойдет.

В общем, можно ждать ацкий ботнет это все умеющий.

Дык не пойдет, не видно главного значения сколько запросов в секунду исполняется :)

Вобщем у меня на VPS получилось 900 штук в секунду что "на вскидку" равняется где-то 100 мегабитам доса...

Резьюм данной темы таков:

Вобщем в nginx нет никакой уязвимости, как я и говорил выше, есть просто не очень быстрая работа при установке SSL соединения, причем 2048 битные ключи примерно в 3 раза медленее чем 1024 битные.

В случае с nginx с помощью файроволла все легко лечится, путем установки ограничения на кол-во коннектов в секунду с одного IP.

А вот апач действительно под угрозой, через одно соединение можно хорошенько загрузить сервер.

Так что надо перекомпилировать апач с отключенным renegotiation, а еще лучше поставить его за nginx'ом :)

ps: на досуге может даже поковыряюсь в исходниках openssl, что-то они там такое ужасное замутили, что оно так тормозит...

Так это, можно мне в ПМ ссылочку на вариант который апач по вашему укладывает, буду у себя тестировать. А то сурово это как-то все.