From nginx-forum на forum.nginx.org Mon Jan 6 20:43:44 2020 From: nginx-forum на forum.nginx.org (RuslanValitov) Date: Mon, 06 Jan 2020 15:43:44 -0500 Subject: =?UTF-8?B?V2ViaW5hciDQvdCwINCx0LDQt9C1IE5naW54?= Message-ID: Всем доброго времени суток. Подскажите как реализовать систему для проведения вебинаров для 10-100 участников на базе nginx? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286661,286661#msg-286661 From nginx-forum на forum.nginx.org Thu Jan 9 07:53:53 2020 From: nginx-forum на forum.nginx.org (andrei_abc) Date: Thu, 09 Jan 2020 02:53:53 -0500 Subject: =?UTF-8?B?0JrQsNC6INC40YHQv9C+0LvRjNC30L7QstCw0YLRjCDQv9C10YDQtdC80LXQvdC9?= =?UTF-8?B?0YPRjiB1cHN0cmVhbSBodHRwIHggYXV0aCByZXF1ZXN0IHVzZXI=?= Message-ID: у меня есть конфигурация nignx v1.17.6 c oauth2_proxy v4.1.0-12-g7663565 авторизация проходит через Azure. server { listen 443 ssl; server_name 127.0.0.1; ssl_certificate ../nginx-selfsigned.crt; ssl_certificate_key ../nginx-selfsigned.key; location /oauth2/ { proxy_pass http://127.0.0.1:4180; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Scheme $scheme; proxy_set_header X-Auth-Request-Redirect $request_uri; } location = /oauth2/auth { proxy_pass http://127.0.0.1:4180; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Scheme $scheme; # nginx auth_request includes headers but not body proxy_set_header Content-Length ""; proxy_pass_request_body off; } location / { auth_request /oauth2/auth; error_page 401 = /oauth2/sign_in; auth_request_set $user $upstream_http_x_auth_request_user; auth_request_set $email $upstream_http_x_auth_request_email; proxy_set_header X-User $user; proxy_set_header X-Email $email; auth_request_set $auth_cookie $upstream_http_set_cookie; add_header Set-Cookie $auth_cookie; auth_request_set $auth_cookie_name_upstream_1 $upstream_cookie_auth_cookie_name_1; add_header X-Debug "$user"; add_header X-Debug2 "$email"; set $username ocadmin; proxy_pass http://127.0.0.1:5601; proxy_set_header Authorization "Basic secret:secret"; if ($user = "test на mail.ru") { set $username user1; } proxy_set_header es-security-runas-user $username; } } переменную user и email в header видно, и если она ровна test на mail.ru, if все равно не выполняется Кто подскажет в чем может быть проблема? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286671,286671#msg-286671 From mdounin на mdounin.ru Thu Jan 9 13:27:09 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 9 Jan 2020 16:27:09 +0300 Subject: =?UTF-8?B?UmU6INCa0LDQuiDQuNGB0L/QvtC70YzQt9C+0LLQsNGC0Ywg0L/QtdGA0LXQvNC1?= =?UTF-8?B?0L3QvdGD0Y4gdXBzdHJlYW0gaHR0cCB4IGF1dGggcmVxdWVzdCB1c2Vy?= In-Reply-To: References: Message-ID: <20200109132709.GX12894@mdounin.ru> Hello! On Thu, Jan 09, 2020 at 02:53:53AM -0500, andrei_abc wrote: > у меня есть конфигурация nignx v1.17.6 c oauth2_proxy v4.1.0-12-g7663565 > авторизация проходит через Azure. [...] > location / { > auth_request /oauth2/auth; > error_page 401 = /oauth2/sign_in; > > auth_request_set $user > $upstream_http_x_auth_request_user; > auth_request_set $email > $upstream_http_x_auth_request_email; > proxy_set_header X-User $user; > proxy_set_header X-Email $email; > auth_request_set $auth_cookie $upstream_http_set_cookie; > add_header Set-Cookie $auth_cookie; > > auth_request_set $auth_cookie_name_upstream_1 > $upstream_cookie_auth_cookie_name_1; > > add_header X-Debug "$user"; > add_header X-Debug2 "$email"; > > set $username ocadmin; > > proxy_pass http://127.0.0.1:5601; > > proxy_set_header Authorization "Basic secret:secret"; > > > if ($user = "test на mail.ru") { > set $username user1; > } > > proxy_set_header es-security-runas-user $username; > > } > > } > > переменную user и email в header видно, и если она ровна test на mail.ru, if > все равно не выполняется > Кто подскажет в чем может быть проблема? Проблема в том, что if - выполняется при выборе конфигурации, см. описание модуля rewrite тут: http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html Соответственно к тому моменту, как выбрана конфигурация и началась обработка запроса в рамках "location /" - в частности, выполнился auth_request - директива if уже давно отработала, и пытаться в ней использовать результаты auth_request - бессмысленно. В данном случае правильно использовать map, как-то так (на уровне http): map $user $username { default ocadmin; test на mail.ru user1; } Ну и соответственно убрать "set $username ..." и "if ($user ...". -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Fri Jan 10 02:07:17 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2020 04:07:17 +0200 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ Message-ID: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Здравствуйте, All! SSL Configuration Generator https://ssl-config.mozilla.org/ Предлагает для конфигурации Intermediate (General-purpose servers with a variety of clients, recommended for almost all systems) в конфиге nginx включать ssl_dhparam: # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam.pem ssl_dhparam /path/to/dhparam.pem; Причем, содержимое файла, куда указывает директива ssl_dhparam будет одинаковым у всех, кто воспользуется этим советом. (!!!) И прописывать в директиву ssl_ciphers в том числе и DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384. Не совсем понятен смысл этого действия. Начиная с версии 1.11.0 (вышла 24 мая 2016 года) для того чтобы включить поддержку DHE-шифров - необходимо явно задавать директиву ssl_dhparam. Но если посмотреть по результатам https://www.ssllabs.com/ssltest/ включение или выключение ssl_dhparam практически ни на что не влияет. Более широкой поддержки со стороны клиентов не появляется, единственное изменение, которое удалось заметить - это то, что IE 11 начинает использовать DHE вместо ECDHE. И на этом всё. Рекомендация сайта https://ssl-config.mozilla.org/ является разумной? ssl_dhparam действительно лучше будет в 2020 включать в конфиге nginx? Или же создатели сайта https://ssl-config.mozilla.org/ ошибаются, и ssl_dhparam лучше не включать и DHE-шифры из директивы ssl_ciphers лучше будет убрать? Если создатели сайта https://ssl-config.mozilla.org/ ошибаются, то осознать свою ошибку они смогут наверное только после того, как им об этом напишет кто-то из разработчиков nginx? -- Best regards, Gena From chipitsine на gmail.com Fri Jan 10 04:37:28 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 10 Jan 2020 09:37:28 +0500 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Message-ID: пт, 10 янв. 2020 г. в 07:07, Gena Makhomed : > Здравствуйте, All! > > SSL Configuration Generator https://ssl-config.mozilla.org/ > > Предлагает для конфигурации Intermediate (General-purpose servers with a > variety of clients, recommended for almost all systems) > в конфиге nginx включать ssl_dhparam: > > # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam.pem > ssl_dhparam /path/to/dhparam.pem; > > Причем, содержимое файла, куда указывает директива ssl_dhparam > будет одинаковым у всех, кто воспользуется этим советом. (!!!) > > И прописывать в директиву ssl_ciphers > в том числе и DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384. > > Не совсем понятен смысл этого действия. > > Начиная с версии 1.11.0 (вышла 24 мая 2016 года) для того чтобы включить > поддержку DHE-шифров - необходимо явно задавать директиву ssl_dhparam. > > Но если посмотреть по результатам https://www.ssllabs.com/ssltest/ > включение или выключение ssl_dhparam практически ни на что не влияет. > > Более широкой поддержки со стороны клиентов не появляется, > единственное изменение, которое удалось заметить - это то, > что IE 11 начинает использовать DHE вместо ECDHE. И на этом всё. > > Рекомендация сайта https://ssl-config.mozilla.org/ является разумной? > ssl_dhparam действительно лучше будет в 2020 включать в конфиге nginx? > > Или же создатели сайта https://ssl-config.mozilla.org/ ошибаются, > и ssl_dhparam лучше не включать и DHE-шифры из директивы ssl_ciphers > лучше будет убрать? > > Если создатели сайта https://ssl-config.mozilla.org/ ошибаются, > то осознать свою ошибку они смогут наверное только после того, > как им об этом напишет кто-то из разработчиков nginx? > > об этом кто угодно может завести баг https://github.com/mozilla/ssl-config-generator > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Fri Jan 10 05:20:56 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2020 07:20:56 +0200 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Message-ID: On 10.01.2020 6:37, Илья Шипицин wrote: > об этом кто угодно может завести баг > https://github.com/mozilla/ssl-config-generator В исходном моем сообщении как раз и содержится вопрос - баг это или нет. Кроме того, в одном из тикетов https://github.com/mozilla/ssl-config-generator/issues/69 они прямо признаются что плохо себе представляют как работает nginx внутри и что им бы очень не помешала квалифицированная помощь от разработчиков nginx. Завести issue - не проблема. Проблема в том, чтобы понять, почему это поведение - баг, и в том, чтобы доходчиво объяснить это создателям сайта https://ssl-config.mozilla.org/ -- Best regards, Gena From chipitsine на gmail.com Fri Jan 10 06:41:06 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 10 Jan 2020 11:41:06 +0500 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Message-ID: пт, 10 янв. 2020 г. в 10:21, Gena Makhomed : > On 10.01.2020 6:37, Илья Шипицин wrote: > > > об этом кто угодно может завести баг > > https://github.com/mozilla/ssl-config-generator > > В исходном моем сообщении как раз и содержится вопрос - баг это или нет. > в общем-то вы сами и ответили на свой вопрос. включение или не включение dh_param это ваше желание или нежелание использовать DHE-сьюты. они являются менее криптостойкими чем ECDHE, которые практически повсеместно распространены (что вы и видите по ssl labs). если у вас есть какие-то клиенты, которые не умеют ECDHE, для них DHE может быть хорошим выбором. но это будет стоить вам небольшим понижением рейтинга на ssl labs (с A+ до A). > > Кроме того, в одном из тикетов > https://github.com/mozilla/ssl-config-generator/issues/69 > они прямо признаются что плохо себе представляют как работает > nginx внутри и что им бы очень не помешала квалифицированная > помощь от разработчиков nginx. > > Завести issue - не проблема. Проблема в том, чтобы понять, > почему это поведение - баг, и в том, чтобы доходчиво объяснить > это создателям сайта https://ssl-config.mozilla.org/ в этом плане ssl labs в помощь. он дает просто отличную картину по эмуляции клиентских хендшейков. > > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From gmm на csdoc.com Fri Jan 10 11:52:53 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2020 13:52:53 +0200 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Message-ID: On 10.01.2020 8:41, Илья Шипицин wrote: >>> об этом кто угодно может завести баг >>> https://github.com/mozilla/ssl-config-generator >> В исходном моем сообщении как раз и содержится вопрос - баг это или нет. > в общем-то вы сами и ответили на свой вопрос. Я не уверен в том, что вижу и понимаю все нюансы. Поэтому мне очень хотелось бы, если это возможно, чтобы Maxim Dounin ответил на мои вопросы. По сути они были и есть адресованы в первую очередь именно ему. SSL Configuration Generator https://ssl-config.mozilla.org/ - это наверное самый точный и самый популярный сайт, который публикует рекомендации по настройке SSL/TLS в nginx, поэтому было бы очень хорошо привести его рекомендации в соответствие с действительностью и сделать их максимально полезными. > в этом плане ssl labs в помощь. он дает просто отличную картину по эмуляции > клиентских хендшейков. Он не идеален и может ошибаться, в некоторых редких случаях. Тем более, что Ivan Ristić там уже не работает. Уж простите за невольную рекламу (придется дать ссылку на отчет, чтобы было понятно о чем я говорю), вчера/сегодня буквально менял сертификаты на сайте и ssltest выдал мне такое предупреждение: https://www.ssllabs.com/ssltest/analyze.html?d=www.ideil.com Chain issues Contains anchor Подробное обсуждение этого предупреждения есть на странице https://discussions.qualys.com/thread/11234 Где Ivan Ristić рекомендует спросить у поддержки Namecheap.com зачем они рекмендуют включать CA сертификат USERTrust в bundle. Поддержка Namecheap.com объяснила, что вроде бы надо и таким образом для некоторых очень страых клиентов сайт будет нормально открываться а если сертификат USERTrust в bundle не включать то сайт не откроется. Хотя, может быть действительно нет смысла всем клиентам слать еще и сертификат USERTrust и достаточно будет только сертификата Sectigo? Чтобы довести до идеального состояния настройку SSL/TLS на этом сайте - необходимо будет перейти на CentOS 8, тогда появится поддержка TLS 1.3 и ChaCha20-Poly1305. Все остальное - вроде бы уже сделано наиболее оптимальным способом? Фрагмент конфига: ssl_protocols TLSv1.3 TLSv1.2; ssl_prefer_server_ciphers off; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; ssl_session_cache shared:SSL:10M; ssl_session_timeout 120m; ssl_stapling on; ssl_stapling_verify on; resolver 127.0.0.1; ssl_certificate /etc/tls/STAR.ideil.com/STAR.ideil.com.ecdsa.crt; ssl_certificate_key /etc/tls/STAR.ideil.com/STAR.ideil.com.ecdsa.key; ssl_certificate /etc/tls/STAR.ideil.com/STAR.ideil.com.rsa.crt; ssl_certificate_key /etc/tls/STAR.ideil.com/STAR.ideil.com.rsa.key; -- Best regards, Gena From chipitsine на gmail.com Fri Jan 10 13:03:14 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Fri, 10 Jan 2020 18:03:14 +0500 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Message-ID: пт, 10 янв. 2020 г. в 16:53, Gena Makhomed : > On 10.01.2020 8:41, Илья Шипицин wrote: > > >>> об этом кто угодно может завести баг > >>> https://github.com/mozilla/ssl-config-generator > >> В исходном моем сообщении как раз и содержится вопрос - баг это или нет. > > в общем-то вы сами и ответили на свой вопрос. > > Я не уверен в том, что вижу и понимаю все нюансы. > > Поэтому мне очень хотелось бы, если это возможно, чтобы Maxim Dounin > ответил на мои вопросы. По сути они были и есть адресованы > в первую очередь именно ему. > > SSL Configuration Generator https://ssl-config.mozilla.org/ > - это наверное самый точный и самый популярный сайт, который > публикует рекомендации по настройке SSL/TLS в nginx, > nginxconfig.io еще на слуху есть пожелание ко всем этим конфигураторам - было логично, если давая рекомендации, они бы давали примерную табличку по браузерным хендшейкам типа "сделав такие то настройки, у вас будут работать вот эти браузеры, и не будут вот эти" сняло бы кучу вопросов > поэтому было бы очень хорошо привести его рекомендации > в соответствие с действительностью и сделать их максимально полезными. > > > в этом плане ssl labs в помощь. он дает просто отличную картину по > эмуляции > > клиентских хендшейков. > > Он не идеален и может ошибаться, в некоторых редких случаях. > Тем более, что Ivan Ristić там уже не работает. > из имеющихся инструментов, тем не менее, это лучшее > > Уж простите за невольную рекламу (придется дать ссылку на отчет, > чтобы было понятно о чем я говорю), вчера/сегодня буквально > менял сертификаты на сайте и ssltest выдал мне такое предупреждение: > > https://www.ssllabs.com/ssltest/analyze.html?d=www.ideil.com > > Chain issues Contains anchor > > Подробное обсуждение этого предупреждения есть на странице > https://discussions.qualys.com/thread/11234 > > Где Ivan Ristić рекомендует спросить у поддержки Namecheap.com > зачем они рекмендуют включать CA сертификат USERTrust в bundle. > наличие корневого серта в цепочке имеет некий смысл. реальный кейс - смена корня у Thawte с MD5 на SHA1 вы получили новый сертификат на новом SHA1 корне. всё отлично кроме того, что у кучи необновленных клиентов этого корня еще нет. для этого Thawte отдавал вам кросс-подпись с корня MD5 на новый корень. и вы могли, отдавая цепочку "кросс + новый корень + промежуточный + сервер" попасть в область доверия необновленных клиентов. это прямо реально работало. отдавать только корень без кросса смысла нет, более того, различный софт наличие самоподписанного серта в отдаваемой цепочке будет считать ошибкой, о чем вам ssl labs и говорит (хотя ошибка, конечно, высосана из пальца) > > Поддержка Namecheap.com объяснила, что вроде бы надо и таким образом > для некоторых очень страых клиентов сайт будет нормально открываться > а если сертификат USERTrust в bundle не включать то сайт не откроется. > > Хотя, может быть действительно нет смысла всем клиентам слать еще и > сертификат USERTrust и достаточно будет только сертификата Sectigo? > наверное, вы не пробились до нужного уровня поддержки )) какое-то беспомощное объяснение > > Чтобы довести до идеального состояния настройку SSL/TLS > на этом сайте - необходимо будет перейти на CentOS 8, > тогда появится поддержка TLS 1.3 и ChaCha20-Poly1305. > нет никаких проблем "включить" настройки TLS1.3 и ChaCha20-Poly1305 и на более старых операционках. они не будут задействованы, но и ошибки не будет. > > Все остальное - вроде бы уже сделано наиболее оптимальным способом? > > Фрагмент конфига: > > ssl_protocols TLSv1.3 TLSv1.2; > ssl_prefer_server_ciphers off; > это спорная директива. есть мнение, что если ее задать как "on", то степень контроля над выбранным сьютом выше, и это типа безопаснее. > ssl_ciphers > > ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305; > > ssl_session_cache shared:SSL:10M; > ssl_session_timeout 120m; > ssl_session с каким-то завидным упорством все тащат в конфиг. на самом деле это устаревший механизм по отношению к https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key ticket-ы работают так же, с тем исключением, что они хранятся на стороне клиента. является хорошей практикой указывать файл с настройками тикетов. в противном случае на релоаде старые тикеты обнуляются, и у вас может быть всплеск нагрузки (из-за пересогласования хендшейков) > > ssl_stapling on; > ssl_stapling_verify on; > resolver 127.0.0.1; > > ssl_certificate > /etc/tls/STAR.ideil.com/STAR.ideil.com.ecdsa.crt; > ssl_certificate_key > /etc/tls/STAR.ideil.com/STAR.ideil.com.ecdsa.key; > > ssl_certificate /etc/tls/ > STAR.ideil.com/STAR.ideil.com.rsa.crt; > ssl_certificate_key /etc/tls/ > STAR.ideil.com/STAR.ideil.com.rsa.key; > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From mdounin на mdounin.ru Fri Jan 10 13:04:05 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Fri, 10 Jan 2020 16:04:05 +0300 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Message-ID: <20200110130405.GE12894@mdounin.ru> Hello! On Fri, Jan 10, 2020 at 04:07:17AM +0200, Gena Makhomed wrote: > SSL Configuration Generator https://ssl-config.mozilla.org/ > > Предлагает для конфигурации Intermediate (General-purpose servers with a > variety of clients, recommended for almost all systems) > в конфиге nginx включать ssl_dhparam: > > # curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam.pem > ssl_dhparam /path/to/dhparam.pem; > > Причем, содержимое файла, куда указывает директива ssl_dhparam > будет одинаковым у всех, кто воспользуется этим советом. (!!!) > > И прописывать в директиву ssl_ciphers > в том числе и DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384. > > Не совсем понятен смысл этого действия. > > Начиная с версии 1.11.0 (вышла 24 мая 2016 года) для того чтобы включить > поддержку DHE-шифров - необходимо явно задавать директиву ssl_dhparam. > > Но если посмотреть по результатам https://www.ssllabs.com/ssltest/ > включение или выключение ssl_dhparam практически ни на что не влияет. > > Более широкой поддержки со стороны клиентов не появляется, > единственное изменение, которое удалось заметить - это то, > что IE 11 начинает использовать DHE вместо ECDHE. И на этом всё. > > Рекомендация сайта https://ssl-config.mozilla.org/ является разумной? > ssl_dhparam действительно лучше будет в 2020 включать в конфиге nginx? > > Или же создатели сайта https://ssl-config.mozilla.org/ ошибаются, > и ssl_dhparam лучше не включать и DHE-шифры из директивы ssl_ciphers > лучше будет убрать? Моя позиция по DHE-шифрам проста: они слишком ресурсоёмкие, чтобы о их использовании можно было всерьёз говорить. И это одна из причин, почему по умолчанию они теперь не используются. Положительная сторона у их использовании только одна: они позволяют получить forward secrecy с некоторыми старыми браузерами, и без DHE-шифров с этими браузерами forward secrecy не получить никак. Однако с учётом использования в конкретной обсуждаемой конфигурации только протоколов TLSv1.2 и выше - это положительная сторона, как я понимаю, полностью нивелируется отсутствием возможности общаться с этими старыми браузерами. Так что смысла разрешать DHЕ-шифры - нет, IMHO, приблизительно никакого, это лишь открывает дополнительный DoS-вектор через очень дорогие SSL handshake'и. > Если создатели сайта https://ssl-config.mozilla.org/ ошибаются, > то осознать свою ошибку они смогут наверное только после того, > как им об этом напишет кто-то из разработчиков nginx? Нет, разработчики nginx тут ни при чём. Тут вопрос исключительно в том, что именно хотят разрешить авторы конфигурации, а что - нет. Они явно хотят разрешить DHE-шифры, и явно специально написали как директиву ssl_dhparam, так и DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 в списке шифров. Возможно, тут дело в том, что предлагаемый список шифров - закрытый, и шифров без forward secrecy там вообще нет. И соответственно DHE-шифры оставлены для того, чтобы какие-то соверменные, но малораспространённые клиенты без поддержки ECDH вообще хоть как-то могли коммуницировать с сервером. В любом случае - вопрос "зачем так" - он не к разработчикам nginx'а, а к авторам соответствующей конфигурации. -- Maxim Dounin http://mdounin.ru/ From gmm на csdoc.com Fri Jan 10 17:00:48 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Fri, 10 Jan 2020 19:00:48 +0200 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> Message-ID: <7485ea4f-2340-a9ad-f6a2-db2cb367bc85@csdoc.com> On 10.01.2020 15:03, Илья Шипицин wrote: > nginxconfig.io еще на слуху этот сайт не открывается, ERR_CONNECTION_REFUSED. > есть пожелание ко всем этим конфигураторам - было логично, если давая > рекомендации, они бы давали примерную табличку > по браузерным хендшейкам типа "сделав такие то настройки, у вас будут > работать вот эти браузеры, и не будут вот эти" > > сняло бы кучу вопросов Вряд ли создатели сайта https://ssl-config.mozilla.org/ читают этот список рассылки. Наверное Вам имеет смысл обратиться к ним напрямую - https://github.com/mozilla/ssl-config-generator/issues Идея, которую Вы озвучили действительно очень толковая, и было бы замечательно, если бы они смогли ее реализовать. >> Уж простите за невольную рекламу (придется дать ссылку на отчет, >> чтобы было понятно о чем я говорю), вчера/сегодня буквально >> менял сертификаты на сайте и ssltest выдал мне такое предупреждение: >> >> https://www.ssllabs.com/ssltest/analyze.html?d=www.ideil.com >> >> Chain issues Contains anchor >> >> Подробное обсуждение этого предупреждения есть на странице >> https://discussions.qualys.com/thread/11234 >> >> Где Ivan Ristić рекомендует спросить у поддержки Namecheap.com >> зачем они рекмендуют включать CA сертификат USERTrust в bundle. > > наличие корневого серта в цепочке имеет некий смысл. реальный кейс - смена > корня у Thawte с MD5 на SHA1 > вы получили новый сертификат на новом SHA1 корне. всё отлично кроме того, > что у кучи необновленных клиентов этого корня еще нет. > > для этого Thawte отдавал вам кросс-подпись с корня MD5 на новый корень. > > и вы могли, отдавая цепочку "кросс + новый корень + промежуточный + сервер" > попасть в область доверия необновленных клиентов. > это прямо реально работало. отдавать только корень без кросса смысла нет, > более того, различный софт наличие самоподписанного серта в отдаваемой > цепочке > будет считать ошибкой, о чем вам ssl labs и говорит (хотя ошибка, конечно, > высосана из пальца) Нсколько я понял Ваше объяснение и слова Ivan Ristić на странице https://discussions.qualys.com/thread/11234 о том, что "There won't be any side effects if you remove the self-signed roots. They wouldn't be used anyhow" - самоподписанный корневой сертификат USERTrust RSA Certification Authority из цепочки лучше убрать, потому что толку от него вообще никакого не будет, это только лишние данные по сети передаются, пустая трата ресурсов. Дополнительная полезная информация есть на сайте sectigo на странице https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rgSZ Self-signed Сертификат USERTrust RSA Certification Authority (Root CA) был создан в 2010 году и действителен до 2038 года. Поскольку я на сервере выключаю поддержку TLS 1.0 и TLS 1.1 - более старые клиенты всё равно работать не будут и поддерживать мне их не нужно, а у более новых клиентов этот сертификат и так уже находится в их локальном trust store. Другой Trust Chain Path, в котором сертификат USERTrust RSA Certification Authority является промежуточным, и подписан корневым сертификатом AddTrust External CA Root рассматривать смысла не имеет, потому что сертификат AddTrust External CA Root действителен только до 30 мая 2020 года. А также потому что этот Trust Chain Path был нужен только для тех очень старых клиентов, которые имели в своем trust store сертификат AddTrust External CA Root, выпущенный в 2000 году, но не имели сертификата USERTrust RSA Certification Authority, который был выпущен в 2010 году. Так что Ivan Ristić все-таки был прав, и созданный им сайт https://www.ssllabs.com/ssltest/ выдает очень толковые предупреждения и рекомендации. Спасибо, что помогли мне разобраться в этой ситуации. Теперь, вроде бы все стало ясно и понятно по этому вопросу. >> Чтобы довести до идеального состояния настройку SSL/TLS >> на этом сайте - необходимо будет перейти на CentOS 8, >> тогда появится поддержка TLS 1.3 и ChaCha20-Poly1305. > нет никаких проблем "включить" настройки TLS1.3 и ChaCha20-Poly1305 и на > более старых операционках. они не будут задействованы, но и ошибки не будет. Верно. Именно так я и поступил - в настройках nginx сейчас включены и TLS1.3 и ChaCha20-Poly1305, но активными эти настройки станут только в том случае, когда я перенесу сайт на сервер с CentOS 8, где будет стоять более новая версия OpenSSL 1.1.1 >> ssl_prefer_server_ciphers off; > это спорная директива. есть мнение, что если ее задать как "on", то степень > контроля над выбранным сьютом выше, и это типа безопаснее. Есть мнение, что это ошибочное мнение. Я общался на эту тему с Maxim Dounin. И он еще несколько лет тому назад говорил, что лучше будет, если ssl_prefer_server_ciphers оставить в выключенном состоянии. Почему? Потому что какой именно шифр будет работать наиболее производительным образом на каждом конкретном клиенте - это может знать только сам этот клиент, но никак не сервер. Например, на мобильных устройствах и на компьютерах с процессорами без поддержки AES-NI шифр ChaCha20/Poly1305 будет более быстрым. Но на компьютерах с поддержкой AES-NI - шифры AES-128 и AES-256 будут работать быстрее, чем ChaCha20/Poly1305. Подробнее - см. например картинку https://hsto.org/files/2ac/5d2/128/2ac5d212814145acae1975a9e104bb93.png из статьи https://habr.com/ru/post/325230/ (сама эта статья во многом уже морально устарела и выдает некорректные на сегодня рекомендации, но некоторая полезная информация в ней всё равно содержится) Исходники десктопных браузеров Chrome/Firefox и мобильных браузеров я не смотрел, но очень надеюсь на то, что они умеют самостоятельно корректно выбирать наиболее быстрый шифр. По крайней мере, если они вдруг этого еще не умеют - их можно будет этому достаточно быстро научить. Делать ssl_prefer_server_ciphers on; имеет смысл только в том случае, когда в каких-то шифрах обнаружена уязвимость, и часть клиентов еще не обновилась, тогда можно с помощью этой настройки опускать до нуля приоритет уязвимых шифров, выводя в начало списка безопасные. Других причин крутить настройку ssl_prefer_server_ciphers я не вижу. И Maxim Dounin тоже не видит, если я правильно понял и помню его слова. По крайней мере, на сегодняшний день, когда подавляющее большинство клиентов умеют TLS 1.2 - в большинстве случаев использовать устаревшие версии протокола и/или устаревшие/уязвимые шифры смысла никакого нет. Соответственно, поэтому же и нет смысла в ssl_prefer_server_ciphers on; >> ssl_session_cache shared:SSL:10M; >> ssl_session_timeout 120m; > ssl_session с каким-то завидным упорством все тащат в конфиг. > на самом деле это устаревший механизм по отношению к > > https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key > > ticket-ы работают так же, с тем исключением, что они хранятся на стороне клиента. По умолчанию ssl_session_tickets on; значение этой директивы я не менял. Вы видите какой-то смысл в том, чтобы выключать ssl_session_cache для экономии на сервере нескольких мегабайт shared memory? Вы думали о том, что будет в той ситуации, когда ssl_session_cache выключен, а клиент по какой-то причине не поддерживает ticket-ы? > является хорошей практикой указывать файл с настройками тикетов. Есть такое мнение, что это является очень плохой практикой. https://www.imperialviolet.org/2013/06/27/botchingpfs.html How to botch TLS forward secrecy В документации к nginx же написано, что директива ssl_session_ticket_key необходима, если один и тот же ключ нужно использовать на нескольких серверах. В остальных случаях - случайно сгенерированный ключ, который хранится в памяти nginx будет гораздо лучше как с точки зрения безопасности, так и с точки зрения удобства администрирования. Вот и здесь: https://github.com/mozilla/server-side-tls/issues/135 и здесь тоже https://github.com/mozilla/ssl-config-generator/issues/69 вообще рекомендуется ssl_session_tickets off; потому что proper rotation of session ticket encryption key is not implemented in nignx. То же самое выдает сейчас и сайт https://ssl-config.mozilla.org для Modern варианта конфигурации (Services with clients that support TLS 1.3 and don't need backward compatibility) И логика в этом есть, лучше уж выключить ssl_session_tickets, чем потерять Forward Secrecy. Многим пользователям безопасность HTTPS подключений важнее повышения производительности работы сервера. > в противном случае на релоаде > старые тикеты обнуляются, и у вас может быть всплеск нагрузки (из-за > пересогласования хендшейков) Лучше уж пусть будет всплеск нагрузки, чем ssl_session_ticket_key, который не меняется годами и который сводит Forward Secrecy к нулю. -- Best regards, Gena From nginx-forum на forum.nginx.org Mon Jan 13 09:46:22 2020 From: nginx-forum на forum.nginx.org (yanda.a) Date: Mon, 13 Jan 2020 04:46:22 -0500 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <20191231105812.GS12894@mdounin.ru> References: <20191231105812.GS12894@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > On Mon, Dec 30, 2019 at 03:22:01AM -0500, yanda.a wrote: > > > Добрался до конфигурации, скину почти полную конфигурацию: > > [...] > > Смысла в "почти полной" конфигурации не очень много. Нужна > конфигурация, с которой воспроизводится то, на что вы жалуетесь. > > Попробуйте воспроизвести проблемное поведение в песочнице, с > использованием минимальной конфигурации. Скорее всего в процессе > станет понятно, в чём именно проблема. > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru Думаю, что смысла в конфигурации в принципе нет, если я все понял верно. Дело в том, что на текущей конфигурации мне никак не удалось воспроизвести это поведение в тестовом окружении. От безысходности пришлось включить дебаг и искать сообщения из логов в исходниках. Например, вот что есть в логах: 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client prematurely closed connection while sending to client, client: 176.59.97.91 .... 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http finalize request: 499, "/api/epg?from=1578862800&to=1578949199" a:1, c:1 И вот как это выглядит в логах: request_time: 1.6400000000000001 bytes_sent: 0 status: 499 upstream_addr: ['backend-01-1'] upstream_status: [200] upstream_response_time: [1.225] То есть, мы получили ответ от бекенда, но не смогли по какой-то причине отдать клиенту (это уже другая история). Но, соединение с бекендом мы уже закрыли! А теперь смотрим исходники: if (!u->cacheable && u->peer.connection) { ngx_log_error(NGX_LOG_INFO, ev->log, err, "client prematurely closed connection, " "so upstream connection is closed too"); ngx_http_upstream_finalize_request(r, u, NGX_HTTP_CLIENT_CLOSED_REQUEST); return; } ngx_log_error(NGX_LOG_INFO, ev->log, err, "client prematurely closed connection"); if (u->peer.connection == NULL) { ngx_http_upstream_finalize_request(r, u, NGX_HTTP_CLIENT_CLOSED_REQUEST); } У нас peer.connection == NULL, так как мы уже получили ответ и закрыли соединение с бекендом. К сожалению, запросы с лагающим бекендом пока не удалось отловить в логах. Но, надеюсь они появятся в обозримом будущем и удастся что-то найти. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286711#msg-286711 From mdounin на mdounin.ru Mon Jan 13 12:33:35 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Jan 2020 15:33:35 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: References: <20191231105812.GS12894@mdounin.ru> Message-ID: <20200113123335.GF12894@mdounin.ru> Hello! On Mon, Jan 13, 2020 at 04:46:22AM -0500, yanda.a wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > On Mon, Dec 30, 2019 at 03:22:01AM -0500, yanda.a wrote: > > > > > Добрался до конфигурации, скину почти полную конфигурацию: > > > > [...] > > > > Смысла в "почти полной" конфигурации не очень много. Нужна > > конфигурация, с которой воспроизводится то, на что вы жалуетесь. > > > > Попробуйте воспроизвести проблемное поведение в песочнице, с > > использованием минимальной конфигурации. Скорее всего в процессе > > станет понятно, в чём именно проблема. > > Думаю, что смысла в конфигурации в принципе нет, если я все понял верно. Нет, вы не всё поняли верно. Вы приводите код из функции ngx_http_upstream_check_broken_connection(), который не может быть вызван, если в конфигурации сказано proxy_ignore_client_abort. Соответственно либо конфигурация не такая, как вы говорите, и proxy_ignore_client_abort не используется, либо происходит не то, что вы подумали. > Дело в том, что на текущей конфигурации мне никак не удалось воспроизвести > это поведение в тестовом окружении. От безысходности пришлось включить дебаг > и искать сообщения из логов в исходниках. > > Например, вот что есть в логах: > 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client prematurely closed > connection while sending to client, client: 176.59.97.91 .... > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http finalize request: > 499, "/api/epg?from=1578862800&to=1578949199" a:1, c:1 Покажите debug log для соединения *29319057 плюс-минус хотя бы пару десятков строк от "client prematurely closed", и по возможности без купюр. Возможно что-то станет понятнее. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Jan 13 14:39:21 2020 From: nginx-forum на forum.nginx.org (yanda.a) Date: Mon, 13 Jan 2020 09:39:21 -0500 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <20200113123335.GF12894@mdounin.ru> References: <20200113123335.GF12894@mdounin.ru> Message-ID: <92bde3fb30d828e04c5e5c741bacc31e.NginxMailingListRussian@forum.nginx.org> 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter 00007FF7599D8E48 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in: 0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http copy filter: -2 "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 pipe write downstream done 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 92, old: 7043363034, new: 7043363039 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 78, old: 7043333034, new: 7043333039 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http upstream exit: 0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http upstream request: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http proxy request 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free rr peer 2 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 close http upstream connection: 92 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free: 00007FF752049F80, unused: 48 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer del: 92: 7043363034 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 reusable connection: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http upstream temp fd: -1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http output filter "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http copy filter: "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http postpone filter "/api/epg?from=1578862800&to=1578949199" 00007FFD9965DD50 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http gzip filter 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in: 00007FF7599D8738 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in_buf:00007FF759A96318 ni:0000000000000000 ai:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate in: ni:0000000000000000 no:00007FF759ADF752 ai:0 ao:14510 fl:4 redo:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate out: ni:0000000000000000 no:00007FF759AE3000 ai:0 ao:0 rc:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in_buf:00007FF759A96318 pos:0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 malloc: 00007FF759F2F000:32768 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate in: ni:0000000000000000 no:00007FF759F2F000 ai:0 ao:32768 fl:4 redo:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate out: ni:0000000000000000 no:00007FF759F30319 ai:0 ao:27879 rc:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in_buf:00007FF759A96318 pos:0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free: 00007FF759857000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF759B58000, pos 00007FF759B5FFF6, size: 10 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF75AB19000, pos 00007FF75AB19000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF75F8F7000, pos 00007FF75F8F7000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF7599F3000, pos 00007FF7599F3000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF759A20000, pos 00007FF759A20000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF759A8E000, pos 00007FF759A8E000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write new buf t:1 f:0 00007FF759ADB000, pos 00007FF759ADB000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write new buf t:1 f:0 00007FF759F2F000, pos 00007FF759F2F000, size: 4897 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter: l:1 f:1 s:201515 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter limit 262144 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 windows: conn:11893020 stream:6029312 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96418: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96500: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A965E8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A966D0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96808: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A968F0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A969D8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96AC0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96BF8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96CF0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96DF8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96F00: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 posix_memalign: 00007FF759F14000:4096 @16 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96FC8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14190: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14298: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F143A0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14508: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14610: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14718: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14820: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14988: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14A90: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14B98: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14CA0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14DB8: len:4907 flags:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter 0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http copy filter: -2 "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http finalize request: -2, "/api/epg?from=1578862800&to=1578949199" a:1, c:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 78, old: 7043333034, new: 7043333039 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 read handler 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 SSL_read: 13 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 SSL_read: -1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 SSL_get_error: 2 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 frame type:3 f:0 l:4 sid:39 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 RST_STREAM frame, sid:39 status:8 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client canceled stream 39 while sending to client, client: 176.59.97.91, server: mydomain.info, request: "GET /api/epg?from=1578862800&to=1578949199 HTTP/2.0", upstream: "http://192. 168.50.48:8081/api/epg?from=1578862800&to=1578949199", host: "www.mydomain.info", referrer: "https://www.mydomain.info/" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http run request: "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http test reading 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client prematurely closed connection while sending to client, client: 176.59.97.91, server: mydomain.info, request: "GET /api/epg?from=1578862800&to=1578949199 HTTP/2.0", upstream: " http://192.168.50.48:8081/api/epg?from=1578862800&to=1578949199", host: "www.mydomain.info", referrer: "https://www.mydomain.info/" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http finalize request: 499, "/api/epg?from=1578862800&to=1578949199" a:1, c:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate request count:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate cleanup count:1 blk:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http posted request: "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate handler count:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http request count:1 blk:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 close stream 39, queued 1, processing 7, pushing 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 frame complete pos:00007FF75925100D end:00007FF75925100D 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 write handler По поводу proxy_ignore_client_abort: # nginx -T 2> /dev/null | grep proxy_ignore_client_abort proxy_ignore_client_abort on; Это указано на уровне http Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286714#msg-286714 From nginx-forum на forum.nginx.org Mon Jan 13 14:39:29 2020 From: nginx-forum на forum.nginx.org (yanda.a) Date: Mon, 13 Jan 2020 09:39:29 -0500 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <20200113123335.GF12894@mdounin.ru> References: <20200113123335.GF12894@mdounin.ru> Message-ID: Да, конечно, единственное что - изменю доменное имя, если вы не против. 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter 00007FF7599D8E48 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in: 0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http copy filter: -2 "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 pipe write downstream done 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 92, old: 7043363034, new: 7043363039 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 78, old: 7043333034, new: 7043333039 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http upstream exit: 0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http upstream request: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http proxy request 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free rr peer 2 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 close http upstream connection: 92 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free: 00007FF752049F80, unused: 48 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer del: 92: 7043363034 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 reusable connection: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http upstream temp fd: -1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http output filter "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http copy filter: "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http postpone filter "/api/epg?from=1578862800&to=1578949199" 00007FFD9965DD50 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http gzip filter 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in: 00007FF7599D8738 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in_buf:00007FF759A96318 ni:0000000000000000 ai:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate in: ni:0000000000000000 no:00007FF759ADF752 ai:0 ao:14510 fl:4 redo:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate out: ni:0000000000000000 no:00007FF759AE3000 ai:0 ao:0 rc:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in_buf:00007FF759A96318 pos:0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 malloc: 00007FF759F2F000:32768 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate in: ni:0000000000000000 no:00007FF759F2F000 ai:0 ao:32768 fl:4 redo:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 deflate out: ni:0000000000000000 no:00007FF759F30319 ai:0 ao:27879 rc:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in_buf:00007FF759A96318 pos:0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free: 00007FF759857000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF759B58000, pos 00007FF759B5FFF6, size: 10 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF75AB19000, pos 00007FF75AB19000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF75F8F7000, pos 00007FF75F8F7000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF7599F3000, pos 00007FF7599F3000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF759A20000, pos 00007FF759A20000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write old buf t:1 f:0 00007FF759A8E000, pos 00007FF759A8E000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write new buf t:1 f:0 00007FF759ADB000, pos 00007FF759ADB000, size: 32768 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 write new buf t:1 f:0 00007FF759F2F000, pos 00007FF759F2F000, size: 4897 file: 0, size: 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter: l:1 f:1 s:201515 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter limit 262144 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 windows: conn:11893020 stream:6029312 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96418: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96500: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A965E8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A966D0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96808: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A968F0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A969D8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96AC0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96BF8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96CF0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96DF8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96F00: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 posix_memalign: 00007FF759F14000:4096 @16 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759A96FC8: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14190: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14298: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F143A0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14508: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14610: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14718: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14820: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14988: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14A90: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14B98: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14CA0: len:8192 flags:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2:39 create DATA frame 00007FF759F14DB8: len:4907 flags:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter 0000000000000000 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http copy filter: -2 "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http finalize request: -2, "/api/epg?from=1578862800&to=1578949199" a:1, c:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 78, old: 7043333034, new: 7043333039 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 read handler 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 SSL_read: 13 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 SSL_read: -1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 SSL_get_error: 2 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 frame type:3 f:0 l:4 sid:39 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 RST_STREAM frame, sid:39 status:8 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client canceled stream 39 while sending to client, client: 176.59.97.91, server: mydomain.info, request: "GET /api/epg?from=1578862800&to=1578949199 HTTP/2.0", upstream: "http://192. 168.50.48:8081/api/epg?from=1578862800&to=1578949199", host: "www.mydomain.info", referrer: "https://www.mydomain.info/" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http run request: "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http test reading 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client prematurely closed connection while sending to client, client: 176.59.97.91, server: mydomain.info, request: "GET /api/epg?from=1578862800&to=1578949199 HTTP/2.0", upstream: " http://192.168.50.48:8081/api/epg?from=1578862800&to=1578949199", host: "www.mydomain.info", referrer: "https://www.mydomain.info/" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http finalize request: 499, "/api/epg?from=1578862800&to=1578949199" a:1, c:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate request count:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate cleanup count:1 blk:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http posted request: "/api/epg?from=1578862800&to=1578949199" 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate handler count:1 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http request count:1 blk:0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 close stream 39, queued 1, processing 7, pushing 0 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 frame complete pos:00007FF75925100D end:00007FF75925100D 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http2 write handler Насчет proxy_ignore_client_abort: # nginx -T 2> /dev/null | grep proxy_ignore_client_abort proxy_ignore_client_abort on; Это указано на уровне http. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286715#msg-286715 From mdounin на mdounin.ru Mon Jan 13 19:39:16 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Mon, 13 Jan 2020 22:39:16 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: References: <20200113123335.GF12894@mdounin.ru> Message-ID: <20200113193916.GG12894@mdounin.ru> Hello! On Mon, Jan 13, 2020 at 09:39:29AM -0500, yanda.a wrote: > Да, конечно, единственное что - изменю доменное имя, если вы не против. Ок, так понятно, что происходит: > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http write filter 00007FF7599D8E48 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 gzip in: 0000000000000000 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http copy filter: -2 "/api/epg?from=1578862800&to=1578949199" > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 pipe write downstream done > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 92, old: 7043363034, new: 7043363039 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 event timer: 78, old: 7043333034, new: 7043333039 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http upstream exit: 0000000000000000 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http upstream request: 0 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 finalize http proxy request > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 free rr peer 2 0 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 close http upstream connection: 92 Где-то тут общение с бекендом завершено, однако ответ ещё не полностью отправлен клиенту. В процессе отправки клиенте закрывает HTTP/2 stream: > 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client canceled stream 39 while sending to client, client: 176.59.97.91, server: mydomain.info, request: "GET /api/epg?from=1578862800&to=1578949199 HTTP/2.0", upstream: "http://192.168.50.48:8081/api/epg?from=1578862800&to=1578949199", host:"www.mydomain.info", referrer: "https://www.mydomain.info/" И дальше зовётся ngx_http_test_reading(), который и финализирует соединение с кодом 499: > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http run request: "/api/epg?from=1578862800&to=1578949199" > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http test reading > 2020/01/13 02:28:13 [info] 17855#17855: *29319057 client prematurely closed connection while sending to client, client: 176.59.97.91, server: mydomain.info, request: "GET /api/epg?from=1578862800&to=1578949199 HTTP/2.0", upstream: " http://192.168.50.48:8081/api/epg?from=1578862800&to=1578949199", host: "www.mydomain.info", referrer: "https://www.mydomain.info/" > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http finalize request: 499, "/api/epg?from=1578862800&to=1578949199" a:1, c:1 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate request count:1 > 2020/01/13 02:28:13 [debug] 17855#17855: *29319057 http terminate cleanup count:1 blk:0 При этом в функции ngx_http_terminate_request(), которая обновляет статус запроса тогда и только тогда, когда статус либо ещё не стоит, либо клиенту вообще ничего не было отправлено. В данном случае, видимо, за счёт использования HTTP/2 случается ситуация, когда клиенту вообще ничего не отправлено (вероятно, за счёт других данных в соединении), и статус таки обновляется на 499. Ситуация с $upstream_status "-", видимо, получается похожим образом: если в процессе работы с бекендом клиент отменяет HTTP/2 stream, то у соответствующей этому stream'у структуре соединения будет проставлен флаг c->error. И если после этого случается timeout бекенда, то в ngx_http_upstream_next() nginx, увидев стоящий флаг c->error, не пойдёт на следующий бекенд, а вместо этого завершит обработку запроса с кодом 499. То есть я был неправ, получить в логах 499 при использовании proxy_ignore_client_abort таки можно, хотя и непросто. В простых случаях это в основном затрагивает HTTP/2, но и в HTTP/1.x можно получить похожее поведение, например, при использовании подзапросов. На практике при использовании proxy_ignore_client_abort это означает, что работа с бекендом завершена или не начиналась. Возвращаясь к исходному вопросу: да, текущее поведение выглядит нормально. -- Maxim Dounin http://mdounin.ru/ From nginx-forum на forum.nginx.org Mon Jan 13 20:07:20 2020 From: nginx-forum на forum.nginx.org (yanda.a) Date: Mon, 13 Jan 2020 15:07:20 -0500 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: <20200113193916.GG12894@mdounin.ru> References: <20200113193916.GG12894@mdounin.ru> Message-ID: Maxim Dounin Wrote: ------------------------------------------------------- > Hello! > > Где-то тут общение с бекендом завершено, однако ответ ещё не > полностью отправлен клиенту. В процессе отправки клиенте > закрывает HTTP/2 stream: Кстати да, я немного не досмотрел. В этом server {} не используется listen http2. Но, в логах наблюдается именно http/2.0 и в хроме видно h2 в консоли разработчика. Не могли бы вы подсказать, насколько это адекватно? > При этом в функции ngx_http_terminate_request(), которая обновляет > статус запроса тогда и только тогда, когда статус либо ещё не > стоит, либо клиенту вообще ничего не было отправлено. В данном > случае, видимо, за счёт использования HTTP/2 случается ситуация, > когда клиенту вообще ничего не отправлено (вероятно, за счёт > других данных в соединении), и статус таки обновляется на 499. > > Ситуация с $upstream_status "-", видимо, получается похожим > образом: если в процессе работы с бекендом клиент отменяет HTTP/2 > stream, то у соответствующей этому stream'у структуре соединения > будет проставлен флаг c->error. И если после этого случается > timeout бекенда, то в ngx_http_upstream_next() nginx, увидев > стоящий флаг c->error, не пойдёт на следующий бекенд, а вместо > этого завершит обработку запроса с кодом 499. > > То есть я был неправ, получить в логах 499 при использовании > proxy_ignore_client_abort таки можно, хотя и непросто. В простых > случаях это в основном затрагивает HTTP/2, но и в HTTP/1.x можно > получить похожее поведение, например, при использовании > подзапросов. > > На практике при использовании proxy_ignore_client_abort это > означает, что работа с бекендом завершена или не начиналась. > > Возвращаясь к исходному вопросу: да, текущее поведение выглядит > нормально. Постараюсь описать ситуацию. Мы пытаемся выгружать эти логи в clickhouse для анализа latency и работы бекендов в целом, и сбора разнообразной статистики. Для этого на выходе у нас ожидается, что переменные (после парсинга это массивы в нашем случае) $upstream_addr, $upstream_response_time и $upstream_status имеют одну длину. Но, как показала практика, это не всегда так. В связи с этим ещё один, вероятно последний, вопрос. Есть ли возможность сделать это поведение более предсказуемым? Или проще добавлять недостающие элементы массива в процессе обработки (по сути угадывая, что там должно быть)? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286606,286718#msg-286718 From mdounin на mdounin.ru Tue Jan 14 12:47:16 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 14 Jan 2020 15:47:16 +0300 Subject: =?UTF-8?B?UmU6INCf0YPRgdGC0LDRjyDQv9C10YDQtdC80LXQvdC90LDRjyAkdXBzdHJlYW0g?= =?UTF-8?B?c3RhdHVzINC/0YDQuCA0OTk=?= In-Reply-To: References: <20200113193916.GG12894@mdounin.ru> Message-ID: <20200114124716.GH12894@mdounin.ru> Hello! On Mon, Jan 13, 2020 at 03:07:20PM -0500, yanda.a wrote: > Maxim Dounin Wrote: > ------------------------------------------------------- > > Hello! > > > > Где-то тут общение с бекендом завершено, однако ответ ещё не > > полностью отправлен клиенту. В процессе отправки клиенте > > закрывает HTTP/2 stream: > Кстати да, я немного не досмотрел. В этом server {} не используется listen > http2. Но, в логах наблюдается именно http/2.0 и в хроме видно h2 в консоли > разработчика. Не могли бы вы подсказать, насколько это адекватно? Параметры директивы listen - это параметры listen-сокета, и они применяются ко всем соединениям, использующим данный listen-сокет. Соответственно если у вас написано в одном сервере: listen 443 ssl http2; а в другом listen 443; то для соединений, принятых на порту 443 будет использоваться SSL и HTTP/2. Нюанс - сейчас одном сервере можно написать listen 443 ssl http2; а в другом listen 443 ssl; то есть без "http2", и будет работать так же, как если бы параметров не было написано вообще - то есть будет использоваться и SSL, и HTTP/2. Это, безусловно, вводит в заблуждение, и такое мы, видимо, в ближайшем будущем просто запретим. [...] > Постараюсь описать ситуацию. Мы пытаемся выгружать эти логи в clickhouse для > анализа latency и работы бекендов в целом, и сбора разнообразной статистики. > Для этого на выходе у нас ожидается, что переменные (после парсинга это > массивы в нашем случае) $upstream_addr, $upstream_response_time и > $upstream_status имеют одну длину. Но, как показала практика, это не всегда > так. В связи с этим ещё один, вероятно последний, вопрос. Есть ли > возможность сделать это поведение более предсказуемым? Или проще добавлять > недостающие элементы массива в процессе обработки (по сути угадывая, что там > должно быть)? Элемент массива там есть, в соответствующей позиции $upstream_status указан "-". -- Maxim Dounin http://mdounin.ru/ From postmaster на softsearch.ru Tue Jan 14 14:41:17 2020 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Tue, 14 Jan 2020 17:41:17 +0300 Subject: =?UTF-8?B?0LrQvtC70LjRh9C10YHRgtCy0L4g0Lgg0YDQsNC30LzQtdGAINCx0LDQutC10YI=?= =?UTF-8?B?0L7Qsg==?= Message-ID: <566730581.20200114174117@softsearch.ru> Здравствуйте. У nginx-а есть несколько настроек, которые задаю количество бакетов и количество элементов в каждом бакете. Если заданных значений не достаточно, то nginx не запустится и выдаст ошибку. Так раньше было по крайней мере. Как подружить такие настройки со сгенерёнными конфигами, которые часто меняются? Даже если задать большое количество бакетов, то вполне вероятна ситуация, когда такая настройка не подойдёт и nginx не запустится. При этом nginx давно и успешно работает в облаках, где подобная генерация конфигов - норма. Как эту проблему обычно решают или её уже нет давно? -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Tue Jan 14 15:06:33 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 14 Jan 2020 18:06:33 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+INC4INGA0LDQt9C80LXRgCDQsdCw0Lo=?= =?UTF-8?B?0LXRgtC+0LI=?= In-Reply-To: <566730581.20200114174117@softsearch.ru> References: <566730581.20200114174117@softsearch.ru> Message-ID: <20200114150633.GI12894@mdounin.ru> Hello! On Tue, Jan 14, 2020 at 05:41:17PM +0300, Михаил Монашёв wrote: > У nginx-а есть несколько настроек, которые задаю количество > бакетов и количество элементов в каждом бакете. Если заданных значений > не достаточно, то nginx не запустится и выдаст ошибку. Так раньше было > по крайней мере. > > Как подружить такие настройки со сгенерёнными конфигами, которые часто > меняются? Даже если задать большое количество бакетов, то вполне > вероятна ситуация, когда такая настройка не подойдёт и nginx не > запустится. При этом nginx давно и успешно работает в облаках, где > подобная генерация конфигов - норма. Как эту проблему обычно решают > или её уже нет давно? Начиная с 1.5.13 (http://hg.nginx.org/nginx/rev/c348dea081fb) - nginx запустится, и выдаст лишь предупреждение. Фатальная ошибка будет только в том случае, если размер одного элемента превышает заданный bucket size, но это обычно означет именно что ошибку в конфиге. -- Maxim Dounin http://mdounin.ru/ From chipitsine на gmail.com Tue Jan 14 21:01:23 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Wed, 15 Jan 2020 02:01:23 +0500 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: <7485ea4f-2340-a9ad-f6a2-db2cb367bc85@csdoc.com> References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> <7485ea4f-2340-a9ad-f6a2-db2cb367bc85@csdoc.com> Message-ID: пт, 10 янв. 2020 г. в 22:00, Gena Makhomed : > On 10.01.2020 15:03, Илья Шипицин wrote: > > > nginxconfig.io еще на слуху > > этот сайт не открывается, ERR_CONNECTION_REFUSED. > > > есть пожелание ко всем этим конфигураторам - было логично, если давая > > рекомендации, они бы давали примерную табличку > > по браузерным хендшейкам типа "сделав такие то настройки, у вас будут > > работать вот эти браузеры, и не будут вот эти" > > > > сняло бы кучу вопросов > > Вряд ли создатели сайта https://ssl-config.mozilla.org/ > читают этот список рассылки. Наверное Вам имеет смысл обратиться > к ним напрямую - https://github.com/mozilla/ssl-config-generator/issues > > Идея, которую Вы озвучили действительно очень толковая, > и было бы замечательно, если бы они смогли ее реализовать. > https://github.com/mozilla/ssl-config-generator/issues/73 в каком отделении счет открывали, туда и идите. > > >> Уж простите за невольную рекламу (придется дать ссылку на отчет, > >> чтобы было понятно о чем я говорю), вчера/сегодня буквально > >> менял сертификаты на сайте и ssltest выдал мне такое предупреждение: > >> > >> https://www.ssllabs.com/ssltest/analyze.html?d=www.ideil.com > >> > >> Chain issues Contains anchor > >> > >> Подробное обсуждение этого предупреждения есть на странице > >> https://discussions.qualys.com/thread/11234 > >> > >> Где Ivan Ristić рекомендует спросить у поддержки Namecheap.com > >> зачем они рекмендуют включать CA сертификат USERTrust в bundle. > > > > наличие корневого серта в цепочке имеет некий смысл. реальный кейс - > смена > > корня у Thawte с MD5 на SHA1 > > вы получили новый сертификат на новом SHA1 корне. всё отлично кроме того, > > что у кучи необновленных клиентов этого корня еще нет. > > > > для этого Thawte отдавал вам кросс-подпись с корня MD5 на новый корень. > > > > и вы могли, отдавая цепочку "кросс + новый корень + промежуточный + > сервер" > > попасть в область доверия необновленных клиентов. > > это прямо реально работало. отдавать только корень без кросса смысла нет, > > более того, различный софт наличие самоподписанного серта в отдаваемой > > цепочке > > будет считать ошибкой, о чем вам ssl labs и говорит (хотя ошибка, > конечно, > > высосана из пальца) > > Нсколько я понял Ваше объяснение и слова Ivan Ristić на странице > https://discussions.qualys.com/thread/11234 о том, > что "There won't be any side effects if you remove the self-signed > roots. They wouldn't be used anyhow" - самоподписанный корневой > сертификат USERTrust RSA Certification Authority из цепочки > лучше убрать, потому что толку от него вообще никакого не будет, > это только лишние данные по сети передаются, пустая трата ресурсов. > > Дополнительная полезная информация есть на сайте sectigo на странице > https://support.sectigo.com/Com_KnowledgeDetailPage?Id=kA01N000000rgSZ > > Self-signed Сертификат USERTrust RSA Certification Authority (Root CA) > был создан в 2010 году и действителен до 2038 года. Поскольку я на > сервере выключаю поддержку TLS 1.0 и TLS 1.1 - более старые клиенты > всё равно работать не будут и поддерживать мне их не нужно, > а у более новых клиентов этот сертификат и так уже находится > в их локальном trust store. > > Другой Trust Chain Path, в котором сертификат > USERTrust RSA Certification Authority является промежуточным, > и подписан корневым сертификатом AddTrust External CA Root > рассматривать смысла не имеет, потому что сертификат > AddTrust External CA Root действителен только до 30 мая 2020 года. > А также потому что этот Trust Chain Path был нужен только для тех > очень старых клиентов, которые имели в своем trust store сертификат > AddTrust External CA Root, выпущенный в 2000 году, > но не имели сертификата USERTrust RSA Certification Authority, > который был выпущен в 2010 году. > > Так что Ivan Ristić все-таки был прав, > и созданный им сайт https://www.ssllabs.com/ssltest/ > выдает очень толковые предупреждения и рекомендации. > > Спасибо, что помогли мне разобраться в этой ситуации. > Теперь, вроде бы все стало ясно и понятно по этому вопросу. > > >> Чтобы довести до идеального состояния настройку SSL/TLS > >> на этом сайте - необходимо будет перейти на CentOS 8, > >> тогда появится поддержка TLS 1.3 и ChaCha20-Poly1305. > > > нет никаких проблем "включить" настройки TLS1.3 и ChaCha20-Poly1305 и на > > более старых операционках. они не будут задействованы, но и ошибки не > будет. > > Верно. > > Именно так я и поступил - в настройках nginx сейчас включены > и TLS1.3 и ChaCha20-Poly1305, но активными эти настройки > станут только в том случае, когда я перенесу сайт на сервер > с CentOS 8, где будет стоять более новая версия OpenSSL 1.1.1 > > >> ssl_prefer_server_ciphers off; > > > это спорная директива. есть мнение, что если ее задать как "on", то > степень > > контроля над выбранным сьютом выше, и это типа безопаснее. > > Есть мнение, что это ошибочное мнение. > > Я общался на эту тему с Maxim Dounin. И он еще несколько лет тому назад > говорил, что лучше будет, если ssl_prefer_server_ciphers оставить > в выключенном состоянии. > > Почему? Потому что какой именно шифр будет работать наиболее > производительным образом на каждом конкретном клиенте - > это может знать только сам этот клиент, но никак не сервер. > > Например, на мобильных устройствах и на компьютерах с процессорами > без поддержки AES-NI шифр ChaCha20/Poly1305 будет более быстрым. > > Но на компьютерах с поддержкой AES-NI - шифры AES-128 и AES-256 > будут работать быстрее, чем ChaCha20/Poly1305. > > Подробнее - см. например картинку > https://hsto.org/files/2ac/5d2/128/2ac5d212814145acae1975a9e104bb93.png > из статьи https://habr.com/ru/post/325230/ (сама эта статья во многом > уже морально устарела и выдает некорректные на сегодня рекомендации, > но некоторая полезная информация в ней всё равно содержится) > > Исходники десктопных браузеров Chrome/Firefox и мобильных браузеров > я не смотрел, но очень надеюсь на то, что они умеют самостоятельно > корректно выбирать наиболее быстрый шифр. По крайней мере, > если они вдруг этого еще не умеют - их можно будет этому > достаточно быстро научить. > > Делать ssl_prefer_server_ciphers on; имеет смысл только в том случае, > когда в каких-то шифрах обнаружена уязвимость, и часть клиентов > еще не обновилась, тогда можно с помощью этой настройки опускать > до нуля приоритет уязвимых шифров, выводя в начало списка безопасные. > > Других причин крутить настройку ssl_prefer_server_ciphers я не вижу. > И Maxim Dounin тоже не видит, если я правильно понял и помню его слова. > > По крайней мере, на сегодняшний день, когда подавляющее большинство > клиентов умеют TLS 1.2 - в большинстве случаев использовать устаревшие > версии протокола и/или устаревшие/уязвимые шифры смысла никакого нет. > Соответственно, поэтому же и нет смысла в ssl_prefer_server_ciphers on; > > >> ssl_session_cache shared:SSL:10M; > >> ssl_session_timeout 120m; > > > ssl_session с каким-то завидным упорством все тащат в конфиг. > > на самом деле это устаревший механизм по отношению к > > > > > https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key > > > > ticket-ы работают так же, с тем исключением, что они хранятся на стороне > клиента. > > По умолчанию ssl_session_tickets on; значение этой директивы я не менял. > > Вы видите какой-то смысл в том, чтобы выключать ssl_session_cache > для экономии на сервере нескольких мегабайт shared memory? > > Вы думали о том, что будет в той ситуации, когда ssl_session_cache > выключен, а клиент по какой-то причине не поддерживает ticket-ы? > > > является хорошей практикой указывать файл с настройками тикетов. > > Есть такое мнение, что это является очень плохой практикой. > > https://www.imperialviolet.org/2013/06/27/botchingpfs.html > How to botch TLS forward secrecy > > В документации к nginx же написано, что директива ssl_session_ticket_key > необходима, если один и тот же ключ нужно использовать на нескольких > серверах. В остальных случаях - случайно сгенерированный ключ, который > хранится в памяти nginx будет гораздо лучше как с точки зрения > безопасности, так и с точки зрения удобства администрирования. > > Вот и здесь: https://github.com/mozilla/server-side-tls/issues/135 > и здесь тоже https://github.com/mozilla/ssl-config-generator/issues/69 > вообще рекомендуется ssl_session_tickets off; потому что proper rotation > of session ticket encryption key is not implemented in nignx. > > То же самое выдает сейчас и сайт https://ssl-config.mozilla.org > для Modern варианта конфигурации (Services with clients > that support TLS 1.3 and don't need backward compatibility) > > И логика в этом есть, лучше уж выключить ssl_session_tickets, > чем потерять Forward Secrecy. Многим пользователям безопасность > HTTPS подключений важнее повышения производительности работы сервера. > > > в противном случае на релоаде > > старые тикеты обнуляются, и у вас может быть всплеск нагрузки (из-за > > пересогласования хендшейков) > > Лучше уж пусть будет всплеск нагрузки, чем ssl_session_ticket_key, > который не меняется годами и который сводит Forward Secrecy к нулю. > > -- > Best regards, > Gena > > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From postmaster на softsearch.ru Wed Jan 15 09:49:56 2020 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Wed, 15 Jan 2020 12:49:56 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+INC4INGA0LDQt9C80LXRgCDQsdCw0Lo=?= =?UTF-8?B?0LXRgtC+0LI=?= In-Reply-To: <20200114150633.GI12894@mdounin.ru> References: <566730581.20200114174117@softsearch.ru> <20200114150633.GI12894@mdounin.ru> Message-ID: <1255996759.20200115124956@softsearch.ru> Здравствуйте, Maxim. > Начиная с 1.5.13 (http://hg.nginx.org/nginx/rev/c348dea081fb) - > nginx запустится, и выдаст лишь предупреждение. > Фатальная ошибка будет только в том случае, если размер одного > элемента превышает заданный bucket size, но это обычно означет > именно что ошибку в конфиге. А если при старте nginx-а в бакете есть 10 элементов и надо добавить 11-ый, который не влазит, то что произойдёт? По ссылке там только уровень логирования изменён. А хочется понять логику в описанной ситуации. -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Wed Jan 15 13:12:34 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 15 Jan 2020 16:12:34 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+INC4INGA0LDQt9C80LXRgCDQsdCw0Lo=?= =?UTF-8?B?0LXRgtC+0LI=?= In-Reply-To: <1255996759.20200115124956@softsearch.ru> References: <566730581.20200114174117@softsearch.ru> <20200114150633.GI12894@mdounin.ru> <1255996759.20200115124956@softsearch.ru> Message-ID: <20200115131234.GK12894@mdounin.ru> Hello! On Wed, Jan 15, 2020 at 12:49:56PM +0300, Михаил Монашёв wrote: > > Начиная с 1.5.13 (http://hg.nginx.org/nginx/rev/c348dea081fb) - > > nginx запустится, и выдаст лишь предупреждение. > > > Фатальная ошибка будет только в том случае, если размер одного > > элемента превышает заданный bucket size, но это обычно означет > > именно что ошибку в конфиге. > > А если при старте nginx-а в бакете есть 10 элементов и надо добавить > 11-ый, который не влазит, то что произойдёт? > > По ссылке там только уровень логирования изменён. А хочется понять > логику в описанной ситуации. Там в коммит-логе всё подробно документировано: "hash now ignores bucket_size if it hits max_size limit". То есть если мы не смогли построить хэш в рамках заданных ограничений на максимальное количество бакетов (max size) и размер одного бакета (bucket size), то мы построим хэш с максимально разрешённым количеством бакетов, игнорируя ограничене на размер одного бакета. -- Maxim Dounin http://mdounin.ru/ From postmaster на softsearch.ru Thu Jan 16 12:00:31 2020 From: postmaster на softsearch.ru (=?utf-8?B?0JzQuNGF0LDQuNC7INCc0L7QvdCw0YjRkdCy?=) Date: Thu, 16 Jan 2020 15:00:31 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+INC4INGA0LDQt9C80LXRgCDQsdCw0Lo=?= =?UTF-8?B?0LXRgtC+0LI=?= In-Reply-To: <20200115131234.GK12894@mdounin.ru> References: <566730581.20200114174117@softsearch.ru> <20200114150633.GI12894@mdounin.ru> <1255996759.20200115124956@softsearch.ru> <20200115131234.GK12894@mdounin.ru> Message-ID: <173969616.20200116150031@softsearch.ru> Здравствуйте, Maxim. > То есть если мы не смогли построить хэш в рамках заданных > ограничений на максимальное количество бакетов (max size) и размер > одного бакета (bucket size), то мы построим хэш с максимально > разрешённым количеством бакетов, игнорируя ограничене на размер > одного бакета. Понятно, т.е. эти настройки фактически про экономию оперативки... А где описано максимально разрешённое количество? Это оно http://hg.nginx.org/nginx/file/tip/src/core/ngx_hash.h#l68 ? #define NGX_HASH_LARGE_ASIZE 16384 #define NGX_HASH_LARGE_HSIZE 10007 -- С уважением, Михаил mailto:postmaster на softsearch.ru From mdounin на mdounin.ru Thu Jan 16 12:24:41 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Thu, 16 Jan 2020 15:24:41 +0300 Subject: =?UTF-8?B?UmU6INC60L7Qu9C40YfQtdGB0YLQstC+INC4INGA0LDQt9C80LXRgCDQsdCw0Lo=?= =?UTF-8?B?0LXRgtC+0LI=?= In-Reply-To: <173969616.20200116150031@softsearch.ru> References: <566730581.20200114174117@softsearch.ru> <20200114150633.GI12894@mdounin.ru> <1255996759.20200115124956@softsearch.ru> <20200115131234.GK12894@mdounin.ru> <173969616.20200116150031@softsearch.ru> Message-ID: <20200116122441.GM12894@mdounin.ru> Hello! On Thu, Jan 16, 2020 at 03:00:31PM +0300, Михаил Монашёв wrote: > > То есть если мы не смогли построить хэш в рамках заданных > > ограничений на максимальное количество бакетов (max size) и размер > > одного бакета (bucket size), то мы построим хэш с максимально > > разрешённым количеством бакетов, игнорируя ограничене на размер > > одного бакета. > > Понятно, т.е. эти настройки фактически про экономию оперативки... Нет. Эти настройки - про скорость работы. В идеале - один бакет должен помещаться в cache line процессора, а бакетов - должно быть минимальное количество, чтобы их адресация также не занимала больших объёмов памяти и легко влезала в кэш процессора. Про это есть статья тут: http://nginx.org/ru/docs/hash.html > А где описано максимально разрешённое количество? Размер одного бакета ограничен значением 64k, так как для отслеживания размеров бакета в процессе построения хеша используется тип short. Ограничение на максимального количество бакетов можно поставить любое. > Это оно http://hg.nginx.org/nginx/file/tip/src/core/ngx_hash.h#l68 ? > #define NGX_HASH_LARGE_ASIZE 16384 > #define NGX_HASH_LARGE_HSIZE 10007 Нет, это константы, используемые при выделении различных внутренних структур для хэшей большого размера. Они ни коим образом ничего не ограничивают. -- Maxim Dounin http://mdounin.ru/ From mdounin на mdounin.ru Tue Jan 21 13:54:59 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Tue, 21 Jan 2020 16:54:59 +0300 Subject: nginx-1.17.8 Message-ID: <20200121135459.GZ12894@mdounin.ru> Изменения в nginx 1.17.8 21.01.2020 *) Добавление: директива grpc_pass поддерживает переменные. *) Исправление: при обработке pipelined-запросов по SSL-соединению мог произойти таймаут; ошибка появилась в 1.17.5. *) Исправление: в директиве debug_points при использовании HTTP/2. Спасибо Даниилу Бондареву. -- Maxim Dounin http://nginx.org/ From gmm на csdoc.com Wed Jan 22 03:04:33 2020 From: gmm на csdoc.com (Gena Makhomed) Date: Wed, 22 Jan 2020 05:04:33 +0200 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: <20200110130405.GE12894@mdounin.ru> References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> <20200110130405.GE12894@mdounin.ru> Message-ID: On 10.01.2020 15:04, Maxim Dounin wrote: >> Если создатели сайта https://ssl-config.mozilla.org/ ошибаются, >> то осознать свою ошибку они смогут наверное только после того, >> как им об этом напишет кто-то из разработчиков nginx? > Нет, разработчики nginx тут ни при чём. Тут вопрос исключительно > в том, что именно хотят разрешить авторы конфигурации, а что - > нет. Они явно хотят разрешить DHE-шифры, и явно специально > написали как директиву ssl_dhparam, так и > DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384 в списке > шифров. > > Возможно, тут дело в том, что предлагаемый список шифров - > закрытый, и шифров без forward secrecy там вообще нет. И > соответственно DHE-шифры оставлены для того, чтобы какие-то > соверменные, но малораспространённые клиенты без поддержки ECDH > вообще хоть как-то могли коммуницировать с сервером. Да, Вы правы. Проблема есть с IE11 - по данным w3counter.com этот браузер имеет 2.30% Browser Market Share и вместе с тем, в случае использования RSA сертификата, IE11 не умеет использовать ECDHE, и именно по этой причине в списке шифров были оставлены DHE-шифры с RSA сертификатами. Если же на сервере используется ECDSA сертификат - в таком случае IE11 умеет использовать ECDHE, тогда нет никакой необходимости использовать директиву ssl_dhparam и можно выключать все DHE-* шифры и все *-RSA-* шифры в директиве ssl_ciphers, оставив там только три самых нормальных ECDHE-ECDSA шифра ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-CHACHA20-POLY1305 в режиме ssl_prefer_server_ciphers off; 0. Кстати, причин, чтобы использвать ECDSA и RSA сертификаты одновременно для сервера в котором разрешены только протоколы TLS 1.2 и TLS 1.3 - я так и не смог найти. По всей видимости, одновременное использование ECDSA и RSA сертификатов имеет смысл только для тех серверов, в которых разрешено использование протоколов TLS 1.0 и TLS 1.1. Или я тут ошибся? В багтрекере страницы https://wiki.mozilla.org/Security/Server_Side_TLS а именно в issue https://github.com/mozilla/server-side-tls/issues/268 я немного пообщался теми людьми, которые редактируют эту вики страницу, узнал от них много нового и интересного про причины, почему сайт https://ssl-config.mozilla.org/ выдает именно такие рекомендации. Сейчас готовлю сервер для тестирования скорости работы ECDHE с различными вариантами ssl_ecdh_curve и ssl_ciphers и DHE с различными вариантами ssl_dhparam и ssl_ciphers и в процессе настройки nginx наткнулся на проблемы. Параметры сборки nginx из исходников на CentOS 7: # nginx -V nginx version: nginx/1.17.8 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) built with OpenSSL 1.1.1d 10 Sep 2019 TLS SNI support enabled configure arguments: --with-http_ssl_module --with-openssl=/root/src/openssl-1.1.1d --with-pcre=/root/src/pcre-8.43 --without-http_gzip_module Проблемы: 1. В документации http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols написано, что директиву ssl_protocols можно задавать на уровне server. Однако - если в default_server было задано ssl_protocols TLSv1.2; то в других server`ах директива ssl_protocols TLSv1.3; не работает. И наоборот, если в default_server задано ssl_protocols TLSv1.3; то в других server`ах директива ssl_protocols TLSv1.2; не работает. Это где ошибка - в документации на сайте или в коде nginx 1.17.8? 2. Аналогичная проблема и с директивой ssl_ecdh_curve: В документации http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ecdh_curve написано, что директиву ssl_ecdh_curve можно задавать на уровне server. Однако, nginx на эту директиву вообще никак не реагирует. У меня есть три тестовых сервера: server_name tls13-ecdsa-ecdhe-x25519.ideil.com; ssl_ecdh_curve X25519; server_name tls13-ecdsa-ecdhe-prime256v1.ideil.com; ssl_ecdh_curve prime256v1; server_name tls13-ecdsa-ecdhe-secp384r1.ideil.com; ssl_ecdh_curve secp384r1; В действительности - везде используется X25519 для Server Temp Key. Это где ошибка - в документации на сайте или в коде nginx 1.17.8? 3. Третий вопрос, если можно: Тикет https://trac.nginx.org/nginx/ticket/1529 читал но по причине https://github.com/openssl/openssl/issues/7938 - что нам с этим всем делать? Как управлять ciphers в TLS 1.3 ? Может быть все-таки имеет смысл сделать [недокументированную (?)] директиву ssl_ciphersuites которая будет управлять шифрами для TLS 1.3 ? Оставив директиву ssl_ciphers для управления шифрами TLS 1.2 и 1.1/1.0 ? Чтобы можно было, например, для теста настроить все возможные комбинации шифров TLS 1.3 (их всего три) и все возможные комбинации рекомендуемых сайтом https://wiki.mozilla.org/Security/Server_Side_TLS вариантов ecdh curve (их тоже всего три: X25519, prime256v1, secp384r1). Итого - только для TLS 1.3 получается всего 9 возможных комбинаций. Для всех возможных комбинаций - необходимо будет 36 различных серверов. Кстати, google пошел еще дальше, и в конфигурации для www.google.com сделал возможность отдельно настраивать значение директивы ssl_prefer_server_ciphers и ssl_ciphers для TLS 1.3 и предыдущих версий. https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com Может быть и для nginx был бы приемлимым более обобщенный синтаксис, например, что-то вроде такого: ssl_ciphers TLSv1.3 ................; ssl_ciphers TLSv1.2 ................; ssl_ciphers TLSv1.1 ................; ssl_ciphers TLSv1.0 ................; ssl_prefer_server_ciphers TLSv1.3 off; ssl_prefer_server_ciphers TLSv1.2 on; ssl_prefer_server_ciphers TLSv1.1 on; ssl_prefer_server_ciphers TLSv1.0 on; ? -- Best regards, Gena From mdounin на mdounin.ru Wed Jan 22 17:13:48 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 22 Jan 2020 20:13:48 +0300 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> <20200110130405.GE12894@mdounin.ru> Message-ID: <20200122171348.GE12894@mdounin.ru> Hello! On Wed, Jan 22, 2020 at 05:04:33AM +0200, Gena Makhomed wrote: [...] > 1. > В документации > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_protocols > написано, что директиву ssl_protocols можно задавать на уровне server. > > Однако - если в default_server было задано ssl_protocols TLSv1.2; > то в других server`ах директива ssl_protocols TLSv1.3; не работает. > > И наоборот, если в default_server задано ssl_protocols TLSv1.3; > то в других server`ах директива ssl_protocols TLSv1.2; не работает. > > Это где ошибка - в документации на сайте или в коде nginx 1.17.8? Возможность задания какой-либо директивы в контексте server - не означает, что она будет применяться для всех запросов, попадающих в этот блок server. В случае виртуальных серверов - могут быть нюансы. В данном случае проблема в том, что разрешённые протоколы проверяются OpenSSL'ем в рамках начала SSL handshake'а, и изменение списка разрешённых протоколов при переходе в другой блок server по SNI - ни на чо не влияет, так как к моменту парсинга расширения server_name - протокол уже зафиксирован. Ну и очевидно, что переход в другой блок server в рамках HTTP-заголовка Host - влияет ещё меньше. Подробнее можно почитать тут и по ссылкам: https://trac.nginx.org/nginx/ticket/844 Соответственно отвечая на заданный вопрос: ошибка - в понимании написанного в документации. > 2. > Аналогичная проблема и с директивой ssl_ecdh_curve: > > В документации > http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_ecdh_curve > написано, что директиву ssl_ecdh_curve можно задавать на уровне server. > > Однако, nginx на эту директиву вообще никак не реагирует. > > У меня есть три тестовых сервера: > > server_name tls13-ecdsa-ecdhe-x25519.ideil.com; > ssl_ecdh_curve X25519; > > server_name tls13-ecdsa-ecdhe-prime256v1.ideil.com; > ssl_ecdh_curve prime256v1; > > server_name tls13-ecdsa-ecdhe-secp384r1.ideil.com; > ssl_ecdh_curve secp384r1; > > В действительности - везде используется X25519 для Server Temp Key. > > Это где ошибка - в документации на сайте или в коде nginx 1.17.8? В OpenSSL. Подробнее тут: https://trac.nginx.org/nginx/ticket/1089 > 3. > Третий вопрос, если можно: > > Тикет https://trac.nginx.org/nginx/ticket/1529 читал > но по причине https://github.com/openssl/openssl/issues/7938 > - что нам с этим всем делать? Как управлять ciphers в TLS 1.3 ? Проще всего - никак. Если очень хочется, то спектр возможностей чуть расширяется: Если речь про OpenSSL, то это можно делать через openssl.cnf. Если речь про BoringSSL, то никак даже если очень хочется. > Может быть все-таки имеет смысл сделать [недокументированную (?)] > директиву ssl_ciphersuites которая будет управлять шифрами для TLS 1.3 ? > Оставив директиву ssl_ciphers для управления шифрами TLS 1.2 и 1.1/1.0 ? > > Чтобы можно было, например, для теста настроить все возможные комбинации > шифров TLS 1.3 (их всего три) и все возможные комбинации рекомендуемых > сайтом https://wiki.mozilla.org/Security/Server_Side_TLS вариантов > ecdh curve (их тоже всего три: X25519, prime256v1, secp384r1). > Итого - только для TLS 1.3 получается всего 9 возможных комбинаций. > Для всех возможных комбинаций - необходимо будет 36 различных серверов. Задача "сделать тестовый стенд со всеми возможными комбинациями параметров SSL / TLS" - это не совсем та задача, для которой разрабатывается nginx. > Кстати, google пошел еще дальше, и в конфигурации для www.google.com > сделал возможность отдельно настраивать значение директивы > ssl_prefer_server_ciphers и ssl_ciphers для TLS 1.3 и предыдущих версий. > > https://www.ssllabs.com/ssltest/analyze.html?d=www.google.com Подозреваю, что на сервере BoringSSL. Там выбор шифров для TLSv1.3 просто игнорирует все имеющиеся настройки. > Может быть и для nginx был бы приемлимым более обобщенный синтаксис, > например, что-то вроде такого: > > ssl_ciphers TLSv1.3 ................; > ssl_ciphers TLSv1.2 ................; > ssl_ciphers TLSv1.1 ................; > ssl_ciphers TLSv1.0 ................; > > ssl_prefer_server_ciphers TLSv1.3 off; > ssl_prefer_server_ciphers TLSv1.2 on; > ssl_prefer_server_ciphers TLSv1.1 on; > ssl_prefer_server_ciphers TLSv1.0 on; > > ? Я не вижу решительно никаких причин для того, чтобы подобное пытаться релизовывать. -- Maxim Dounin http://mdounin.ru/ From bgx на protva.ru Wed Jan 22 19:16:02 2020 From: bgx на protva.ru (Evgeniy Berdnikov) Date: Wed, 22 Jan 2020 22:16:02 +0300 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: <20200122171348.GE12894@mdounin.ru> References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> <20200110130405.GE12894@mdounin.ru> <20200122171348.GE12894@mdounin.ru> Message-ID: <20200122191602.GE15801@sie.protva.ru> On Wed, Jan 22, 2020 at 08:13:48PM +0300, Maxim Dounin wrote: > On Wed, Jan 22, 2020 at 05:04:33AM +0200, Gena Makhomed wrote: [...] > > И наоборот, если в default_server задано ssl_protocols TLSv1.3; > > то в других server`ах директива ssl_protocols TLSv1.2; не работает. > > > > Это где ошибка - в документации на сайте или в коде nginx 1.17.8? > > Возможность задания какой-либо директивы в контексте server - не > означает, что она будет применяться для всех запросов, попадающих > в этот блок server. В случае виртуальных серверов - могут быть > нюансы. [...] > Подробнее можно почитать тут и по ссылкам: > > https://trac.nginx.org/nginx/ticket/844 > > Соответственно отвечая на заданный вопрос: ошибка - в понимании > написанного в документации. Как человек, наступавший на те же самые грабли, хочу выразить своё несогласие с посылом, что тупица здесь читатель. Документация вводит в заблуждение, а поведение nginx никак не способствует обходу этой ловушки. Если в доке написано "context: server", то читатель понимает это буквально: для заданного server будет действовать указанная директива. И поскольку её задача ограничить перечень протоколов, то именно это, с точки зрения пользователя, и должно происходить. Потребителю не до того, чтобы вспоминать, что бывают name-based виртуалхосты, sni-based, ip-based, процессы, нити, пространства имён и прочая лабуда, ему не до проблем их сплетения в разных версиях. Потребитель ожидает, что ему дадут простой и удобный интерфейс, где все нюансы продуманы, а возможность ошибиться и получить не то, что ожидал -- сведена к минимуму. Если же интерфейс позволяет сделать бессмысленные или даже противоречивые комбинации параметров -- это плохой интерфейс, и его следует по возможности выправлять в рантайме, например, предупреждениями вида "извините, в этой конфигурации есть разные версии ssl_protocols на одном ip-шнике, это работать не будет, см. подробности в ". Ну и в документации капканы тоже желательно упоминать, разумеется. Вероятно, хотелось сделать интерфейс простым и универсальным, чтобы пользователю было легче его освоить. С одной директривой "server". Но если идти этим путём, то стыковку разных гаек и болтов по их профилю, метрикам и шагам резьбы следует прятать под капот, а потребителю выводить такой набор педалей и ручек, чтобы он мог решить задачу "ехать" без головной боли и гаданий, где же включился тормоз... IMHO. -- Eugene Berdnikov From chipitsine на gmail.com Wed Jan 22 19:40:47 2020 From: chipitsine на gmail.com (=?UTF-8?B?0JjQu9GM0Y8g0KjQuNC/0LjRhtC40L0=?=) Date: Thu, 23 Jan 2020 00:40:47 +0500 Subject: SSL Configuration Generator https://ssl-config.mozilla.org/ In-Reply-To: <20200122191602.GE15801@sie.protva.ru> References: <0def8092-17c6-6bc7-cbb5-32d994cde7f9@csdoc.com> <20200110130405.GE12894@mdounin.ru> <20200122171348.GE12894@mdounin.ru> <20200122191602.GE15801@sie.protva.ru> Message-ID: чт, 23 янв. 2020 г. в 00:16, Evgeniy Berdnikov : > On Wed, Jan 22, 2020 at 08:13:48PM +0300, Maxim Dounin wrote: > > On Wed, Jan 22, 2020 at 05:04:33AM +0200, Gena Makhomed wrote: > [...] > > > И наоборот, если в default_server задано ssl_protocols TLSv1.3; > > > то в других server`ах директива ssl_protocols TLSv1.2; не работает. > > > > > > Это где ошибка - в документации на сайте или в коде nginx 1.17.8? > > > > Возможность задания какой-либо директивы в контексте server - не > > означает, что она будет применяться для всех запросов, попадающих > > в этот блок server. В случае виртуальных серверов - могут быть > > нюансы. > [...] > > Подробнее можно почитать тут и по ссылкам: > > > > https://trac.nginx.org/nginx/ticket/844 > > > > Соответственно отвечая на заданный вопрос: ошибка - в понимании > > написанного в документации. > > Как человек, наступавший на те же самые грабли, хочу выразить своё > несогласие с посылом, что тупица здесь читатель. Документация вводит > в заблуждение, а поведение nginx никак не способствует обходу этой > ловушки. > > SSL-ная часть nginx обложена граблями примерно полностью. как вы думаете, в приведенной ниже конфигурации stapling включится ? не торопитесь с ответом )) server { listen 443 ssl http2; ssl_stapling on; location / { proxy_pass http://upstream; } } server { listen 443 ssl http2 default; return 404; } > Если в доке написано "context: server", то читатель понимает это > буквально: для заданного server будет действовать указанная директива. > И поскольку её задача ограничить перечень протоколов, то именно это, > с точки зрения пользователя, и должно происходить. Потребителю > не до того, чтобы вспоминать, что бывают name-based виртуалхосты, > sni-based, ip-based, процессы, нити, пространства имён и прочая лабуда, > ему не до проблем их сплетения в разных версиях. Потребитель ожидает, > что ему дадут простой и удобный интерфейс, где все нюансы продуманы, > а возможность ошибиться и получить не то, что ожидал -- сведена к > минимуму. Если же интерфейс позволяет сделать бессмысленные или даже > противоречивые комбинации параметров -- это плохой интерфейс, и его > следует по возможности выправлять в рантайме, например, предупреждениями > вида "извините, в этой конфигурации есть разные версии ssl_protocols > на одном ip-шнике, это работать не будет, см. подробности в ". > > Ну и в документации капканы тоже желательно упоминать, разумеется. > > Вероятно, хотелось сделать интерфейс простым и универсальным, чтобы > пользователю было легче его освоить. С одной директривой "server". > Но если идти этим путём, то стыковку разных гаек и болтов по их профилю, > метрикам и шагам резьбы следует прятать под капот, а потребителю выводить > такой набор педалей и ручек, чтобы он мог решить задачу "ехать" без > головной боли и гаданий, где же включился тормоз... IMHO. > -- > Eugene Berdnikov > _______________________________________________ > nginx-ru mailing list > nginx-ru на nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru ----------- следущая часть ----------- Вложение в формате HTML было извлечено… URL: From nginx-forum на forum.nginx.org Wed Jan 29 03:20:23 2020 From: nginx-forum на forum.nginx.org (Ilya Evseev) Date: Tue, 28 Jan 2020 22:20:23 -0500 Subject: =?UTF-8?B?U1NMIEVhcmx5IERhdGEg0L/QvtC00LTQtdGA0LbQuNCy0LDQtdGCINGC0L7Qu9GM?= =?UTF-8?B?0LrQviDQv9C10YDQstGL0Lkgd29ya2VyPw==?= Message-ID: Есть Nginx 1.17.8, собран со свежей BoringSSL stable. Запущен на Linux kernel 5.4.10: nginx version: nginx/1.17.8 built by gcc 4.8.5 20150623 (Red Hat 4.8.5-39) (GCC) built with OpenSSL 1.1.0 (compatible; BoringSSL) (running with BoringSSL) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-compat --with-file-aio --with-threads --with-http_addition_module --with-http_dav_module --with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_mp4_module --with-http_realip_module --with-http_secure_link_module --with-http_slice_module --with-http_ssl_module --with-http_stub_status_module --with-http_sub_module --with-http_v2_module --with-stream --with-stream_realip_module --with-stream_ssl_module --with-stream_ssl_preread_module --with-openssl=boringssl --with-http_image_filter_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -fPIC' --with-ld-opt='-Wl,-z,relro -Wl,-z,now -pie' 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 поддерживает только первый воркер. Этому есть какое-то объяснение? multi_accept и accept_mutex на ситуацию не влияют. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,286846,286846#msg-286846 From pluknet на nginx.com Wed Jan 29 10:40:44 2020 From: pluknet на nginx.com (Sergey Kandaurov) Date: Wed, 29 Jan 2020 13:40:44 +0300 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: References: Message-ID: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> > On 29 Jan 2020, at 06:20, Ilya Evseev 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 со включёнными по умолчанию тикетами. В TLSv1.2 тикеты можно выключить (ssl_session_tickets off) и использовать session id, в TLSv1.3 это отключит любую возможность восстановления сессий. Используйте OpenSSL, там это работает. -- Sergey Kandaurov From mdounin на mdounin.ru Wed Jan 29 12:06:29 2020 From: mdounin на mdounin.ru (Maxim Dounin) Date: Wed, 29 Jan 2020 15:06:29 +0300 Subject: =?UTF-8?B?UmU6IFNTTCBFYXJseSBEYXRhINC/0L7QtNC00LXRgNC20LjQstCw0LXRgiDRgtC+?= =?UTF-8?B?0LvRjNC60L4g0L/QtdGA0LLRi9C5IHdvcmtlcj8=?= In-Reply-To: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> References: <831CB40B-A9C5-4E36-8ECE-DF1A9B76CBE1@nginx.com> Message-ID: <20200129120629.GO12894@mdounin.ru> Hello! On Wed, Jan 29, 2020 at 01:40:44PM +0300, Sergey Kandaurov wrote: > > > On 29 Jan 2020, at 06:20, Ilya Evseev 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, и работать всегда. Другой вопрос, что в стандарте про Early Data написано неисполнимое требование про невосстановление сессии более одного раза, которое как минимум OpenSSL'ем трактуется как "должна быть запись во встроенном кэше сессий, и при восстановлении мы её убираем" (что в свою очередь как раз означает поведение "работает только в текущем воркере, и только при использовании встроенного кэша сессий"). В OpenSSL это поведение с некоторых пор лечится с помощью флага SSL_OP_NO_ANTI_REPLAY (который nginx и использует). В BoringSSL раньше всей этой фигни не было, и там всё работало из коробки, без дополнительных приседаний. Закоммитили какую-то аналогичную ерунду? > Используйте OpenSSL, там это работает. В части Early Data это, IMHO, очень странный совет. Ты не хуже меня знаешь, через какое место в OpenSSL реализована поддеркжа Early Data. То, что она вообще работает - это скорее случайность. -- Maxim Dounin http://mdounin.ru/