From arut на nginx.com Sun Jun 12 18:27:53 2022 From: arut на nginx.com (Roman Arutyunyan) Date: Sun, 12 Jun 2022 22:27:53 +0400 Subject: nginxQuic: =?utf-8?B?0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg?= =?utf-8?B?0L7RgiDRgdC10YDQstC10YDQsC4=?= In-Reply-To: <329E8710-1A56-4474-AAD1-11DD51C6BCBB@nginx.com> References: <1354362087.20220528013602@gmail.com> <1221274700.20220528120319@gmail.com> <1406949901.20220530152232@gmail.com> <329E8710-1A56-4474-AAD1-11DD51C6BCBB@nginx.com> Message-ID: <20220612182753.njmdypv5llychn3f@N00W24XTQX> Добрый день, On Mon, May 30, 2022 at 04:27:54PM +0400, Roman Arutyunyan wrote: > Добрый день, > > Да, я видел. спасибо. > > > On 30 May 2022, at 16:22, izorkin на gmail.com wrote: > > > > Добрый день Роман. > > > > Скинул ссылку с дампом на личную почту. > > Вероятно, что могло попасть в спам, т.к. предыдущее письмо тоже осталось без ответа > > > > > > -- > > С уважением, > > Izorkin mailto:izorkin на gmail.com > > > > _______________________________________________ > > nginx-ru mailing list -- nginx-ru на nginx.org > > To unsubscribe send an email to nginx-ru-leave на nginx.org > > ---- > Roman Arutyunyan > arut на nginx.com > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org Удалось выяснить следующее. Имеет место проблема на стороне Хрома. Если точнее, в гугловой библиотоке QUICHE. Проблемa триггерится комбинацией EarlyData + HelloRetryRequest. Если Хром отправил EarlyData, которую сервер проигнорировал, то далее клиент не шлет новый ClientHello в ответ на HelloRetryRequest т.к. зачем-то ждет подтверждения EarlyData. В итоге соединение зависает и таймаутится. ClientHello -> EarlyData -> (ignore) <- HelloRetryRequest (timeout) Самый простой способ обойти проблему - избежать отправки HelloRetryRequest. В рассматриваемом случае для этого достаточно было убрать из конфигурации nginx директиву ssl_ecdh_curve. Заткнуть это также можно и в QUICHE при помощи следующего патча: diff --git a/quiche/quic/core/quic_session.cc b/quiche/quic/core/quic_session.cc index d2976006..ad5c4d3c 100644 --- a/quiche/quic/core/quic_session.cc +++ b/quiche/quic/core/quic_session.cc @@ -2404,6 +2404,9 @@ bool QuicSession::RetransmitLostData() { return false; } } + if (connection()->encryption_level() == ENCRYPTION_ZERO_RTT) { + return true; + } while (!streams_with_pending_retransmission_.empty()) { if (!CanWriteStreamData()) { break; ---- Roman Arutyunyan arut на nginx.com From izorkin на gmail.com Sun Jun 12 18:35:48 2022 From: izorkin на gmail.com (izorkin на gmail.com) Date: Sun, 12 Jun 2022 21:35:48 +0300 Subject: =?utf-8?B?UmU6IG5naW54UXVpYzog0LzQtdC00LvQtdC90L3Ri9C5INC+0YLQstC10YIg0L7RgiDRgdC1?= =?utf-8?B?0YDQstC10YDQsC4=?= In-Reply-To: <20220612182753.njmdypv5llychn3f@N00W24XTQX> References: <1354362087.20220528013602@gmail.com> <1221274700.20220528120319@gmail.com> <1406949901.20220530152232@gmail.com> <329E8710-1A56-4474-AAD1-11DD51C6BCBB@nginx.com> <20220612182753.njmdypv5llychn3f@N00W24XTQX> Message-ID: <139205285.20220612213548@gmail.com> Здравствуйте, Роман. Спасибо за помощь в поиске и устранении проблемы! Отключение директивы ssl_ecdh_curve в Nginx помогло. Планируется ли делать баг-репорт в Chrome? Вы писали 12 июня 2022 г., 21:27:53: > Добрый день, > Удалось выяснить следующее. Имеет место проблема на стороне Хрома. Если > точнее, в гугловой библиотоке QUICHE. Проблемa триггерится комбинацией > EarlyData + HelloRetryRequest. Если Хром отправил EarlyData, которую сервер > проигнорировал, то далее клиент не шлет новый ClientHello в ответ на > HelloRetryRequest т.к. зачем-то ждет подтверждения EarlyData. В итоге > соединение зависает и таймаутится. ClientHello ->> EarlyData ->> (ignore) > <- HelloRetryRequest > (timeout) > Самый простой способ обойти проблему - избежать отправки HelloRetryRequest. > В рассматриваемом случае для этого достаточно было убрать из конфигурации > nginx директиву ssl_ecdh_curve. > Заткнуть это также можно и в QUICHE при помощи следующего патча: > diff --git a/quiche/quic/core/quic_session.cc b/quiche/quic/core/quic_session.cc > index d2976006..ad5c4d3c 100644 > --- a/quiche/quic/core/quic_session.cc > +++ b/quiche/quic/core/quic_session.cc > @@ -2404,6 +2404,9 @@ bool QuicSession::RetransmitLostData() { > return false; > } > } > + if (connection()->encryption_level() == ENCRYPTION_ZERO_RTT) { > + return true; > + } > while (!streams_with_pending_retransmission_.empty()) { > if (!CanWriteStreamData()) { > break; > ---- > Roman Arutyunyan > arut на nginx.com > _______________________________________________ > nginx-ru mailing list -- nginx-ru на nginx.org > To unsubscribe send an email to nginx-ru-leave на nginx.org -- С уважением, Izorkin mailto:izorkin на gmail.com From gmm на csdoc.com Fri Jun 17 17:20:46 2022 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 17 Jun 2022 20:20:46 +0300 Subject: =?UTF-8?B?0LTQuNGA0LXQutGC0LjQstCwIG1lbWNhY2hlZF9mb3JjZV9yYW5nZXM=?= Message-ID: <1123dc73-f729-7fa4-2796-91807e3d27fd@csdoc.com> Здравствуйте, All! В документации к nginx встречается упоминание про директиву memcached_force_ranges https://nginx.org/en/docs/http/ngx_http_memcached_module.html#memcached_force_ranges Однако, в исходниках nginx нет директивы memcached_force_ranges - похоже на то, что директиву из исходников nginx удалили, а документацию и файл CHANGES обновить забыли? nginx/src/http/modules/ngx_http_memcached_module.c /* the hardcoded values */ conf->upstream.force_ranges = 1; -- Best regards, Gena From mdounin на mdounin.ru Fri Jun 17 23:47:19 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Sat, 18 Jun 2022 02:47:19 +0300 Subject: =?koi8-r?B?xMnSxcvUydc=?= =?koi8-r?Q?=C1?= memcached_force_ranges In-Reply-To: <1123dc73-f729-7fa4-2796-91807e3d27fd@csdoc.com> References: <1123dc73-f729-7fa4-2796-91807e3d27fd@csdoc.com> Message-ID: Hello! On Fri, Jun 17, 2022 at 08:20:46PM +0300, Gena Makhomed wrote: > Здравствуйте, All! > > В документации к nginx встречается > упоминание про директиву memcached_force_ranges > > https://nginx.org/en/docs/http/ngx_http_memcached_module.html#memcached_force_ranges > > Однако, в исходниках nginx нет директивы memcached_force_ranges > - похоже на то, что директиву из исходников nginx удалили, > а документацию и файл CHANGES обновить забыли? > > nginx/src/http/modules/ngx_http_memcached_module.c > /* the hardcoded values */ > conf->upstream.force_ranges = 1; Спасибо, это ошибка документации (в CHANGES и коде такой директивы никогда не было). -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Jun 20 13:25:13 2022 From: nginx-forum на forum.nginx.org (grey) Date: Mon, 20 Jun 2022 09:25:13 -0400 Subject: =?UTF-8?Q?=D0=A1=D0=B0=D0=B9=D1=82=20=D0=BE=D1=82=D0=BA=D1=80=D1=8B?= =?UTF-8?Q?=D0=B2=D0=B0=D0=B5=D1=82=D1=81=D1=8F=20=D0=BF=D0=BE=20=D0?= =?UTF-8?Q?=B8=D0=BC=D0=B5=D0=BD=D0=B8=20=D0=BF=D0=BE=D0=B4=D0=B4=D0?= =?UTF-8?Q?=BE=D0=BC=D0=B5=D0=BD=D0=B0,=20=D0=B0=20=D0=BD=D0=B5=20=D0?= =?UTF-8?Q?=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD?= Message-ID: <608d67cde758d0126668e8bb47d1f9a3.NginxMailingListRussian@forum.nginx.org> Привет. Че-то я туплю. Пересмотрел конфиги и документацию не один раз, но ошибку не вижу. Есть основной сайт, который должен открываться только по адресу httpS://site.ru, но при этом по адресу http://beta.site.ru должна работать так сказать тестовая версия сайта без шифрования. Суть проблемы – почему-то при заходе по адресу httpS://beta.site.ru открывается основная версия сайта. Почему - понять не могу. По адресу http://beta.site.ru – все ок. Конфиг: # по умолчанию server { listen 80 default_server; server_name 1.2.3.4; allow 127.0.0.1; deny all; } # версия для тестов server { listen 80; server_name beta.site.ru ; … } # редирект с http на https server { listen 80; server_name site.ru; access_log off; return 301 https://site.ru$request_uri; } # редирект с www на non-www server { listen 443 ssl; # ssl_certificate domain.crt; # ssl_certificate_key domain-key.txt; server_name www.site.ru; access_log off; rewrite ^(.*)$ https://site.ru$1 permanent; } # основная версия сайта server { listen 443 ssl http2; server_name site.ru ; … } Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294517,294517#msg-294517 From nginx-forum на forum.nginx.org Tue Jun 21 01:11:04 2022 From: nginx-forum на forum.nginx.org (oradba25) Date: Mon, 20 Jun 2022 21:11:04 -0400 Subject: =?UTF-8?Q?Re:=20=D0=A1=D0=B0=D0=B9=D1=82=20=D0=BE=D1=82=D0=BA=D1=80?= =?UTF-8?Q?=D1=8B=D0=B2=D0=B0=D0=B5=D1=82=D1=81=D1=8F=20=D0=BF=D0=BE?= =?UTF-8?Q?=20=D0=B8=D0=BC=D0=B5=D0=BD=D0=B8=20=D0=BF=D0=BE=D0=B4=D0?= =?UTF-8?Q?=B4=D0=BE=D0=BC=D0=B5=D0=BD=D0=B0,=20=D0=B0=20=D0=BD=D0=B5?= =?UTF-8?Q?=20=D0=B4=D0=BE=D0=BB=D0=B6=D0=B5=D0=BD?= In-Reply-To: <608d67cde758d0126668e8bb47d1f9a3.NginxMailingListRussian@forum.nginx.org> References: <608d67cde758d0126668e8bb47d1f9a3.NginxMailingListRussian@forum.nginx.org> Message-ID: <2303011cd1e47296761d12f3e37a57a4.NginxMailingListRussian@forum.nginx.org> Т.к. server_name beta.site.ru среди серверов, слушающих 443 не найдено, используется дефолтовый сервер для 443, в данном случае www.site.ru, ну и далее редирект Нужно завести сервер listen 443 ssl default_server и там уже решать, что делать с такими именами. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294517,294533#msg-294533 From pluknet на nginx.com Tue Jun 21 09:42:29 2022 From: pluknet на nginx.com (Sergey Kandaurov) Date: Tue, 21 Jun 2022 13:42:29 +0400 Subject: =?utf-8?B?UmU6INC00LjRgNC10LrRgtC40LLQsCBtZW1jYWNoZWRfZm9yY2Vf?= =?utf-8?B?cmFuZ2Vz?= In-Reply-To: <1123dc73-f729-7fa4-2796-91807e3d27fd@csdoc.com> References: <1123dc73-f729-7fa4-2796-91807e3d27fd@csdoc.com> Message-ID: <162D9219-3103-4D0E-A43A-8B2B9E301DB5@nginx.com> > On 17 Jun 2022, at 21:20, Gena Makhomed wrote: > > Здравствуйте, All! > > В документации к nginx встречается > упоминание про директиву memcached_force_ranges > > https://nginx.org/en/docs/http/ngx_http_memcached_module.html#memcached_force_ranges > > Однако, в исходниках nginx нет директивы memcached_force_ranges > - похоже на то, что директиву из исходников nginx удалили, > а документацию и файл CHANGES обновить забыли? > > nginx/src/http/modules/ngx_http_memcached_module.c > /* the hardcoded values */ > conf->upstream.force_ranges = 1; Документацию поправили, спасибо. -- Sergey Kandaurov From mdounin на mdounin.ru Tue Jun 21 17:03:19 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Jun 2022 20:03:19 +0300 Subject: nginx-1.23.0 Message-ID: Изменения в nginx 1.23.0 21.06.2022 *) Изменение во внутреннем API: теперь строки заголовков представлены связными списками. *) Изменение: теперь nginx объединяет произвольные строки заголовков с одинаковыми именами при отправке на FastCGI-, SCGI- и uwsgi-бэкенды, в методе $r->header_in() модуля ngx_http_perl_module, и при доступе через переменные "$http_...", "$sent_http_...", "$sent_trailer_...", "$upstream_http_..." и "$upstream_trailer_...". *) Исправление: если в заголовке ответа бэкенда было несколько строк "Vary", при кэшировании nginx учитывал только последнюю из них. *) Исправление: если в заголовке ответа бэкенда было несколько строк "WWW-Authenticate" и использовался перехват ошибок с кодом 401 от бэкенда или директива auth_request, nginx пересылал клиенту только первую из этих строк. *) Изменение: уровень логгирования ошибок SSL "application data after close notify" понижен с уровня crit до info. *) Исправление: соединения могли зависать, если nginx был собран на Linux 2.6.17 и новее, а использовался на системах без поддержки EPOLLRDHUP, в частности, на системах с эмуляцией epoll; ошибка появилась в 1.17.5. Спасибо Marcus Ball. *) Исправление: nginx не кэшировал ответ, если строка заголовка ответа "Expires" запрещала кэширование, а последующая строка заголовка "Cache-Control" разрешала кэширование. -- Maxim Dounin http://nginx.org/ From nginx-forum на forum.nginx.org Mon Jun 27 19:24:48 2022 From: nginx-forum на forum.nginx.org (edo1) Date: Mon, 27 Jun 2022 15:24:48 -0400 Subject: =?UTF-8?Q?=D0=BF=D0=B0=D1=80=D0=B0=D0=BB=D0=BB=D0=B5=D0=BB=D1=8C=D0?= =?UTF-8?Q?=BD=D1=8B=D0=B5=20=D1=81=D0=B5=D1=80=D1=82=D0=B8=D1=84=D0?= =?UTF-8?Q?=B8=D0=BA=D0=B0=D1=82=D1=8B=20ECDSA/RSA=20=D0=B8=20@SECLEVEL?= Message-ID: Дано: nginx 1.23 (сборка под bullseye с nginx.org), openssl 1.1.1n (из debian) два сертификата от LE, RSA и P-256. testssl.sh Нужно сделать, чтобы старые клиенты, умеющие только TLSc1/RSA, могли подключаться. Запускаем testssl.sh, TLSv1 и 1.1 не работают (только 1.2): SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 offered (deprecated) TLS 1.1 offered (deprecated) TLS 1.2 offered (OK) TLS 1.3 not offered and downgraded to a weaker protocol Убираем один из сертификатов — TLSv1 появляется, с двумя — только 1.2 Идём, например, на https://ssl-config.mozilla.org/#server=nginx&version=1.23&config=old&openssl=1.1.1n&hsts=false&ocsp=false&guideline=5.6 прописываем ssl_ciphers оттуда. Не помогает. Добавляем в конец списка шифров :@SECLEVEL=0 TLSv1 начинает работать. Решил редуцировать пример, дошёл до такого: a. ssl_ciphers AES128-SHA; TLSv1 работает b. ssl_ciphers AES128-SHA:ECDHE-ECDSA-AES128-SHA; TLSv1 работает c. ssl_ciphers ECDHE-ECDSA-AES128-SHA:AES128-SHA; TLSv1 НЕ работает d. ssl_ciphers ECDHE-ECDSA-AES128-SHA256:AES128-SHA; TLSv1 работает e. ssl_ciphers ECDHE-ECDSA-AES128-SHA:AES128-SHA:@SECLEVEL=0; TLSv1 работает :@SECLEVEL=0 прописать недолго, тем более, что, если я ничего не путаю, с переходом на openssl3 так и так придётся это делать; но неконсистентность поведения удивила. это вообще баг или фича? ) за десять минут просмотра кода нжинкса возникло ощущение, что дело не в нём, а так срабатывают какие-то эвристики в openssl. код openssl пока не смотрел. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294596,294596#msg-294596 From mdounin на mdounin.ru Tue Jun 28 23:26:15 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 29 Jun 2022 02:26:15 +0300 Subject: =?koi8-r?B?0MHSwczMxczYztnFINPF0tTJ?= =?koi8-r?B?xsnLwdTZIEVDRFNBL1JTQSDJ?= @SECLEVEL In-Reply-To: References: Message-ID: Hello! On Mon, Jun 27, 2022 at 03:24:48PM -0400, edo1 wrote: > Дано: > nginx 1.23 (сборка под bullseye с nginx.org), openssl 1.1.1n (из debian) > два сертификата от LE, RSA и P-256. > testssl.sh > > Нужно сделать, чтобы старые клиенты, умеющие только TLSc1/RSA, могли > подключаться. > Запускаем testssl.sh, TLSv1 и 1.1 не работают (только 1.2): > SSLv2 not offered (OK) > SSLv3 not offered (OK) > TLS 1 offered (deprecated) > TLS 1.1 offered (deprecated) > TLS 1.2 offered (OK) > TLS 1.3 not offered and downgraded to a weaker protocol > > Убираем один из сертификатов — TLSv1 появляется, с двумя — только 1.2 (Just in case, в приведённом фрагменте вывода testssl.sh как раз видно, что TLSv1 и TLSv1.1 работают.) > Идём, например, на > https://ssl-config.mozilla.org/#server=nginx&version=1.23&config=old&openssl=1.1.1n&hsts=false&ocsp=false&guideline=5.6 > прописываем ssl_ciphers оттуда. > Не помогает. > > Добавляем в конец списка шифров :@SECLEVEL=0 > TLSv1 начинает работать. > > Решил редуцировать пример, дошёл до такого: > a. ssl_ciphers AES128-SHA; > TLSv1 работает > > b. ssl_ciphers AES128-SHA:ECDHE-ECDSA-AES128-SHA; > TLSv1 работает > > c. ssl_ciphers ECDHE-ECDSA-AES128-SHA:AES128-SHA; > TLSv1 НЕ работает > > d. ssl_ciphers ECDHE-ECDSA-AES128-SHA256:AES128-SHA; > TLSv1 работает > > e. ssl_ciphers ECDHE-ECDSA-AES128-SHA:AES128-SHA:@SECLEVEL=0; > TLSv1 работает > > > :@SECLEVEL=0 прописать недолго, тем более, что, если я ничего не путаю, с > переходом на openssl3 так и так придётся это делать; но неконсистентность > поведения удивила. > это вообще баг или фича? ) > > за десять минут просмотра кода нжинкса возникло ощущение, что дело не в нём, > а так срабатывают какие-то эвристики в openssl. > код openssl пока не смотрел. Debian по умолчанию использует в настройках OpenSSL SECLEVEL=2, что приводит к тому, что ECDHE-ECDSA-AES128-SHA не работает из-за использования SHA1 в процессе key exchange. Ибо для SECLEVEL=2 требуется минимум 112 бит криптостойкости, а SHA1 обеспечивает максимум 80 (а с учётом атак - и того меньше, что и отражено в OpenSSL 3.0). От этого у вас TLSv1 и ломается без SECLEVEL=0 (для OpenSSL 1.1.1 хватит и SECLEVEL=1). При этом AES128-SHA работает, т.к. в процессе key exchange SHA1 не используется. Вот тут, например, об этом подробнее: https://github.com/openssl/openssl/issues/18194 При этом OpenSSL сначала выбирает, какой шифр использовать, а потом уже ломается из-за ограничений на security level используемого алгоритма подписи, так что наличие других работающих шифров на ситуацию не влияет. (Кроме того, в случае TLSv1.2 клиент может, и обычно передаёт, дополнительные поддерживаемые алгоритмы подписи, и если он это сделал - шифр ECDHE-ECDSA-AES128-SHA будет работать.) -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Tue Jun 28 23:45:53 2022 From: nginx-forum на forum.nginx.org (edo1) Date: Tue, 28 Jun 2022 19:45:53 -0400 Subject: =?UTF-8?Q?Re:=20=D0=BF=D0=B0=D1=80=D0=B0=D0=BB=D0=BB=D0=B5=D0=BB=D1?= =?UTF-8?Q?=8C=D0=BD=D1=8B=D0=B5=20=D1=81=D0=B5=D1=80=D1=82=D0=B8=D1?= =?UTF-8?Q?=84=D0=B8=D0=BA=D0=B0=D1=82=D1=8B=20ECDSA/RSA=20=D0=B8=20@SE?= =?UTF-8?Q?CLEVEL?= In-Reply-To: References: Message-ID: > (Just in case, в приведённом фрагменте вывода testssl.sh как раз > видно, что TLSv1 и TLSv1.1 работают.) всё-таки не работает, извините, не то скопировал, заметил уже после отправки. должно было быть: SSLv2 not offered (OK) SSLv3 not offered (OK) TLS 1 not offered TLS 1.1 not offered TLS 1.2 offered (OK) TLS 1.3 not offered and downgraded to a weaker protocol > Debian по умолчанию использует в настройках OpenSSL SECLEVEL=2, > что приводит к тому, что ECDHE-ECDSA-AES128-SHA не работает из-за > использования SHA1 в процессе key exchange. Ибо для SECLEVEL=2 > требуется минимум 112 бит криптостойкости, а SHA1 обеспечивает > максимум 80 (а с учётом атак - и того меньше, что и отражено в > OpenSSL 3.0). От этого у вас TLSv1 и ломается без SECLEVEL=0 но почему при SECLEVEL=2 наличие/отстутсвие поддержки TLSv1 зависит от того, в каком порядке указаны шифры? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294596,294606#msg-294606 From mdounin на mdounin.ru Wed Jun 29 00:16:35 2022 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 29 Jun 2022 03:16:35 +0300 Subject: =?koi8-r?B?0MHSwczMxczYztnFINPF0tTJ?= =?koi8-r?B?xsnLwdTZIEVDRFNBL1JTQSDJ?= @SECLEVEL In-Reply-To: References: Message-ID: Hello! On Tue, Jun 28, 2022 at 07:45:53PM -0400, edo1 wrote: > > Debian по умолчанию использует в настройках OpenSSL SECLEVEL=2, > > что приводит к тому, что ECDHE-ECDSA-AES128-SHA не работает из-за > > использования SHA1 в процессе key exchange. Ибо для SECLEVEL=2 > > требуется минимум 112 бит криптостойкости, а SHA1 обеспечивает > > максимум 80 (а с учётом атак - и того меньше, что и отражено в > > OpenSSL 3.0). От этого у вас TLSv1 и ломается без SECLEVEL=0 > > но почему при SECLEVEL=2 наличие/отстутсвие поддержки TLSv1 зависит от того, > в каком порядке указаны шифры? Вероятнее всего у вас включена опция ssl_prefer_server_ciphers, и соответственно OpenSSL выбирает и пытается использовать тот шифр, который указан первым. И ломается, если это ECDHE-ECDSA-AES128-SHA. Если опцию выключить - будет использоваться тот шифр, который предпочитает клиент, и ломаться будет в зависимости от предпочтений клиента (то есть примерно всегда для клиентов, поддерживающих ECDSA). -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Wed Jun 29 00:30:30 2022 From: nginx-forum на forum.nginx.org (edo1) Date: Tue, 28 Jun 2022 20:30:30 -0400 Subject: =?UTF-8?Q?Re:=20=D0=BF=D0=B0=D1=80=D0=B0=D0=BB=D0=BB=D0=B5=D0=BB=D1?= =?UTF-8?Q?=8C=D0=BD=D1=8B=D0=B5=20=D1=81=D0=B5=D1=80=D1=82=D0=B8=D1?= =?UTF-8?Q?=84=D0=B8=D0=BA=D0=B0=D1=82=D1=8B=20ECDSA/RSA=20=D0=B8=20@SE?= =?UTF-8?Q?CLEVEL?= In-Reply-To: References: Message-ID: <89da174b0c3cc0fade54e885287b524d.NginxMailingListRussian@forum.nginx.org> да, спасибо, я как раз писал, что уже понял. при таком конфиге сервера: ssl_protocols TLSv1; ssl_ciphers ECDHE-ECDSA-AES128-SHA:AES128-SHA; ssl_prefer_server_ciphers on; если запускаем openssl s_client -tls1 то от клиента приходит запрос, в котором есть шифр ECDHE-ECDSA-AES128-SHA, сервер выбирает его, но не может использовать из-за SECLEVEL, выдаёт такой ответ: Transport Layer Security TLSv1 Record Layer: Alert (Level: Fatal, Description: Internal Error) Content Type: Alert (21) Version: TLS 1.0 (0x0301) Length: 2 Alert Message Level: Fatal (2) Description: Internal Error (80) если же мы запускаем openssl s_client -cipher AES128-SHA -tls1 то сервер соглашается на AES128-SHA и всё работает. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294596,294609#msg-294609 From nginx-forum на forum.nginx.org Wed Jun 29 14:33:30 2022 From: nginx-forum на forum.nginx.org (Rasin) Date: Wed, 29 Jun 2022 10:33:30 -0400 Subject: Requests to the new URL Message-ID: Добрый день. Подскажите пожалуйста, есть софт, в докере поднятый. Работает только с location / { proxy_pass http://127.0.0.1:3333; ... } Хочу сделать чтобы открывался location /soft { proxy_pass http://127.0.0.1:3333; ... } Но с последним выдаёт, что не может найти скрипты и прочее. Я так понимаю он посылает заголовок, который непонятен софту. Что необходимо сделать, куда копнуть, подскажите пожалуйста. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,294617,294617#msg-294617