Error log question

[Maxim Dounin]

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/