Re: ssl_prefer_server_ciphers

[Anatoly Mikhailov <anatoly@xxxxxxxxx>]

On Sep 10, 2013, at 10:18 AM, Anatoly Mikhailov <anatoly@xxxxxxxxx> wrote:

> 
> On Sep 9, 2013, at 1:35 PM, Maxim Dounin <mdounin@xxxxxxxxxx> 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
>> nginx-ru@xxxxxxxxx
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru