ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ssl_prefer_server_ciphers



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 по умолчанию - особого смысла нет.

[...]

> может быть имеет смысл в документации к 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


 




Copyright © Lexa Software, 1996-2009.