On Sep 10, 2013, at 10:18 AM, Anatoly Mikhailov <[email protected]> wrote:
> > On Sep 9, 2013, at 1:35 PM, Maxim Dounin <[email protected]> wrote: > >> Hello! >> >> On Mon, Sep 09, 2013 at 02:31:11PM +0300, Gena Makhomed wrote: >> >>> On 09.09.2013 13:06, Anton Yuzhaninov wrote: >>> >>>>> потому что при ssl_prefer_server_ciphers off; >>>>> nginx подвержен влиянию BEAST-атаки CVE-2011-3389. >>>> >>>> Без очень тщательного выбора того что и каком порядке указывать в >>>> ssl_ciphers это делать смысла мало. >>>> >>>> А что писать в ssl_ciphers вопрос не очень простой. >>>> >>>> На первом месте логично поставить AES-GCM, но он пока не поддерживается >>>> большинством браузеров. Да и на сервере для его нужен openssl 1.0.1 а во >>>> многих дистрибутивах используются более старые версии. >>> >>> ясно. а нельзя сделать так, чтобы если openssl версии 1.0.1, >>> то по-умолчанию в ssl_ciphers на первом месте стоял AES-GCM, >>> а если openssl более ранней версии, тогда лучшее из возможного: >>> >>> ssl_ciphers RC4:HIGH:!aNULL:!MD5:!kEDH; >> >> Если говорить о борьбе с BEAST'ом, то правильных решений два: >> >> 1) Решать проблему переходом на TLS 1.1+ (в том числе AES-CBC >> будет работать нормально). >> >> 2) Решать проблему на стороне клиента (собственно, все современные >> браузеры это делают). >> >> Использование RC4 - это костыль, заметно ухудшающий безопасность с >> остальных точек зрения. Его имело смысл использовать в момент >> появления BEAST-атаки, сейчас - скорее не имеет. >> >> Что до значения по умолчанию директивы ssl_ciphers, то оно выбрано >> так, чтобы обеспечить максимальную безопасность на длинном отрезке >> времени и требовать минимума изменений. >> >> Что до ssl_prefer_server_ciphers, то оно имеет смысл в случае >> использования конструкций вроде вышеописанного anti-BEAST решения. >> Включать же его при ssl_ciphers по умолчанию - особого смысла нет. >> > > Максим, насколько такая конфигурация сейчас актуальна и надежна? > > ssl_session_timeout 15m; > ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; > ssl_ciphers RC4:HIGH:!aNULL:!MD5; > ssl_prefer_server_ciphers on; > ssl_session_cache shared:SSL:10m; > > Данная конфигурация набирает 100/90/80/90 (Rating A) на Qualys SSL Labs. > > И второй вопрос, в плане _безопасности_ стоит обновляться > с Nginx 1.3.14 до последней стабильной версии? Обновление Nginx до последней стабильной версии в планах, но пока очень интересно узнать, насколько это критично в плане безопасности. > > > Анатолий > > >> [...] >> >>> может быть имеет смысл в документации к nginx написать рекомендацию, >>> чтобы пользователи после настройки ssl проверили свой сайт на >>> предмет уязвимостей на сайте https://www.ssllabs.com/ssltest/ ? >>> >>> и почитали SSL/TLS Deployment Best Practices https://www.ssllabs.com/ >>> >>> подозреваю, что многие пользователи считают, что nginx имеет дефолтовые >>> значения параметров такие, что он будет "secure by default" и они даже >>> не догадываются про все эти уязвимости и нюансы в настройке ssl в nginx. >> >> Почитать ssllabs.com - это завсегда полезно. :) >> >> В частности, сейчас там на голове висит ссылка на вот эту статью Ivan'а >> Ristic'а: >> >> RC4 in TLS is Broken: Now What? >> https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what >> >> А в тестах сейчас светится: >> >> BEAST attack: No longer rated; considered sufficiently mitigated client-side >> >> -- >> Maxim Dounin >> http://nginx.org/en/donation.html >> >> _______________________________________________ >> nginx-ru mailing list >> [email protected] >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > > _______________________________________________ > nginx-ru mailing list > [email protected] > http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ nginx-ru mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-ru
