Re: вопрос про heartbleed
On 10 Apr 2014, at 12:47, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Apr 10, 2014 at 07:24:22AM +0100, Anatoly Mikhailov wrote: на данный момент меня интересует только необходимость заказа новых ключей, я правильно понимаю, при включенном forward secrecy приватные ключи утечь не могли? Нет, вероятность утекания приватных ключей от включённости forward secrecy никак не зависит. Отдельный вопрос - какова эта самая вероятность. ребята из CloudFlare решили проверить эту вероятность экспериментальным путем https://www.cloudflarechallenge.com/heartbleed Анатолий On 10 Apr 2014, at 05:26, Илья Шипицин chipits...@gmail.com wrote: при включенном forward secrecy наличия закрытого ключа (у злоумышленника) недостаточно для расшифровки потока. от атаки на память сервера это не защищает четверг, 10 апреля 2014 г. пользователь Anatoly Mikhailov написал: Если SSL ciphers оставались стандартные (ssl_ciphers: дефолтное значение) на Nginx 1.3.14, то Forward Secrecy был включен. Вопрос: надо ли генерить CSR и заказывать новые SSL ключи или Forward Secrecy помог избежать полной утечки приватных ключей? Анатолий On 09 Apr 2014, at 16:46, Anton Yuzhaninov cit...@citrin.ru wrote: On 04/09/14 13:41, Vladislav Shabanov wrote: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Если очень хочется знать о безуспешных аттаках, то лучше использовать что то типа SNORT. И про heartbleed он должен знать. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос про heartbleed
On Friday 11 April 2014 14:02:40 Anatoly Mikhailov wrote: On 10 Apr 2014, at 12:47, Maxim Dounin mdou...@mdounin.ru wrote: Hello! On Thu, Apr 10, 2014 at 07:24:22AM +0100, Anatoly Mikhailov wrote: на данный момент меня интересует только необходимость заказа новых ключей, я правильно понимаю, при включенном forward secrecy приватные ключи утечь не могли? Нет, вероятность утекания приватных ключей от включённости forward secrecy никак не зависит. Отдельный вопрос - какова эта самая вероятность. ребята из CloudFlare решили проверить эту вероятность экспериментальным путем https://www.cloudflarechallenge.com/heartbleed Правильная ссылка: http://blog.cloudflare.com/answering-the-critical-question-can-you-get-private-ssl-keys-using-heartbleed -- Валентин Бартенев ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос про heartbleed
на данный момент меня интересует только необходимость заказа новых ключей, я правильно понимаю, при включенном forward secrecy приватные ключи утечь не могли? Анатолий On 10 Apr 2014, at 05:26, Илья Шипицин chipits...@gmail.com wrote: при включенном forward secrecy наличия закрытого ключа (у злоумышленника) недостаточно для расшифровки потока. от атаки на память сервера это не защищает четверг, 10 апреля 2014 г. пользователь Anatoly Mikhailov написал: Если SSL ciphers оставались стандартные (ssl_ciphers: дефолтное значение) на Nginx 1.3.14, то Forward Secrecy был включен. Вопрос: надо ли генерить CSR и заказывать новые SSL ключи или Forward Secrecy помог избежать полной утечки приватных ключей? Анатолий On 09 Apr 2014, at 16:46, Anton Yuzhaninov cit...@citrin.ru wrote: On 04/09/14 13:41, Vladislav Shabanov wrote: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Если очень хочется знать о безуспешных аттаках, то лучше использовать что то типа SNORT. И про heartbleed он должен знать. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос про heartbleed
Hello! On Thu, Apr 10, 2014 at 07:24:22AM +0100, Anatoly Mikhailov wrote: на данный момент меня интересует только необходимость заказа новых ключей, я правильно понимаю, при включенном forward secrecy приватные ключи утечь не могли? Нет, вероятность утекания приватных ключей от включённости forward secrecy никак не зависит. Отдельный вопрос - какова эта самая вероятность. Анатолий On 10 Apr 2014, at 05:26, Илья Шипицин chipits...@gmail.com wrote: при включенном forward secrecy наличия закрытого ключа (у злоумышленника) недостаточно для расшифровки потока. от атаки на память сервера это не защищает четверг, 10 апреля 2014 г. пользователь Anatoly Mikhailov написал: Если SSL ciphers оставались стандартные (ssl_ciphers: дефолтное значение) на Nginx 1.3.14, то Forward Secrecy был включен. Вопрос: надо ли генерить CSR и заказывать новые SSL ключи или Forward Secrecy помог избежать полной утечки приватных ключей? Анатолий On 09 Apr 2014, at 16:46, Anton Yuzhaninov cit...@citrin.ru wrote: On 04/09/14 13:41, Vladislav Shabanov wrote: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Если очень хочется знать о безуспешных аттаках, то лучше использовать что то типа SNORT. И про heartbleed он должен знать. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
вопрос про heartbleed
Добрый день! В чём суть уязвимости и как исправлять все, думаю, уже в курсе. А вот вопрос, который после исправления было бы интересно поизучать: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Вариант «включить уровень логов DEBUG и в нём утонуть» не нравится. У кого какие мысли? С уважением, Влад ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос про heartbleed
Hello! On Wed, Apr 09, 2014 at 01:41:06PM +0400, Vladislav Shabanov wrote: Добрый день! В чём суть уязвимости и как исправлять все, думаю, уже в курсе. А вот вопрос, который после исправления было бы интересно поизучать: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Вариант «включить уровень логов DEBUG и в нём утонуть» не нравится. У кого какие мысли? Максимум, что можно сделать со стороны nginx'а - это логгировать сам факт соединения (и он таки логгируется на уровне info). Следует однако понимать, что отличить соединение, в котором уязвимость эксплуатируется, от обычного соединения с обычным запросом при правильном подходе к вопросу эксплуатации данной уязвимости - не представляется возможным вообще никак. Разве что запрошенный через heartbeat кускок данных будет достаточно большим, чтобы вызвать segmentation fault в OpenSSL. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос про heartbleed
Существует ли простой способ сделать (на уровне конфигов, разумеется, программировать это скорее всего никому не захочется) логирование холостых обращений (сокет открыли, но ничего не GET/POST/…) ? И, кстати, вопрос тем, кто nginX отлаживает: а много таких холостых обращений «по жизни»? 09 апр. 2014 г., в 15:47, Maxim Dounin mdou...@mdounin.ru написал(а): Hello! On Wed, Apr 09, 2014 at 01:41:06PM +0400, Vladislav Shabanov wrote: Добрый день! В чём суть уязвимости и как исправлять все, думаю, уже в курсе. А вот вопрос, который после исправления было бы интересно поизучать: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Вариант «включить уровень логов DEBUG и в нём утонуть» не нравится. У кого какие мысли? Максимум, что можно сделать со стороны nginx'а - это логгировать сам факт соединения (и он таки логгируется на уровне info). Следует однако понимать, что отличить соединение, в котором уязвимость эксплуатируется, от обычного соединения с обычным запросом при правильном подходе к вопросу эксплуатации данной уязвимости - не представляется возможным вообще никак. Разве что запрошенный через heartbeat кускок данных будет достаточно большим, чтобы вызвать segmentation fault в OpenSSL. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: вопрос про heartbleed
On 04/09/14 13:41, Vladislav Shabanov wrote: В типовых настройках конфигов при таких вот битых обращениях ни одной строчки в лог не пишется. Что нужно сделать, чтобы в логах nginX были видны такие обращения? Если очень хочется знать о безуспешных аттаках, то лучше использовать что то типа SNORT. И про heartbleed он должен знать. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
