ssl_prefer_server_ciphers
Anatoly Mikhailov
anatoly at sonru.com
Tue Sep 10 09:18:50 UTC 2013
On Sep 9, 2013, at 1:35 PM, Maxim Dounin <mdounin at mdounin.ru> 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
Подробная информация о списке рассылки nginx-ru