> On 29 Jan 2020, at 15:06, Maxim Dounin <mdou...@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-fo...@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 отменяет это. > В BoringSSL раньше всей этой фигни не было, и там всё работало из > коробки, без дополнительных приседаний. Закоммитили какую-то > аналогичную ерунду? https://boringssl.googlesource.com/boringssl/+/72912d2 -- Sergey Kandaurov _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
