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