Re: SSL Early Data поддерживает только первый worker?

[Илья Шипицин]

правка от 2017 года, просто не замечали ?

(или я что-то не понимаю, и проявилось только спустя 2.5 года)

пн, 3 февр. 2020 г. в 20:40, Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>
> On Mon, Feb 03, 2020 at 05:37:55PM +0300, Sergey Kandaurov wrote:
>
> >
> > > On 29 Jan 2020, at 15:06, Maxim Dounin <mdounin на mdounin.ru> wrote:
> > >
> > > Hello!
> > >
> > > On Wed, Jan 29, 2020 at 01:40:44PM +0300, Sergey Kandaurov wrote:
> > >
> > >>
> > >>> On 29 Jan 2020, at 06:20, Ilya Evseev <nginx-forum на forum.nginx.org>
> wrote:
> > >>>
> > >>> Есть Nginx 1.17.8, собран со свежей BoringSSL stable.
> > >>> Запущен на Linux kernel 5.4.10:
> > >>>
> > >>> [..]
> > >>> SSL в Nginx'e настроен так:
> > >>>
> > >>> ssl_dhparam /etc/pki/tls/private/dhparam2048.pem;
> > >>> ssl_session_timeout 1h;
> > >>> ssl_session_cache shared:SSL:10m;
> > >>> ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
> > >>> ssl_ciphers
> > >>>
> kEECDH+ECDSA+AESGCM:kEECDH+AES128:kEECDH:kEDH:-3DES:kRSA+AES128:kEDH+3DES:DES-CBC3-SHA:!RC4:!aNULL:!eNULL:!MD5:!EXPORT:!LOW:!SEED:!CAMELLIA:!IDEA:!PSK:!SRP:!SSLv2;
> > >>> ssl_prefer_server_ciphers on;
> > >>> ssl_early_data on;
> > >>>
> > >>> Проверяю, поддерживает ли он SSL early data:
> > >>>
> > >>> docker run --rm -it nablac0d3/sslyze --early_data 1.2.3.4
> > >>>
> > >>> Результат:
> > >>>
> > >>> - Если в nginx'e настроен "worker_processes 1;", sslyze всегда
> возвращает
> > >>> "Suppported - Server accepted early data"
> > >>> - Если воркеров больше одного, "Supported" начинает возвращаться не
> всегда.
> > >>> Чем больше воркеров - тем чаще возвращается "Not supported".
> > >>>
> > >>> Т.е. выглядит так, будто SSL Early Data поддерживает только первый
> воркер.
> > >>>
> > >>> Этому есть какое-то объяснение?
> > >>
> > >> Тут дело не в early data, а в том что BoringSSL по какой-то причине не
> > >> разрешает сохранять тикеты в session cache.  В итоге сессия
> восстанавливается
> > >> только по тикету из того же рабочего процесса, который его породил.
> > >> Это означает, что восстановление сессий из кеша (в т.ч. shared) не
> будет
> > >> работать и для TLSv1.2 со включёнными по умолчанию тикетами.
> > >
> > > Э.  Тикеты - восстанавливаются по ключу, который задаётся в
> > > master-процессе и соответственно одинаковый во всех рабочих
> > > процессах.  То есть восстановление тикетов должно работать вне
> > > зависимости от session cache, и работать всегда.
> >
> > И действительно.  В BoringSSL ключи создаются не во время вызова
> > SSL_CTX_new() в master-процессе, а по необходимости при работе
> > с тикетами, где таким образом каждый рабочий процесс получает
> > уникальное значение в соответствующих структурах SSL_CTX.  Это
> > препятствует восстановлению сессии по тикету в другом процессе.
> > Помимо этого, применяется механизм автовращания ключей через
> > SSL_DEFAULT_TICKET_KEY_ROTATION_INTERVAL секунд после создания,
> > но здесь это не столь важно.
> >
> > Использование коллбека SSL_CTX_set_tlsext_ticket_key_cb отменяет это.
>
> [...]
>
> > https://boringssl.googlesource.com/boringssl/+/72912d2
>
> Ну э, молодцы.  То есть доступный прямо сейчас workaround для
> BoringSSL - задать ssl_session_ticket_key явно.  Что, конечно,
> делает прямо противоположное тому, что было целью авторов данного
> изменения - вместо вращения ключей при каждом чтении конфигурации,
> которое было раньше, и в пару к которому хотелось сделать
> автовращение, мы получаем вечно лежащий на диске ключ.
>
> Возможно, стоит подумать о том, чтобы явно отключить всю эту
> красоту для BoringSSL, явно задав случайные ключи при чтении
> конфигурации, скажем, с помощью SSL_CTX_set_tlsext_ticket_keys().
>
> Ну или сделать, наконец, автовращение ключей на уровне nginx'а, с
> синхронизацией ключей между рабочими процессами через разделяемую
> память.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-ru mailing list
> nginx-ru на nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20200203/849e68ec/attachment-0001.htm>