ср, 27 июл. 2022 г. в 02:08, Maxim Dounin <mdou...@mdounin.ru>:
> Hello! > > On Tue, Jul 26, 2022 at 07:46:50PM +0500, Илья Шипицин wrote: > > > вт, 26 июл. 2022 г. в 19:33, Gena Makhomed <g...@csdoc.com>: > > > > > On 26.07.2022 16:59, Maxim Dounin wrote: > > > > > > >>>> >> 2022/07/23 16:26:33 [alert] 849481#849481: *8078448 could not > > > allocate > > > >>>> >> new session in SSL session shared cache "le_nginx_SSL" while > SSL > > > >>>> >> handshaking, client: 175.156.80.121, server: 0.0.0.0:443 > > > > > > [...] > > > > > > >> Если не будет в логах ошибок - каким образом тогда пользователь > > > >> сможет понять, что размер кэша для сессий SSL слишком маленький? > > > > > > > Точно так же, как и сейчас - по статистике повторного > > > > использования сессий, других способов нет. Обсуждаемое сообщение > > > > об ошибке возникает тогда и только тогда, когда не удаётся > > > > выделить память после удаления одной из старых сессий. Такое > > > > может происходить, например, если удалённая сессия заметно > > > > отличается по размеру от создаваемой, и попадает в другой диапазон > > > > выделений slab-аллокатора. > > > > > > А каким образом эту статистику повторного использования сессий > > > можно получить? Для этого надо писать в лог значение переменной > > > $ssl_session_reused потом скриптом вычислять процент запросов, > > > > > > > и да, и нет. действительно, сессию можно логировать, но это не значит, > что > > сессия была использована. > > сессии это устаревший механизм, сейчас 100% современных браузеров > > используют tls tickets > > Когда я последний раз проверял (полгода назад в рамках ticket > #1892, https://trac.nginx.org/nginx/ticket/1892) - в тикеты не > умел Safari. > > Возможно, имеет смысл таки добраться до ticket #927 > (https://trac.nginx.org/nginx/ticket/927), и сделать, чтобы reuse > сессий через тикеты можно было легко отличить от такового через > кэш сессий. Сейчас использование тикетов от кэша сессий > отличается по отсутствию $ssl_session_id после первого хендшейка - > что в принципе позволяет их отличать, но делать это, скажем так, > неудобно. > > [...] > > > из того, с чем реально сталкивались - ротация тикетов и сессий. есть два > > пограничных подхода > > > > а) никогда не делать релоад. (сессии вечные, безопасники несчастны) > > б) иногда делать релоад. сессии ротируются, но по вам со всей дури > > прилетает cpu storm на полных хендшейках > > > > как-то управляемо ротировать сессии, без привязки к релоаду, было бы > > идеально > > Проблема не в "сессии вечные", проблема, о которой любят плакаться > безопасники - это то, что ключ шифрования тикетов меняется только > при релоаде. Соответственно если кто-нибудь сможет получить этот > ключ - он сможет расшифровать записанный трафик после последнего > релоада. Ключ - симметричный ключ на 256-бит, то есть > единственная реальная возможность его получить - это доступ к > оперативной памяти работающего сервера. > > Если это действительно проблема, то сейчас есть два работающих > варианта её решения, не приводящих к увеличению числа полных > хендшейков: > > - Выключить тикеты, и использовать кэш сессий. В этом случае > сессионные ключи будут удаляться из памяти сервера по мере > перезаписи другими сессиями, и соответственно возможность > расшифровки ранее записанного трафика ограничена последними > сессиями. > > - Использовать несколько ключей для шифрования тикетов, заданных > через директиву ssl_session_ticket_key, и периодически их > вращать (добавлять новый и убирать самый старый). В этом случае > ключи для шифрования тикетов обновляются с любой удобной частотой, > а количество полных хендшейков не увеличивается (так как для > шифрования новых тикетов используется первый ключ, и старые ключи > становятся не нужны после истечения ssl_session_timeout с того > момента, как ключ перестал быть первым). > я почему-то был уверен, что ключ может быть только один. надо будет затестить несколько ключей > > В планах - сделать-таки автоматическое вращение ключей в памяти, > но пока этого нет. В частности потому, что модель угроз, в > которой это важно - выглядит немного оторванной от реальности. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list -- nginx-ru@nginx.org > To unsubscribe send an email to nginx-ru-le...@nginx.org >
_______________________________________________ nginx-ru mailing list -- nginx-ru@nginx.org To unsubscribe send an email to nginx-ru-le...@nginx.org
