Re: ssl_prefer_server_ciphers

[Anatoly Mikhailov <anatoly@xxxxxxxxx>]

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 написать рекомендацию,
>> чтобы пользователи после настройки 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