ср, 27 июл. 2022 г. в 02:08, Maxim Dounin <mdounin@mdounin.ru>:

> Hello!
>
> On Tue, Jul 26, 2022 at 07:46:50PM +0500, Илья Шипицин wrote:
>
> > вт, 26 июл. 2022 г. в 19:33, Gena Makhomed <gmm@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-leave@nginx.org
>
_______________________________________________
nginx-ru mailing list -- nginx-ru@nginx.org
To unsubscribe send an email to nginx-ru-leave@nginx.org