From hans345 at gmx.at Fri Mar 3 15:33:25 2023 From: hans345 at gmx.at (=?UTF-8?Q?Hans_M=C3=BCller?=) Date: Fri, 3 Mar 2023 16:33:25 +0100 Subject: Reverse Proxy 502 Bad Gateway Message-ID: An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Fri Mar 3 20:45:31 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 3 Mar 2023 23:45:31 +0300 Subject: Reverse Proxy 502 Bad Gateway In-Reply-To: References: Message-ID: Hello! On Fri, Mar 03, 2023 at 04:33:25PM +0100, Hans Müller wrote: > Hello, > I am working in a proxmox environment, setting up a ngnix reverse proxy > (192.168.178.103) forwarding requests via https to a nginx backend > server (192.168.178.105). On the backend server shellinabox is > installed. Request from the internet are secured via a Letsentcrypt > certificate. For the encryption to the backend server I use a > self-signed certificate. > When I want to open the next-shell.example.com I get an 502 Bad Gateway > error > On the reverse proxy are the following configs > HttpGateway [...] > location / { > proxy_set_header Host $host; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > proxy_ssl_certificate /etc/selfcerts/stern-example-cert-chain.pem; > proxy_ssl_certificate_key /etc/selfcerts/stern-example-key.pem; > proxy_ssl_verify off; > proxy_pass [1]https://192.168.178.105:4200; Note you are proxying using the "https" protocol. [...] > On the backend server there is the following config > next-shell.example.com > server { > listen 192.168.178.105:4200; > server_name next-shell.example.com; But the backend is not configured to use SSL on the socket (or at least this is not something visible from the configuration provided). Note no "ssl" parameter on the listen directive. [...] > When I try to open the page there is this error in the nginx error log > {{{ > [error] 1103#1103: *1 SSL_do_handshake() failed (SSL: > error:0A00010B:SSL routines::wrong version > number) while SSL handshaking to upstream, client: 95.116.52.151, > server: next-shell.example.com, request: "GET /f > avicon.ico HTTP/2.0", upstream: > "[3]https://192.168.178.105:4200/favicon.ico", host: > "next-shell.example.com" > }}} > > Any idea, what I can do here? The error is somewhat expected: you are trying to connect to non-SSL port using SSL, and this is expected to fail. You should either configure SSL on the backend, or change proxying to use the "http" protocol instead. -- Maxim Dounin http://mdounin.ru/ From hans345 at gmx.at Sat Mar 4 16:29:33 2023 From: hans345 at gmx.at (=?UTF-8?Q?Hans_M=C3=BCller?=) Date: Sat, 4 Mar 2023 17:29:33 +0100 Subject: Aw: Re: Reverse Proxy 502 Bad Gateway In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From siembabdavid at gmail.com Sat Mar 4 21:01:32 2023 From: siembabdavid at gmail.com (David Siembab) Date: Sat, 4 Mar 2023 16:01:32 -0500 Subject: learning python sloppy, but it works just change the versions for fedora haven't tried red hat or centos Message-ID: the code is as follows and is very sloppy: #!/usr/bin/env python3 import subprocess as sp import os import pwd os.chdir(os.path.expanduser('~')) pcre2_version="pcre2-10.40" zlib_version="zlib-1.2.13" openssl_version="openssl-1.1.1p" nginx_version="nginx-1.22.1" deps = [ 'curl', 'wget', 'tree','perl','perl-devel','perl-ExtUtils-Embed','libxslt','libxslt-devel', 'libxml2','libxml2-devel','gd','gd-devel','GeoIP','GeoIP-devel' ] deps_group = ['Development Tools'] def set_download_url(array=[]): if not array or not isinstance(array, list): return return '/'.join(array) + '.tar.gz' pcre2_download_url=set_download_url([ 'github.com/PCRE2Project/pcre2/releases/download/', pcre2_version, pcre2_version ]) zlib_download_url=set_download_url([ 'http://zlib.net/', zlib_version ]) openssl_download_url=set_download_url([ 'http://www.openssl.org/source/', openssl_version ]) nginx_download_url= set_download_url([ 'https://nginx.org/download/', nginx_version ]) def download_build_install(url): tar_file = url.split('/')[-1] print(f'Downloading {url} and untaring {tar_file}') sp.run(f'wget -N {url}', shell=True) sp.run(f'tar xzvf {tar_file}', shell=True) def delete_tar_gz(version): tarfile=version + '.tar.gz' print(f'deleting {tarfile}') os.remove(os.path.join(os.path.expanduser('~'), tarfile)) print(f'deleted {tarfile}') print('ok, first thin first lets get all the dnf dependencies to compile nginx') print('are you ready for timewasting dnf forever repo loads? [y/n]') answer = input() if not answer or answer.lower().startswith('n'): print('ok, have a good day') if answer.lower().startswith('y'): new = ['sudo', 'dnf' ] groupinstall = new + ['groupinstall', '-y'] + deps_group depinstall = new + ['install', '-y'] + deps listed = [groupinstall, depinstall] for a in listed: sp.run(a) print(f'Nice, now lets download the sources for:\n\t{openssl_version}, {zlib_version},{pcre2_version}') print('are you ready?[y/n]') answer1 = input() if not answer1 or answer1.lower().startswith('n'): print('ok, have a good day') if answer.lower().startswith('y'): for b in [openssl_download_url, zlib_download_url, pcre2_download_url]: download_build_install(b) for c in [openssl_version, zlib_version, pcre2_version]: delete_tar_gz(c) download_build_install(nginx_download_url) print(f'setting the man page:') if not os.path.exists('/usr/share/man/man8/nginx.8'): sp.run(['sudo', 'cp', os.path.join(os.path.expanduser('~'),f'{nginx_version}/nginx.8'), '/usr/share/man/man8']) sp.run(['sudo', 'gzip', '/usr/share/man/man8/nginx.8']) sp.run('ls /usr/share/man/man8/ | grep nginx.8.gz', shell=True) print(f'going into {nginx_version} directory') os.chdir(nginx_version) sp.run( ['./configure', '--prefix=/etc/nginx', '--sbin-path=/usr/sbin/nginx', '--modules-path=/usr/lib64/nginx/modules', '--conf-path=/etc/nginx/nginx.conf', '--error-log-path=/var/log/nginx/error.log', '--pid-path=/var/run/nginx.pid', '--lock-path=/var/run/nginx.lock', '--user=nginx', '--group=nginx', '--build=Fedora', '--builddir=nginx-1.15.8', '--with-select_module', '--with-poll_module', '--with-threads', '--with-file-aio', '--with-http_ssl_module', '--with-http_v2_module', '--with-http_realip_module', '--with-http_addition_module', '--with-http_xslt_module=dynamic', '--with-http_image_filter_module=dynamic', '--with-http_geoip_module=dynamic', '--with-http_sub_module', '--with-http_dav_module', '--with-http_flv_module', '--with-http_mp4_module', '--with-http_gunzip_module', '--with-http_gzip_static_module', '--with-http_auth_request_module', '--with-http_random_index_module', '--with-http_secure_link_module', '--with-http_degradation_module', '--with-http_slice_module', '--with-http_stub_status_module', '--with-http_perl_module=dynamic', '--with-perl_modules_path=/usr/lib64/perl5', '--with-perl=/usr/bin/perl', '--http-log-path=/var/log/nginx/access.log', '--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', '--with-mail=dynamic', '--with-mail_ssl_module', '--with-stream=dynamic', '--with-stream_ssl_module', '--with-stream_realip_module', '--with-stream_geoip_module=dynamic', '--with-stream_ssl_preread_module', '--with-compat', f'--with-pcre=../{pcre2_version}', '--with-pcre-jit', f'--with-zlib=../{zlib_version}', f'--with-openssl=../{openssl_version}', '--with-openssl-opt=no-nextprotoneg', '--with-debug'] ) sp.run('make') sp.run(['sudo', 'make', 'install']) if os.path.islink('/etc/nginx/modules'): sp.run('sudo rm /etc/nginx/modules', shell=True) sp.run('sudo ln -s /usr/lib64/nginx/modules /etc/nginx/modules', shell=True) try: pwd.getpwnam('nginx') except KeyError: sp.run('sudo useradd --system --home /var/cache/nginx --shell /sbin/nologin\ --comment "nginx user" --user-group nginx', shell=True) for x in ['/var/cache/nginx/client_temp','/var/cache/nginx/fastcgi_temp', '/var/cache/nginx/proxy_temp','/var/cache/nginx/scgi_temp','/var/cache/nginx/uwsgi_temp']: if not os.path.exists(x): sp.run(['sudo','mkdir', '-p', x]) sp.run('sudo chmod 700 /var/cache/nginx/*', shell=True) sp.run('sudo chown nginx:root /var/cache/nginx/*', shell=True) print('check for errors') sp.run(['sudo', 'nginx', '-t']) thank you for your time, that is the attached file -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: nginx_build.py Type: text/x-python Size: 5993 bytes Desc: not available URL: From ekgermann at semperen.com Thu Mar 9 06:56:50 2023 From: ekgermann at semperen.com (Eric Germann) Date: Thu, 9 Mar 2023 01:56:50 -0500 Subject: Issue with getting to HTTP/3 or QUIC on first connect Message-ID: I’m having an issue where I (think I) have enabled HTTP3 correctly on my nginx server. When I connect to the server the first time, it indicates HTTP/2 in the logs. If I hit refresh it indicates HTTP/3 from then on. So something is wrong with the configuration of the server to offer headers to negotiate it. I’ve even added HTTPS DNS records to indicate the preferred connection schemes. Bonus points if you can help me get QUIC working too. The result of http3check.net is "HTTP/3 Check could not get the server's advertised QUIC versions due to the error given below. Bad status code from server. Thanks in advance for any pointers Eric Source code was pulled 2023-02-27 Build information is: nginx version: nginx/1.23.4 built by gcc 7.3.1 20180712 (Red Hat 7.3.1-15) (GCC) built with OpenSSL 3.0.8+quic 7 Feb 2023 TLS SNI support enabled configure arguments: --with-threads --with-cc-opt='-static -static-libgcc' --with-ld-opt=-static --with-debug --with-compat --with-file-aio --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-http_realip_module --with-http_secure_link_module --with-http_random_index_module --with-http_geoip_module --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-stream_quic_module --with-http_sub_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-cc-opt=-I/usr/local/include --with-ld-opt=-L/usr/local/lib --with-openssl=../quictls --with-openssl-opt=enable-tls1_3 --add-module=/source/ngx_brotli Pertinent config for the server block is upstream httpd_backend { server 172.28.10.91:443; keepalive 120; } log_format quic '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" "$http3"'; access_log logs/access.log quic; # NON-SSL server { listen 80; listen [::]:80; server_name www.example.com; location / { rewrite ^ https://www.example.com$request_uri?/ permanent; } } # SSL server { listen 443 ssl http2; listen [::]:443 ssl http2; listen 443 http3 reuseport; listen [::]:443 http3 reuseport; quic_retry on; server_name noc2.semperen.com; # Set up your cert paths ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem; ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; ssl_trusted_certificate /etc/letsencrypt/live/www.example.com/chain.pem; ssl_dhparam SSLKeys/dhparam.pem; ssl_protocols TLSv1.3; ssl_prefer_server_ciphers On; ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:AES256+EECDH:AES256+EDH:!aNULL:!CBC; ssl_ecdh_curve secp384r1; ssl_early_data on; # enable ocsp stapling ssl_stapling on; ssl_stapling_verify on; resolver 8.8.4.4 8.8.8.8 valid=86400s; resolver_timeout 10s; # upgrade to HTTP3 and HTTP2 add_header alt-svc 'h3=":443"; ma=86400, h2=":443"; ma=86400'; add_header alt-svc 'h2=":443"; ma=86400; persist=1'; add_header alt-svc 'h2=":443"; ma=86400;'; add_header X-Frame-Options "SAMEORIGIN"; # tell users to go to SSL version next time add_header Strict-Transport-Security "max-age=31104000; includeSubdomains" always; # handle brotli compression brotli on; brotli_static on; # Note this is one line, even if it wraps and renders as two brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; brotli_buffers 16 8k; brotli_comp_level 9; client_max_body_size 32M; error_page 502 /custom_502.html; location = /custom_502.html { root /usr/local/nginx/html; internal; } location / { proxy_pass https://httpd_backend; proxy_http_version 1.1; proxy_buffering on; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_pass_header Authorization; # proxy_set_header X-Scheme $scheme; # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection "upgrade"; } location /roundcube { proxy_pass https://172.28.10.100; proxy_http_version 1.1; proxy_buffering on; proxy_set_header X-Forwarded-For $remote_addr; proxy_set_header X-Real-IP $remote_addr; proxy_set_header Host $host; proxy_pass_header Authorization; # proxy_set_header X-Scheme $scheme; # proxy_set_header Upgrade $http_upgrade; # proxy_set_header Connection "upgrade"; } } -- Eric Germann ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com LinkedIn: https://www.linkedin.com/in/ericgermann Medium: https://ekgermann.medium.com Twitter: @ekgermann Telegram || Signal || Skype || WhatsApp || Phone +1 {dash} 419 {dash} 513 {dash} 0712 GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From ekgermann at semperen.com Thu Mar 9 07:16:25 2023 From: ekgermann at semperen.com (Eric Germann) Date: Thu, 9 Mar 2023 02:16:25 -0500 Subject: Issue with getting to HTTP/3 or QUIC on first connect In-Reply-To: References: Message-ID: Forgot to add, here are the HTTPS [1] records in DNS IN HTTPS 100 . no-default-alpn alpn="h3" IN HTTPS 200 . no-default-alpn alpn="h2" They 100/200 are weights, much like MX records, where the lowest one wins [1] https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-11.txt > On Mar 9, 2023, at 01:56, Eric Germann wrote: > > I’m having an issue where I (think I) have enabled HTTP3 correctly on my nginx server. When I connect to the server the first time, it indicates HTTP/2 in the logs. If I hit refresh it indicates HTTP/3 from then on. So something is wrong with the configuration of the server to offer headers to negotiate it. I’ve even added HTTPS DNS records to indicate the preferred connection schemes. Bonus points if you can help me get QUIC working too. > > The result of http3check.net is "HTTP/3 Check could not get the server's advertised QUIC versions due to the error given below. > Bad status code from server. > Thanks in advance for any pointers > > Eric > > Source code was pulled 2023-02-27 > > > Build information is: > > nginx version: nginx/1.23.4 > built by gcc 7.3.1 20180712 (Red Hat 7.3.1-15) (GCC) > built with OpenSSL 3.0.8+quic 7 Feb 2023 > TLS SNI support enabled > configure arguments: --with-threads --with-cc-opt='-static -static-libgcc' --with-ld-opt=-static --with-debug --with-compat --with-file-aio --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-http_realip_module --with-http_secure_link_module --with-http_random_index_module --with-http_geoip_module --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-stream_quic_module --with-http_sub_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-cc-opt=-I/usr/local/include --with-ld-opt=-L/usr/local/lib --with-openssl=../quictls --with-openssl-opt=enable-tls1_3 --add-module=/source/ngx_brotli > > > Pertinent config for the server block is > > upstream httpd_backend { > server 172.28.10.91:443; > > keepalive 120; > } > > log_format quic '$remote_addr - $remote_user [$time_local] ' > '"$request" $status $body_bytes_sent ' > '"$http_referer" "$http_user_agent" "$http3"'; > > access_log logs/access.log quic; > > # NON-SSL > server { > listen 80; > listen [::]:80; > server_name www.example.com; > > location / { > rewrite ^ https://www.example.com$request_uri?/ permanent; > } > } > > # SSL > server { > listen 443 ssl http2; > listen [::]:443 ssl http2; > listen 443 http3 reuseport; > listen [::]:443 http3 reuseport; > > quic_retry on; > > server_name noc2.semperen.com; > > # Set up your cert paths > ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem; > ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; > ssl_trusted_certificate /etc/letsencrypt/live/www.example.com/chain.pem; > ssl_dhparam SSLKeys/dhparam.pem; > ssl_protocols TLSv1.3; > ssl_prefer_server_ciphers On; > ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:AES256+EECDH:AES256+EDH:!aNULL:!CBC; > ssl_ecdh_curve secp384r1; > ssl_early_data on; > > # enable ocsp stapling > ssl_stapling on; > ssl_stapling_verify on; > > resolver 8.8.4.4 8.8.8.8 valid=86400s; > resolver_timeout 10s; > > # upgrade to HTTP3 and HTTP2 > add_header alt-svc 'h3=":443"; ma=86400, h2=":443"; ma=86400'; > add_header alt-svc 'h2=":443"; ma=86400; persist=1'; > add_header alt-svc 'h2=":443"; ma=86400;'; > > add_header X-Frame-Options "SAMEORIGIN"; > > > # tell users to go to SSL version next time > add_header Strict-Transport-Security "max-age=31104000; includeSubdomains" always; > > # handle brotli compression > brotli on; > brotli_static on; > > # Note this is one line, even if it wraps and renders as two > brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; > > brotli_buffers 16 8k; > brotli_comp_level 9; > > client_max_body_size 32M; > > error_page 502 /custom_502.html; > location = /custom_502.html { > root /usr/local/nginx/html; > internal; > } > > location / { > proxy_pass https://httpd_backend; > proxy_http_version 1.1; > proxy_buffering on; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host $host; > proxy_pass_header Authorization; > # proxy_set_header X-Scheme $scheme; > # proxy_set_header Upgrade $http_upgrade; > # proxy_set_header Connection "upgrade"; > } > > location /roundcube { > proxy_pass https://172.28.10.100; > proxy_http_version 1.1; > proxy_buffering on; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host $host; > proxy_pass_header Authorization; > # proxy_set_header X-Scheme $scheme; > # proxy_set_header Upgrade $http_upgrade; > # proxy_set_header Connection "upgrade"; > } > } > > > > > -- > Eric Germann > ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com > LinkedIn: https://www.linkedin.com/in/ericgermann > Medium: https://ekgermann.medium.com > Twitter: @ekgermann > Telegram || Signal || Skype || WhatsApp || Phone +1 {dash} 419 {dash} 513 {dash} 0712 > > GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1 > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From arut at nginx.com Thu Mar 9 09:41:08 2023 From: arut at nginx.com (Roman Arutyunyan) Date: Thu, 9 Mar 2023 13:41:08 +0400 Subject: Issue with getting to HTTP/3 or QUIC on first connect In-Reply-To: References: Message-ID: Hi Eric, > On 9 Mar 2023, at 10:56, Eric Germann via nginx wrote: > > I’m having an issue where I (think I) have enabled HTTP3 correctly on my nginx server. When I connect to the server the first time, it indicates HTTP/2 in the logs. If I hit refresh it indicates HTTP/3 from then on. Normally you connect to the server using regular https first (http/2 is probably an option as well). Only after that the client analyses Alt-Svc response header and tries http/3. > So something is wrong with the configuration of the server to offer headers to negotiate it. I’ve even added HTTPS DNS records to indicate the preferred connection schemes. > Bonus points if you can help me get QUIC working too. > > The result of http3check.net is "HTTP/3 Check could not get the server's advertised QUIC versions due to the error given below. > Bad status code from server. Can you please check nginx error.log for errors? If no errors, can you please enable debugging and send the error.log to me. > Thanks in advance for any pointers > > Eric > > Source code was pulled 2023-02-27 > > > Build information is: > > nginx version: nginx/1.23.4 > built by gcc 7.3.1 20180712 (Red Hat 7.3.1-15) (GCC) > built with OpenSSL 3.0.8+quic 7 Feb 2023 > TLS SNI support enabled > configure arguments: --with-threads --with-cc-opt='-static -static-libgcc' --with-ld-opt=-static --with-debug --with-compat --with-file-aio --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-http_realip_module --with-http_secure_link_module --with-http_random_index_module --with-http_geoip_module --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-stream_quic_module --with-http_sub_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-cc-opt=-I/usr/local/include --with-ld-opt=-L/usr/local/lib --with-openssl=../quictls --with-openssl-opt=enable-tls1_3 --add-module=/source/ngx_brotli > > > Pertinent config for the server block is > > upstream httpd_backend { > server 172.28.10.91:443; > > keepalive 120; > } > > log_format quic '$remote_addr - $remote_user [$time_local] ' > '"$request" $status $body_bytes_sent ' > '"$http_referer" "$http_user_agent" "$http3"'; > > access_log logs/access.log quic; > > # NON-SSL > server { > listen 80; > listen [::]:80; > server_name www.example.com; > > location / { > rewrite ^ https://www.example.com$request_uri?/ permanent; > } > } > > # SSL > server { > listen 443 ssl http2; > listen [::]:443 ssl http2; > listen 443 http3 reuseport; > listen [::]:443 http3 reuseport; > > quic_retry on; > > server_name noc2.semperen.com; > > # Set up your cert paths > ssl_certificate_key /etc/letsencrypt/live/www.example.com/privkey.pem; > ssl_certificate /etc/letsencrypt/live/www.example.com/fullchain.pem; > ssl_trusted_certificate /etc/letsencrypt/live/www.example.com/chain.pem; > ssl_dhparam SSLKeys/dhparam.pem; > ssl_protocols TLSv1.3; > ssl_prefer_server_ciphers On; > ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:AES256+EECDH:AES256+EDH:!aNULL:!CBC; > ssl_ecdh_curve secp384r1; > ssl_early_data on; > > # enable ocsp stapling > ssl_stapling on; > ssl_stapling_verify on; > > resolver 8.8.4.4 8.8.8.8 valid=86400s; > resolver_timeout 10s; > > # upgrade to HTTP3 and HTTP2 > add_header alt-svc 'h3=":443"; ma=86400, h2=":443"; ma=86400'; > add_header alt-svc 'h2=":443"; ma=86400; persist=1'; > add_header alt-svc 'h2=":443"; ma=86400;'; > > add_header X-Frame-Options "SAMEORIGIN"; > > > # tell users to go to SSL version next time > add_header Strict-Transport-Security "max-age=31104000; includeSubdomains" always; > > # handle brotli compression > brotli on; > brotli_static on; > > # Note this is one line, even if it wraps and renders as two > brotli_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; > > brotli_buffers 16 8k; > brotli_comp_level 9; > > client_max_body_size 32M; > > error_page 502 /custom_502.html; > location = /custom_502.html { > root /usr/local/nginx/html; > internal; > } > > location / { > proxy_pass https://httpd_backend; > proxy_http_version 1.1; > proxy_buffering on; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host $host; > proxy_pass_header Authorization; > # proxy_set_header X-Scheme $scheme; > # proxy_set_header Upgrade $http_upgrade; > # proxy_set_header Connection "upgrade"; > } > > location /roundcube { > proxy_pass https://172.28.10.100; > proxy_http_version 1.1; > proxy_buffering on; > proxy_set_header X-Forwarded-For $remote_addr; > proxy_set_header X-Real-IP $remote_addr; > proxy_set_header Host $host; > proxy_pass_header Authorization; > # proxy_set_header X-Scheme $scheme; > # proxy_set_header Upgrade $http_upgrade; > # proxy_set_header Connection "upgrade"; > } > } > > > > > -- > Eric Germann > ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com > LinkedIn: https://www.linkedin.com/in/ericgermann > Medium: https://ekgermann.medium.com > Twitter: @ekgermann > Telegram || Signal || Skype || WhatsApp || Phone +1 {dash} 419 {dash} 513 {dash} 0712 > > GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1 > > > > > > > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx ---- Roman Arutyunyan arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekgermann at semperen.com Thu Mar 9 14:22:52 2023 From: ekgermann at semperen.com (Eric Germann) Date: Thu, 9 Mar 2023 09:22:52 -0500 Subject: Issue with getting to HTTP/3 or QUIC on first connect In-Reply-To: References: Message-ID: For the archives: - I pulled down latest version of nginx-quic and built it. The error seems to be resolved. First page on the site now shows http/3 - As for https://http3check.net , the reason it failed was I had the root page protected behind basic auth. Since it doesn’t send auth info, it 401’d and caused the page to throw an error. I’m going to write to them and ask them to toss up a clearer answer, whether it’s a negotiation error or a http error. Thanks for the assist. The debug log is where I found the 401 Eric > On Mar 9, 2023, at 04:41, Roman Arutyunyan wrote: > > Hi Eric, > >> On 9 Mar 2023, at 10:56, Eric Germann via nginx > wrote: >> >> I’m having an issue where I (think I) have enabled HTTP3 correctly on my nginx server. When I connect to the server the first time, it indicates HTTP/2 in the logs. If I hit refresh it indicates HTTP/3 from then on. > > Normally you connect to the server using regular https first (http/2 is probably an option as well). > Only after that the client analyses Alt-Svc response header and tries http/3. > >> So something is wrong with the configuration of the server to offer headers to negotiate it. I’ve even added HTTPS DNS records to indicate the preferred connection schemes. >> Bonus points if you can help me get QUIC working too. >> >> The result of http3check.net is "HTTP/3 Check could not get the server's advertised QUIC versions due to the error given below. >> Bad status code from server. > Can you please check nginx error.log for errors? If no errors, can you please enable debugging and send the error.log to me. > >> Thanks in advance for any pointers >> >> Eric >> >> Source code was pulled 2023-02-27 >> >> >> Build information is: >> >> nginx version: nginx/1.23.4 >> built by gcc 7.3.1 20180712 (Red Hat 7.3.1-15) (GCC) >> built with OpenSSL 3.0.8+quic 7 Feb 2023 >> TLS SNI support enabled >> configure arguments: --with-threads --with-cc-opt='-static -static-libgcc' --with-ld-opt=-static --with-debug --with-compat --with-file-aio --with-stream --with-stream_ssl_module --with-stream_ssl_preread_module --with-stream_realip_module --with-http_realip_module --with-http_secure_link_module --with-http_random_index_module --with-http_geoip_module --with-http_ssl_module --with-http_v2_module --with-http_v3_module --with-stream_quic_module --with-http_sub_module --without-mail_pop3_module --without-mail_imap_module --without-mail_smtp_module --with-cc-opt=-I/usr/local/include --with-ld-opt=-L/usr/local/lib --with-openssl=../quictls --with-openssl-opt=enable-tls1_3 --add-module=/source/ngx_brotli >> > > ---- > Roman Arutyunyan > arut at nginx.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From xeioex at nginx.com Thu Mar 9 23:43:54 2023 From: xeioex at nginx.com (Dmitry Volyntsev) Date: Thu, 9 Mar 2023 15:43:54 -0800 Subject: njs-0.7.11 Message-ID: Hello, I'm glad to announce a new release of NGINX JavaScript module (njs). Notable new features: - XMLNode API to modify XML documents: : const xml = require("xml"); : let data = `ToveJani`; : let doc = xml.parse(data); : : doc.$root.to.$attr$b = 'bar2'; : doc.$root.to.setAttribute('c', 'baz'); : delete doc.$root.to.$attr$a; : : console.log(xml.serializeToString(doc.$root.to)) : /* 'Tove' */ : : doc.$root.to.removeAllAttributes(); : doc.$root.from.$text = 'Jani2'; : : console.log(xml.serializeToString(doc)) : /* 'ToveJani2' */ : : doc.$root.to.$tags = [xml.parse(``), xml.parse(``)]; : doc.$root.to.addChild(xml.parse(``)); : : console.log(xml.serializeToString(doc.$root.to)) : /* '' */ : : doc.$root.to.removeChildren('a'); : : console.log(xml.serializeToString(doc.$root.to)) : /* '' */ Learn more about njs: - Overview and introduction: https://nginx.org/en/docs/njs/ - NGINX JavaScript in Your Web Server Configuration: https://youtu.be/Jc_L6UffFOs - Extending NGINX with Custom Code: https://youtu.be/0CVhq4AUU7M - Using node modules with njs: https://nginx.org/en/docs/njs/node_modules.html - Writing njs code using TypeScript definition files: https://nginx.org/en/docs/njs/typescript.html Feel free to try it and give us feedback on: - Github: https://github.com/nginx/njs/issues - Mailing list: https://mailman.nginx.org/mailman/listinfo/nginx-devel Additional examples and howtos can be found here: - Github: https://github.com/nginx/njs-examples Changes with njs 0.7.11 9 Mar 2023 nginx modules: *) Bugfix: added missed linking with libxml2 for the dynamic module. The bug was introduced in 0.7.10. Core: *) Feature: added XMLNode API to modify XML documents. *) Change: removed XML_PARSE_DTDVALID during parsing of XML document due to security implications. The issue was introduced in 0.7.10. When XML_PARSE_DTDVALID is enabled, libxml2 parses and executes external entities present inside an XML document. *) Bugfix: fixed the detection of await in arguments. *) Bugfix: fixed Error() instance dumping when "name" prop is not primitive. *) Bugfix: fixed array instance with a getter property dumping. *) Bugfix: fixed njs_object_property() with NJS_WHITEOUT properties. *) Bugfix: fixed func instance dumping with "name" as getter. *) Bugfix: fixed attaching of a stack to an error object. *) Bugfix: fixed String.prototype.replace() with replacement containing "$'", "$`". From citrin at citrin.ru Sat Mar 11 18:15:24 2023 From: citrin at citrin.ru (Anton Yuzhaninov) Date: Sat, 11 Mar 2023 18:15:24 +0000 Subject: ngx_mail: untagged IMAP responses Message-ID: <210f0323-76a0-0113-1208-c0f8278e6a42@citrin.ru> Hi All, Trying to setup ngx_mail proxy I've discovered that nginx doesn't like untagged responses which can be send by an IMAP servers. There was a similar question in 2013: https://mailman.nginx.org/pipermail/nginx-devel/2013-March/003477.html Given that it is a known issue and it has not been addressed I don't expect it to be supported by nginx out of the box but may be there are 3rd party patches for this I can try? -- Best Regards, Anton Yuzhaninov From mdounin at mdounin.ru Sun Mar 12 01:01:22 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Sun, 12 Mar 2023 04:01:22 +0300 Subject: ngx_mail: untagged IMAP responses In-Reply-To: <210f0323-76a0-0113-1208-c0f8278e6a42@citrin.ru> References: <210f0323-76a0-0113-1208-c0f8278e6a42@citrin.ru> Message-ID: Hello! On Sat, Mar 11, 2023 at 06:15:24PM +0000, Anton Yuzhaninov via nginx wrote: > Trying to setup ngx_mail proxy I've discovered that nginx doesn't like > untagged responses which can be send by an IMAP servers. There was a similar > question in 2013: > > https://mailman.nginx.org/pipermail/nginx-devel/2013-March/003477.html > > Given that it is a known issue and it has not been addressed I don't expect it > to be supported by nginx out of the box but may be there are 3rd party patches > for this I can try? I'm not aware of any. -- Maxim Dounin http://mdounin.ru/ From mauro.tridici at cmcc.it Sun Mar 12 19:43:27 2023 From: mauro.tridici at cmcc.it (Mauro Tridici) Date: Sun, 12 Mar 2023 20:43:27 +0100 Subject: Your opinion about a corporate proxy server to reach the magazine's website from everywhere Message-ID: <342F5826-189D-4551-B376-A6F1104DC6E8@cmcc.it> Dear users, I am a newbie and would like to know your opinion about a request I received at work. I will try to describe the problem. The company at which I work has several locations located within the same country. The company has subscribed to an online magazine that can be accessed after providing the public IP with which the various locations face the public network. Instead of providing the various public IP addresses related to each of the different locations, my boss proposed to set up a proxy server at the main work location and ask all users in the company to use that proxy to reach the magazine's site. In this way, even company users working from home can reach the magazine's website. Following are some questions: - In your opinion, is this a suggested or recommended solution? - if such a solution falls within best practices, could you point me to some links where examples of configurations are given? - from the point of view of network security, it doesn't seem to me to be very secure and I think that, for each of the users, we should create credentials for access to the proxy server (e.g. through an integration with the LDAP server), what do you think? I thank you in advance, Mauro From pchychi at gmail.com Sun Mar 12 21:04:45 2023 From: pchychi at gmail.com (Payam Chychi) Date: Sun, 12 Mar 2023 14:04:45 -0700 Subject: Your opinion about a corporate proxy server to reach the magazine's website from everywhere In-Reply-To: <342F5826-189D-4551-B376-A6F1104DC6E8@cmcc.it> References: <342F5826-189D-4551-B376-A6F1104DC6E8@cmcc.it> Message-ID: Can’t comment on what’s best for your company. If you plan to do what you described, sounds like a reasonable plan, though many others exist. You can do this using nginx + vouch to hook into an idp like Okta, and introduce an identity layer into your connection to secure authentication and authorization up. Ldap over internet is a horrible idea. Good luck, Payam On Sun, Mar 12, 2023 at 12:43 PM Mauro Tridici wrote: > > Dear users, > > I am a newbie and would like to know your opinion about a request I > received at work. > > I will try to describe the problem. > The company at which I work has several locations located within the same > country. The company has subscribed to an online magazine that can be > accessed after providing the public IP with which the various locations > face the public network. > > Instead of providing the various public IP addresses related to each of > the different locations, my boss proposed to set up a proxy server at the > main work location and ask all users in the company to use that proxy to > reach the magazine's site. > In this way, even company users working from home can reach the magazine's > website. > > Following are some questions: > > - In your opinion, is this a suggested or recommended solution? > - if such a solution falls within best practices, could you point me to > some links where examples of configurations are given? > - from the point of view of network security, it doesn't seem to me to be > very secure and I think that, for each of the users, we should create > credentials for access to the proxy server (e.g. through an integration > with the LDAP server), what do you think? > > I thank you in advance, > Mauro > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -- Payam Tarverdyan Chychi -------------- next part -------------- An HTML attachment was scrubbed... URL: From venefax at gmail.com Sun Mar 12 21:56:08 2023 From: venefax at gmail.com (Saint Michael) Date: Sun, 12 Mar 2023 17:56:08 -0400 Subject: Your opinion about a corporate proxy server to reach the magazine's website from everywhere In-Reply-To: References: <342F5826-189D-4551-B376-A6F1104DC6E8@cmcc.it> Message-ID: Performance is poor at best. Please check an identical arrangement at https://1eye.us And if the magazine uses Cloudflare, your proxy will be blocked. I haven't been able to defeat Cloudflare. On Sun, Mar 12, 2023 at 5:05 PM Payam Chychi wrote: > Can’t comment on what’s best for your company. > > If you plan to do what you described, sounds like a reasonable plan, > though many others exist. > > You can do this using nginx + vouch to hook into an idp like Okta, and > introduce an identity layer into your connection to secure authentication > and authorization up. > > Ldap over internet is a horrible idea. > > Good luck, > Payam > > On Sun, Mar 12, 2023 at 12:43 PM Mauro Tridici > wrote: > >> >> Dear users, >> >> I am a newbie and would like to know your opinion about a request I >> received at work. >> >> I will try to describe the problem. >> The company at which I work has several locations located within the same >> country. The company has subscribed to an online magazine that can be >> accessed after providing the public IP with which the various locations >> face the public network. >> >> Instead of providing the various public IP addresses related to each of >> the different locations, my boss proposed to set up a proxy server at the >> main work location and ask all users in the company to use that proxy to >> reach the magazine's site. >> In this way, even company users working from home can reach the >> magazine's website. >> >> Following are some questions: >> >> - In your opinion, is this a suggested or recommended solution? >> - if such a solution falls within best practices, could you point me to >> some links where examples of configurations are given? >> - from the point of view of network security, it doesn't seem to me to be >> very secure and I think that, for each of the users, we should create >> credentials for access to the proxy server (e.g. through an integration >> with the LDAP server), what do you think? >> >> I thank you in advance, >> Mauro >> _______________________________________________ >> nginx mailing list >> nginx at nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx >> > -- > Payam Tarverdyan Chychi > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mauro.tridici at cmcc.it Mon Mar 13 07:04:59 2023 From: mauro.tridici at cmcc.it (Mauro Tridici) Date: Mon, 13 Mar 2023 08:04:59 +0100 Subject: Your opinion about a corporate proxy server to reach the magazine's website from everywhere In-Reply-To: References: <342F5826-189D-4551-B376-A6F1104DC6E8@cmcc.it> Message-ID: Thank you Payam, for sharing your experience and suggestions. Have a great day. Mauro > On 12 Mar 2023, at 22:04, Payam Chychi wrote: > > Can’t comment on what’s best for your company. > > If you plan to do what you described, sounds like a reasonable plan, though many others exist. > > You can do this using nginx + vouch to hook into an idp like Okta, and introduce an identity layer into your connection to secure authentication and authorization up. > > Ldap over internet is a horrible idea. > > Good luck, > Payam > > On Sun, Mar 12, 2023 at 12:43 PM Mauro Tridici > wrote: > > Dear users, > > I am a newbie and would like to know your opinion about a request I received at work. > > I will try to describe the problem. > The company at which I work has several locations located within the same country. The company has subscribed to an online magazine that can be accessed after providing the public IP with which the various locations face the public network. > > Instead of providing the various public IP addresses related to each of the different locations, my boss proposed to set up a proxy server at the main work location and ask all users in the company to use that proxy to reach the magazine's site. > In this way, even company users working from home can reach the magazine's website. > > Following are some questions: > > - In your opinion, is this a suggested or recommended solution? > - if such a solution falls within best practices, could you point me to some links where examples of configurations are given? > - from the point of view of network security, it doesn't seem to me to be very secure and I think that, for each of the users, we should create credentials for access to the proxy server (e.g. through an integration with the LDAP server), what do you think? > > I thank you in advance, > Mauro > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -- > Payam Tarverdyan Chychi > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From mauro.tridici at cmcc.it Mon Mar 13 07:06:00 2023 From: mauro.tridici at cmcc.it (Mauro Tridici) Date: Mon, 13 Mar 2023 08:06:00 +0100 Subject: Your opinion about a corporate proxy server to reach the magazine's website from everywhere In-Reply-To: References: <342F5826-189D-4551-B376-A6F1104DC6E8@cmcc.it> Message-ID: <41290675-4BCF-4234-AE41-4FF9F222497C@cmcc.it> Thank you Michael for your help and for the link. Kind Regards, Mauro > On 12 Mar 2023, at 22:56, Saint Michael wrote: > > Performance is poor at best. > Please check an identical arrangement at > https://1eye.us > And if the magazine uses Cloudflare, your proxy will be blocked. > I haven't been able to defeat Cloudflare. > > > On Sun, Mar 12, 2023 at 5:05 PM Payam Chychi > wrote: > Can’t comment on what’s best for your company. > > If you plan to do what you described, sounds like a reasonable plan, though many others exist. > > You can do this using nginx + vouch to hook into an idp like Okta, and introduce an identity layer into your connection to secure authentication and authorization up. > > Ldap over internet is a horrible idea. > > Good luck, > Payam > > On Sun, Mar 12, 2023 at 12:43 PM Mauro Tridici > wrote: > > Dear users, > > I am a newbie and would like to know your opinion about a request I received at work. > > I will try to describe the problem. > The company at which I work has several locations located within the same country. The company has subscribed to an online magazine that can be accessed after providing the public IP with which the various locations face the public network. > > Instead of providing the various public IP addresses related to each of the different locations, my boss proposed to set up a proxy server at the main work location and ask all users in the company to use that proxy to reach the magazine's site. > In this way, even company users working from home can reach the magazine's website. > > Following are some questions: > > - In your opinion, is this a suggested or recommended solution? > - if such a solution falls within best practices, could you point me to some links where examples of configurations are given? > - from the point of view of network security, it doesn't seem to me to be very secure and I think that, for each of the users, we should create credentials for access to the proxy server (e.g. through an integration with the LDAP server), what do you think? > > I thank you in advance, > Mauro > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -- > Payam Tarverdyan Chychi > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.wanat at gmail.com Thu Mar 16 12:50:49 2023 From: marcin.wanat at gmail.com (Marcin Wanat) Date: Thu, 16 Mar 2023 13:50:49 +0100 Subject: Reverse proxy for upload Message-ID: Hi, i am working on nginx reverse proxy for upload gateway to speed up things worldwide. Infrastructure schema looks like this: Main upload server - EU Upload proxy servers in Asia, Australia, North America etc Upload proxy servers will be connected to main upload servers via Long Fat Network VPN - 10Gbps, but large RTT (located on different continents) Client will be sending 10GB+ files splitted to multiple 10MB POST requests with data. Local nginx proxy server should read (buffer) this request as soon as possible and immediately reply with HTTP 200, even before it will finish proxying the request to upstream. We can reply HTTP 200 before transmitted to upstream because we do not care about data consistency here, as client will verify checksum with master upload server after last piece and then resend missing pieces if anything goes wrong. We are optimizing for speed only here. My question is - is it possible with nginx that proxy server will reply to client with HTTP 200 before request is fully transmitted to upstream? Regards, Marcin From sshedi at vmware.com Thu Mar 16 18:19:42 2023 From: sshedi at vmware.com (Shreenidhi Shedi) Date: Thu, 16 Mar 2023 18:19:42 +0000 Subject: Changing ownership of proxy_temp and other temp directories Message-ID: Hi All, I have hosted a nginx server instance and the temp directories are created under /etc/nginx/ $ ls -ld /etc/nginx/*_temp drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/client_body_temp drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/fastcgi_temp drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/proxy_temp drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/scgi_temp drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/uwsgi_temp And I updated to a newer version of nginx which runs in "nginx" user context and after that these directory ownership is getting changed to nginx:root but the issue is, it happens only on these top directories and not directories within these temp directories. I did strace on the same to confirm my theory. mkdir("/etc/nginx/client_body_temp", 0700) = -1 EEXIST (File exists) stat("/etc/nginx/client_body_temp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 chown("/etc/nginx/client_body_temp", 997, -1) = 0 mkdir("/etc/nginx/proxy_temp", 0700) = -1 EEXIST (File exists) stat("/etc/nginx/proxy_temp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 chown("/etc/nginx/proxy_temp", 997, -1) = 0 mkdir("/etc/nginx/fastcgi_temp", 0700) = -1 EEXIST (File exists) stat("/etc/nginx/fastcgi_temp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 chown("/etc/nginx/fastcgi_temp", 997, -1) = 0 mkdir("/etc/nginx/uwsgi_temp", 0700) = -1 EEXIST (File exists) stat("/etc/nginx/uwsgi_temp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 chown("/etc/nginx/uwsgi_temp", 997, -1) = 0 mkdir("/etc/nginx/scgi_temp", 0700) = -1 EEXIST (File exists) stat("/etc/nginx/scgi_temp", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 Now the issue is, why chown happens only on top directory and not recursively on all files and directories inside them? Is this a bug or is it fixed in latest version of nginx? I'm currently using nginx-1.22.0. Any help would be appreciated. Thanks. -- Shedi -------------- next part -------------- An HTML attachment was scrubbed... URL: From osa at freebsd.org.ru Thu Mar 16 18:41:58 2023 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Thu, 16 Mar 2023 21:41:58 +0300 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Hi there, On Thu, Mar 16, 2023 at 06:19:42PM +0000, Shreenidhi Shedi via nginx wrote: > > I have hosted a nginx server instance and the temp directories are created > under /etc/nginx/ > > $ ls -ld /etc/nginx/*_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/client_body_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/fastcgi_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/proxy_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/scgi_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/uwsgi_temp Could you share an output of the following command: % nginx -V > I'm currently using nginx-1.22.0. Any help would be appreciated. Thanks. I assume that's official package from the following distribution point, the http://nginx.org/en/linux_packages.html. And if not, how's that nginx and packages have been built. Thank you. -- Sergey A. Osokin From sshedi at vmware.com Thu Mar 16 19:05:20 2023 From: sshedi at vmware.com (Shreenidhi Shedi) Date: Thu, 16 Mar 2023 19:05:20 +0000 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Hi, Thanks for the response. I'm using nginx from Photon OS. https://github.com/vmware/photon/blob/3.0/SPECS/nginx/nginx.spec Please see the changelog between v1.16.1-6 and v1.16.1-7 -- Shedi ________________________________ From: Sergey A. Osokin Sent: 17 March 2023 00:11 To: Shreenidhi Shedi via nginx Cc: Shreenidhi Shedi Subject: Re: Changing ownership of proxy_temp and other temp directories !! External Email Hi there, On Thu, Mar 16, 2023 at 06:19:42PM +0000, Shreenidhi Shedi via nginx wrote: > > I have hosted a nginx server instance and the temp directories are created > under /etc/nginx/ > > $ ls -ld /etc/nginx/*_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/client_body_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/fastcgi_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/proxy_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/scgi_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/uwsgi_temp Could you share an output of the following command: % nginx -V > I'm currently using nginx-1.22.0. Any help would be appreciated. Thanks. I assume that's official package from the following distribution point, the https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fnginx.org%2Fen%2Flinux_packages.html&data=05%7C01%7Csshedi%40vmware.com%7Cbfc91307f7744b86824408db264e2479%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638145889319995895%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BWlxln2Jx3yvB0wtvQtdov0FTHJknAPW1K%2BGDJ9WGeE%3D&reserved=0. And if not, how's that nginx and packages have been built. Thank you. -- Sergey A. Osokin !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From osa at freebsd.org.ru Thu Mar 16 19:41:47 2023 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Thu, 16 Mar 2023 22:41:47 +0300 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Hi, On Thu, Mar 16, 2023 at 07:05:20PM +0000, Shreenidhi Shedi wrote: > I'm using nginx from Photon OS. > https://github.com/vmware/photon/blob/3.0/SPECS/nginx/nginx.spec > > Please see the changelog between v1.16.1-6 and v1.16.1-7 Would you mind to share the following, thanks. > Could you share an output of the following command: > % nginx -V Could you also share the output of the following command: % nginx -T Thank you. -- Sergey A. Osokin From osa at freebsd.org.ru Thu Mar 16 21:16:40 2023 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Fri, 17 Mar 2023 00:16:40 +0300 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Hi, On Thu, Mar 16, 2023 at 06:19:42PM +0000, Shreenidhi Shedi via nginx wrote: > > I have hosted a nginx server instance and the temp directories are created under /etc/nginx/ > > $ ls -ld /etc/nginx/*_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/client_body_temp [...] > > And I updated to a newer version of nginx which runs in "nginx" user > context and after that these directory ownership is getting changed > to nginx:root but the issue is, it happens only on these top > directories and not directories within these temp directories. > > I did strace on the same to confirm my theory. [strace is skipped] It seems like previously nginx' worker process was running under `nobody' user, so the directory structure has appropriate permissions. The configuration setting was changed to `nginx' user then, and when nginx main process started, it checked and updated directories permissions according to the new settings. > Now the issue is, why chown happens only on top directory and > not recursively on all files and directories inside them? Please take a look in the source code, http://hg.nginx.org/nginx/file/tip/src/core/ngx_file.c#l598 > Is this a bug or is it fixed in latest version of nginx? I don't think there's a bug in that part of the code. As a workaround for the transition content to a new user, it's easy to run an one line script to update permissions of those directories. > I'm currently using nginx-1.22.0. Any help would be appreciated. I'd recommend to upgrade to the recent version in stable branch, 1.22.1. Thank you. -- Sergey A. Osokin From sshedi at vmware.com Fri Mar 17 04:42:53 2023 From: sshedi at vmware.com (Shreenidhi Shedi) Date: Fri, 17 Mar 2023 04:42:53 +0000 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Hi, Here you go. root at ph3dev:~ # nginx -V nginx version: nginx/1.22.0 built by gcc 7.3.0 (GCC) built with OpenSSL 1.0.2zg-fips 7 Feb 2023 (running with OpenSSL 1.0.2zg 7 Feb 2023) TLS SNI support enabled configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --add-module=njs-0.7.5/nginx --with-http_ssl_module --with-pcre --with-ipv6 --with-stream --with-http_auth_request_module --with-http_sub_module --with-http_stub_status_module --with-http_v2_module --user=nginx --group=nginx root at ph3dev:~ # nginx -T nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful # configuration file /etc/nginx/nginx.conf: #user nobody; worker_processes 1; #error_log logs/error.log; #error_log logs/error.log notice; #error_log logs/error.log info; #pid logs/nginx.pid; events { worker_connections 1024; } http { include mime.types; default_type application/octet-stream; #log_format main '$remote_addr - $remote_user [$time_local] "$request" ' # '$status $body_bytes_sent "$http_referer" ' # '"$http_user_agent" "$http_x_forwarded_for"'; #access_log logs/access.log main; sendfile on; #tcp_nopush on; #keepalive_timeout 0; keepalive_timeout 65; #gzip on; server { listen 80; server_name localhost; #charset koi8-r; #access_log logs/host.access.log main; location / { root html; index index.html index.htm; } #error_page 404 /404.html; # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # #location ~ \.php$ { # root html; # fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # include fastcgi_params; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} } # another virtual host using mix of IP-, name-, and port-based configuration # #server { # listen 8000; # listen somename:8080; # server_name somename alias another.alias; # location / { # root html; # index index.html index.htm; # } #} # HTTPS server # #server { # listen 443 ssl; # server_name localhost; # ssl_certificate cert.pem; # ssl_certificate_key cert.key; # ssl_session_cache shared:SSL:1m; # ssl_session_timeout 5m; # ssl_ciphers HIGH:!aNULL:!MD5; # ssl_prefer_server_ciphers on; # location / { # root html; # index index.html index.htm; # } #} } # configuration file /etc/nginx/mime.types: types { text/html html htm shtml; text/css css; text/xml xml; image/gif gif; image/jpeg jpeg jpg; application/javascript js; application/atom+xml atom; application/rss+xml rss; text/mathml mml; text/plain txt; text/vnd.sun.j2me.app-descriptor jad; text/vnd.wap.wml wml; text/x-component htc; image/avif avif; image/png png; image/svg+xml svg svgz; image/tiff tif tiff; image/vnd.wap.wbmp wbmp; image/webp webp; image/x-icon ico; image/x-jng jng; image/x-ms-bmp bmp; font/woff woff; font/woff2 woff2; application/java-archive jar war ear; application/json json; application/mac-binhex40 hqx; application/msword doc; application/pdf pdf; application/postscript ps eps ai; application/rtf rtf; application/vnd.apple.mpegurl m3u8; application/vnd.google-earth.kml+xml kml; application/vnd.google-earth.kmz kmz; application/vnd.ms-excel xls; application/vnd.ms-fontobject eot; application/vnd.ms-powerpoint ppt; application/vnd.oasis.opendocument.graphics odg; application/vnd.oasis.opendocument.presentation odp; application/vnd.oasis.opendocument.spreadsheet ods; application/vnd.oasis.opendocument.text odt; application/vnd.openxmlformats-officedocument.presentationml.presentation pptx; application/vnd.openxmlformats-officedocument.spreadsheetml.sheet xlsx; application/vnd.openxmlformats-officedocument.wordprocessingml.document docx; application/vnd.wap.wmlc wmlc; application/wasm wasm; application/x-7z-compressed 7z; application/x-cocoa cco; application/x-java-archive-diff jardiff; application/x-java-jnlp-file jnlp; application/x-makeself run; application/x-perl pl pm; application/x-pilot prc pdb; application/x-rar-compressed rar; application/x-redhat-package-manager rpm; application/x-sea sea; application/x-shockwave-flash swf; application/x-stuffit sit; application/x-tcl tcl tk; application/x-x509-ca-cert der pem crt; application/x-xpinstall xpi; application/xhtml+xml xhtml; application/xspf+xml xspf; application/zip zip; application/octet-stream bin exe dll; application/octet-stream deb; application/octet-stream dmg; application/octet-stream iso img; application/octet-stream msi msp msm; audio/midi mid midi kar; audio/mpeg mp3; audio/ogg ogg; audio/x-m4a m4a; audio/x-realaudio ra; video/3gpp 3gpp 3gp; video/mp2t ts; video/mp4 mp4; video/mpeg mpeg mpg; video/quicktime mov; video/webm webm; video/x-flv flv; video/x-m4v m4v; video/x-mng mng; video/x-ms-asf asx asf; video/x-ms-wmv wmv; video/x-msvideo avi; } -- Shedi ________________________________ From: Sergey A. Osokin Sent: 17 March 2023 02:46 To: nginx at nginx.org Cc: Shreenidhi Shedi Subject: Re: Changing ownership of proxy_temp and other temp directories !! External Email Hi, On Thu, Mar 16, 2023 at 06:19:42PM +0000, Shreenidhi Shedi via nginx wrote: > > I have hosted a nginx server instance and the temp directories are created under /etc/nginx/ > > $ ls -ld /etc/nginx/*_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/client_body_temp [...] > > And I updated to a newer version of nginx which runs in "nginx" user > context and after that these directory ownership is getting changed > to nginx:root but the issue is, it happens only on these top > directories and not directories within these temp directories. > > I did strace on the same to confirm my theory. [strace is skipped] It seems like previously nginx' worker process was running under `nobody' user, so the directory structure has appropriate permissions. The configuration setting was changed to `nginx' user then, and when nginx main process started, it checked and updated directories permissions according to the new settings. > Now the issue is, why chown happens only on top directory and > not recursively on all files and directories inside them? Please take a look in the source code, https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.nginx.org%2Fnginx%2Ffile%2Ftip%2Fsrc%2Fcore%2Fngx_file.c%23l598&data=05%7C01%7Csshedi%40vmware.com%7Ccc1606f4494b48ed496308db2663c194%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638145982140985501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BnlexAGf4iaOhxIl0GnCZOGUfufWlJyuefJOFP%2Bvb6I%3D&reserved=0 > Is this a bug or is it fixed in latest version of nginx? I don't think there's a bug in that part of the code. As a workaround for the transition content to a new user, it's easy to run an one line script to update permissions of those directories. > I'm currently using nginx-1.22.0. Any help would be appreciated. I'd recommend to upgrade to the recent version in stable branch, 1.22.1. Thank you. -- Sergey A. Osokin !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sshedi at vmware.com Fri Mar 17 05:13:24 2023 From: sshedi at vmware.com (Shreenidhi Shedi) Date: Fri, 17 Mar 2023 05:13:24 +0000 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Thanks for the response Sergey A. Osokin. The problem is these temp locations are configurable parameters. So, from a spec file perspective it's hard to fetch these parameters and change the permissions. As ngnix is already doing the task of changing permission of top directory, is there any problem the same recursively? Sorry, I'm using outlook so I don't know how to reply below your message, so it's a bit difficult. Apologies for that. -- Shedi ________________________________ From: Sergey A. Osokin Sent: 17 March 2023 02:46 To: nginx at nginx.org Cc: Shreenidhi Shedi Subject: Re: Changing ownership of proxy_temp and other temp directories !! External Email Hi, On Thu, Mar 16, 2023 at 06:19:42PM +0000, Shreenidhi Shedi via nginx wrote: > > I have hosted a nginx server instance and the temp directories are created under /etc/nginx/ > > $ ls -ld /etc/nginx/*_temp > drwx------ 2 nobody root 4096 Mar 16 15:21 /etc/nginx/client_body_temp [...] > > And I updated to a newer version of nginx which runs in "nginx" user > context and after that these directory ownership is getting changed > to nginx:root but the issue is, it happens only on these top > directories and not directories within these temp directories. > > I did strace on the same to confirm my theory. [strace is skipped] It seems like previously nginx' worker process was running under `nobody' user, so the directory structure has appropriate permissions. The configuration setting was changed to `nginx' user then, and when nginx main process started, it checked and updated directories permissions according to the new settings. > Now the issue is, why chown happens only on top directory and > not recursively on all files and directories inside them? Please take a look in the source code, https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhg.nginx.org%2Fnginx%2Ffile%2Ftip%2Fsrc%2Fcore%2Fngx_file.c%23l598&data=05%7C01%7Csshedi%40vmware.com%7Ccc1606f4494b48ed496308db2663c194%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638145982140985501%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BnlexAGf4iaOhxIl0GnCZOGUfufWlJyuefJOFP%2Bvb6I%3D&reserved=0 > Is this a bug or is it fixed in latest version of nginx? I don't think there's a bug in that part of the code. As a workaround for the transition content to a new user, it's easy to run an one line script to update permissions of those directories. > I'm currently using nginx-1.22.0. Any help would be appreciated. I'd recommend to upgrade to the recent version in stable branch, 1.22.1. Thank you. -- Sergey A. Osokin !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From osa at freebsd.org.ru Fri Mar 17 14:26:19 2023 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Fri, 17 Mar 2023 17:26:19 +0300 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Hi Shedi, On Fri, Mar 17, 2023 at 05:13:24AM +0000, Shreenidhi Shedi wrote: > Thanks for the response Sergey A. Osokin. > > The problem is these temp locations are configurable parameters. > So, from a spec file perspective it's hard to fetch these parameters > and change the permissions. > > As ngnix is already doing the task of changing permission of top > directory, is there any problem the same recursively? I don't think I see a specific reason for nginx to do that, because that may cause a delay with its start, but it's definitely possible to: o) implement a specific logic and rebuild nginx binary, also raise a request in https://trac.nginx.org/ and submit a patch; o) use other then /etc/nginx directory for temporary files, for example /var/tmp/nginx, see ./configure output for details Hope that helps. Thank you. -- Sergey A. Osokin From sshedi at vmware.com Sat Mar 18 20:31:43 2023 From: sshedi at vmware.com (Shreenidhi Shedi) Date: Sat, 18 Mar 2023 20:31:43 +0000 Subject: Changing ownership of proxy_temp and other temp directories In-Reply-To: References: Message-ID: Thanks for the inputs but if user has different paths configured for these temp files in nginx.conf; then again this permssion issue pops up. I also referred Fedora nginx spec file and considered this possibility but it's a bit complex on an already configured and running server instance. I have created a bug at https://trac.nginx.org/nginx/ticket/2469 and submitted a patch, please review it when you get time. -- Shedi ________________________________ From: Sergey A. Osokin Sent: 17 March 2023 19:56 To: Shreenidhi Shedi Cc: nginx at nginx.org Subject: Re: Changing ownership of proxy_temp and other temp directories !! External Email Hi Shedi, On Fri, Mar 17, 2023 at 05:13:24AM +0000, Shreenidhi Shedi wrote: > Thanks for the response Sergey A. Osokin. > > The problem is these temp locations are configurable parameters. > So, from a spec file perspective it's hard to fetch these parameters > and change the permissions. > > As ngnix is already doing the task of changing permission of top > directory, is there any problem the same recursively? I don't think I see a specific reason for nginx to do that, because that may cause a delay with its start, but it's definitely possible to: o) implement a specific logic and rebuild nginx binary, also raise a request in https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.nginx.org%2F&data=05%7C01%7Csshedi%40vmware.com%7C233de8ff58d24c75955908db26f3989d%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C638146599941295693%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Ldc9UpODK%2BitxiBnVrmSvXBdjwBk9HIqzRCX35Hr76w%3D&reserved=0 and submit a patch; o) use other then /etc/nginx directory for temporary files, for example /var/tmp/nginx, see ./configure output for details Hope that helps. Thank you. -- Sergey A. Osokin !! External Email: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pgnet.dev at gmail.com Mon Mar 20 17:51:47 2023 From: pgnet.dev at gmail.com (PGNet Dev) Date: Mon, 20 Mar 2023 13:51:47 -0400 Subject: failure to limit access to a secure area with self-signed client SSL cert fingerprint match Message-ID: i run nginx -v nginx version: nginx/1.23.3 (COPR Build) the server's setup to use LE certs server { ... ssl_trusted_certificate "/www/sec/le/deploy/otherexample.com/intermediate_ca.ec.crt.pem"; ssl_certificate "/www/sec/le/deploy/otherexample.com/fullchain.ec.crt.pem"; ssl_certificate_key "/www/sec/le/deploy/otherexample.com/priv.ec.key"; ... i've a secure area that i want to limit access to clients only with exact-matching ssl cert fingerprints i've added map $ssl_client_fingerprint $test_ssl_fp_reject { default 1; # cert's SHA1 FP 01234567890ABCDEFGHIJK1234567890ABCDEFGH 0; } ... log_format ssl_client '"Client fingerprint" $ssl_client_fingerprint ' '"Client DN" $ssl_client_s_dn '; ... server { ... # attempt the verify, to populate $ssl_client_fingerprint ssl_verify_client optional; ssl_verify_depth 2; ssl_client_certificate "/etc/ssl/cert.pem"; ... location /sec/test { if ($test_ssl_fp_reject) {return 403; } root /www/sec/test; try_files /test.php =444; fastcgi_pass phpfpm; fastcgi_index test.php; fastcgi_param PATH_INFO $fastcgi_script_name; include fastcgi.conf; } ... access_log /var/log/nginx/ssl.log ssl_client; the client cert's self-signed with my own CA, and usage's config'd for Client auth, openssl x509 -in desktop.example.com.client.ec.crt.pem -text -noout Certificate: Data: Version: 3 (0x2) Serial Number: 4859 (0x12fb) Signature Algorithm: ecdsa-with-SHA256 Issuer: C = US, ST = NY, O = example.com, OU = example.com_CA, CN = example.com_CA_INT, emailAddress = ssl at example.com Validity Not Before: Mar 20 11:17:47 2023 GMT Not After : Mar 17 11:17:47 2024 GMT Subject: C = US, ST = NY, L = New_York, O = example.com, OU = example.com_CA, CN = desktop.example.com, emailAddress = ssl at example.com Subject Public Key Info: Public Key Algorithm: id-ecPublicKey Public-Key: (384 bit) pub: 04:...:e5 ASN1 OID: secp384r1 NIST CURVE: P-384 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, S/MIME Netscape Comment: example.com CLIENT Certificate X509v3 Subject Key Identifier: CC:...:06 X509v3 Authority Key Identifier: D0:...:CD X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection X509v3 Subject Alternative Name: DNS:desktop.example.com, DNS:www.desktop.example.com Signature Algorithm: ecdsa-with-SHA256 Signature Value: 30:...:6f i've imported the cert as .pfx into Firefox & Chrome. i can access https://otherexample.com as usual. now, on access to EITHER of https://otherexample.com https://otherexample.com/sec/test in browser i get 400 Bad Request The SSL certificate error nginx while in log, i _do_ see the captured FP & DN, tail -f /var/log/nginx/ssl.log "Client fingerprint" 01234567890ABCDEFGHIJK1234567890ABCDEFGH "Client DN" emailAddress=ssl at example.com,CN=desktop.example.com,OU=example.com_CA,O=example.com,L=New_York,ST=NY,C=US if i toggle - ssl_verify_client optional; + ssl_verify_client off; now, access to https://otherexample.com works. but https://otherexample.com/sec/test returns 403 Forbidden nginx since the $ssl_client_fingerprint doesn't populate tail -f /var/log/nginx/ssl.log "Client fingerprint" - "Client DN" - and, if I turn off ALL client verification, then access to frontend and by secure area works as expected. what config change's needed to (1) keep the site publicly accessible using the LE certs" (2) lock down to secure area for exact FP-match access only? From lance at wordkeeper.com Tue Mar 21 21:06:00 2023 From: lance at wordkeeper.com (Lance Dockins) Date: Tue, 21 Mar 2023 16:06:00 -0500 Subject: How to compile Nginx with zlib-ng In-Reply-To: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> Message-ID: <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Has anyone had success compiling Nginx with zlib-ng instead of default Zlib versions?  I seem to be able to compile Nginx with standard Zlib and various other Zlib libraries (e.g. Intel optimized or Cloudflare) but compiling with Zlib-NG always fails.  I’ve tried passing in various options via with-zlib-opt to try to include the —zlib-compat flag for the Zlib NG configure directives but no matter what syntax I use, it seems like it always fails (whether I have that param or not).  Perhaps I’m just struggling with the proper use of Zlib NG in an Nginx compile context. If Nginx should compile with Zlib NG, is there any documentation on what params to use in the Nginx compile command to get it to work? -- Lance Dockins -------------- next part -------------- An HTML attachment was scrubbed... URL: From francis at daoine.org Tue Mar 21 21:48:44 2023 From: francis at daoine.org (Francis Daly) Date: Tue, 21 Mar 2023 21:48:44 +0000 Subject: failure to limit access to a secure area with self-signed client SSL cert fingerprint match In-Reply-To: References: Message-ID: <20230321214844.GC6170@daoine.org> On Mon, Mar 20, 2023 at 01:51:47PM -0400, PGNet Dev wrote: Hi there, > now, on access to EITHER of > > https://otherexample.com > https://otherexample.com/sec/test > > in browser i get > > 400 Bad Request > The SSL certificate error > nginx What does the error_log say about this request and response? It looks like some part of your nginx/tls setup fails to verify the client certificate; maybe the debug or info log will hint at why. Good luck with it, f -- Francis Daly francis at daoine.org From pgnet.dev at gmail.com Tue Mar 21 23:02:23 2023 From: pgnet.dev at gmail.com (PGNet Dev) Date: Tue, 21 Mar 2023 19:02:23 -0400 Subject: failure to limit access to a secure area with self-signed client SSL cert fingerprint match In-Reply-To: <20230321214844.GC6170@daoine.org> References: <20230321214844.GC6170@daoine.org> Message-ID: <4017fae1-88bd-1301-7bae-c7ea19d189ad@gmail.com> > What does the error_log say about this request and response? nothing that's giving me a hint i recognize, ... 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 header: "cache-control: no-cache" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 encoded string, len:2 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 encoded string, len:6 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 table add: "te: trailers" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 table account: 42 free:2775 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 header: "te: trailers" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 request line: "GET / HTTP/2.0" 2023/03/21 18:52:14 [info] 4955#4955: *7 client SSL certificate verify error: certificate status request failed while reading client request headers, client: 2401::...::1, server: example.com, request: "GET / HTTP/2.0", host: "example.com" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http finalize request: 495, "/?" a:1, c:1 2023/03/21 18:52:14 [debug] 4955#4955: *7 http special response: 495, "/?" 2023/03/21 18:52:14 [debug] 4955#4955: *7 headers more header filter, uri "/" 2023/03/21 18:52:14 [debug] 4955#4955: *7 xslt filter header 2023/03/21 18:52:14 [debug] 4955#4955: *7 charset: "" > "utf-8" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 header filter 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 push resources 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 table size update: 0 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: ":status: 400" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "date: Tue, 21 Mar 2023 22:52:14 GMT" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "content-type: text/html; charset=utf-8" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "content-length: 208" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "secure: Server" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "x-robots-tag: noindex, nofollow, nosnippet, noarchive" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "x-download-options: noopen" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "x-permitted-cross-domain-policies: none" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "permissions-policy: interest-cohort=()" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "x-xss-protection: 1; mode=block" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "strict-transport-security: max-age=63072000; includeSubDomains; preload" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "x-frame-options: SAMEORIGIN" 2023/03/21 18:52:14 [debug] 4955#4955: *7 http2 output header: "referrer-policy: strict-origin-when-cross-origin" ... From francis at daoine.org Wed Mar 22 00:54:00 2023 From: francis at daoine.org (Francis Daly) Date: Wed, 22 Mar 2023 00:54:00 +0000 Subject: failure to limit access to a secure area with self-signed client SSL cert fingerprint match In-Reply-To: <4017fae1-88bd-1301-7bae-c7ea19d189ad@gmail.com> References: <20230321214844.GC6170@daoine.org> <4017fae1-88bd-1301-7bae-c7ea19d189ad@gmail.com> Message-ID: <20230322005400.GD6170@daoine.org> On Tue, Mar 21, 2023 at 07:02:23PM -0400, PGNet Dev wrote: > > What does the error_log say about this request and response? > 2023/03/21 18:52:14 [info] 4955#4955: *7 client SSL certificate verify error: certificate status request failed while reading client request headers, client: 2401::...::1, server: example.com, request: "GET / HTTP/2.0", host: "example.com" That'll be why nginx blocks the access, at least -- the client cert is not verified as good. You have indicated that the client cert has: Issuer: C = US, ST = NY, O = example.com, OU = example.com_CA, CN = example.com_CA_INT, emailAddress = ssl at example.com Do you have the certificate that has that value as the Subject? What is that certificate's Issuer? And repeat until you get to the root certificate. And which of the ssl*certificate files named in your config holds those certificates? f -- Francis Daly francis at daoine.org From pgnet.dev at gmail.com Wed Mar 22 12:48:50 2023 From: pgnet.dev at gmail.com (PGNet Dev) Date: Wed, 22 Mar 2023 08:48:50 -0400 Subject: failure to limit access to a secure area with self-signed client SSL cert fingerprint match In-Reply-To: <20230322005400.GD6170@daoine.org> References: <20230321214844.GC6170@daoine.org> <4017fae1-88bd-1301-7bae-c7ea19d189ad@gmail.com> <20230322005400.GD6170@daoine.org> Message-ID: > Do you have the certificate that has that value as the Subject? What > is that certificate's Issuer? And repeat until you get to the root > certificate. > > And which of the ssl*certificate files named in your config holds those certificates? i verified all my certs/chains. all good. with my orig conf, it appears i can't manage to grab/verify ssl client FP's for other-than-primary domains this fails to work, errors as reported above, server { ... servername example.com; ssl_verify_client optional; ssl_verify_depth 2; ssl_client_certificate "/www/ssl/self-signed/myCA.CHAIN.crt.pem"; ssl_trusted_certificate "/www/ssl/le/deploy/example.com/intermediate_ca.ec.crt.pem"; ssl_certificate "/www/ssl/le/deploy/example.com/fullchain.ec.crt.pem"; ssl_certificate_key "/www/ssl/le/deploy/example.com/priv.ec.key"; location /test { if ($ssl_client_verify != SUCCESS) { return 403; } if ($test_ssl_fp_reject) {return 403; } ... } OTOH simply splitting the secure subdir out into a separate server{}/subdomain, with separate, self-signed cert server { ... servername example.com; ssl_verify_client off; ssl_trusted_certificate "/www/ssl/le/deploy/example.com/intermediate_ca.ec.crt.pem"; ssl_certificate "/www/ssl/le/deploy/example.com/fullchain.ec.crt.pem"; ssl_certificate_key "/www/ssl/le/deploy/example.com/priv.ec.key"; } server { servername test.example.com; ssl_verify_client on; ssl_client_certificate "/www/ssl/self-signed/myCA.CHAIN.crt.pem"; ssl_verify_depth 2; ssl_certificate "/www/ssl/self-signed/test.example.com.server.ec.crt.pem"; ssl_certificate_key "/www/ssl/self-signed/test.example.com.ec.key.pem"; location / { if ($ssl_client_verify != SUCCESS) { return 403; } if ($test_ssl_fp_reject) {return 403; } ... } ... } achieves the intended result -- just not in the same server{} block From osa at freebsd.org.ru Wed Mar 22 14:49:49 2023 From: osa at freebsd.org.ru (Sergey A. Osokin) Date: Wed, 22 Mar 2023 17:49:49 +0300 Subject: How to compile Nginx with zlib-ng In-Reply-To: <078b9cb1-2e76-400b-a43b-f53971467897@Spark> References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: Hi Lance, thanks for your question. Since this is more or less related to nginx development or new features I'd suggest to use nginx-devel mailing list instead, thank you. On Tue, Mar 21, 2023 at 04:06:00PM -0500, Lance Dockins wrote: > > Has anyone had success compiling Nginx with zlib-ng instead of > default Zlib versions?  I seem to be able to compile Nginx with > standard Zlib and various other Zlib libraries (e.g. Intel > optimized or Cloudflare) but compiling with Zlib-NG always fails. NGINX builds well with zlib. In case of new functionality, like an ability to build with zlib-ng, the source code requires some patches. > I’ve tried passing in various options via with-zlib-opt to try > to include the —zlib-compat flag for the Zlib NG configure > directives but no matter what syntax I use, it seems like it > always fails (whether I have that param or not).  Perhaps I’m > just struggling with the proper use of Zlib NG in an Nginx > compile context. > > If Nginx should compile with Zlib NG, is there any documentation > on what params to use in the Nginx compile command to get it to > work? Some ideas can be found inside the zlib-ng project on GH, not sure is that working solution or not, so you can try. I'd also recommend to raise a request in https://trac.nginx.org/nginx/ about this feature request and provide patches for source code and documentation. Thank you. -- Sergey A. Osokin From r1ch+nginx at teamliquid.net Wed Mar 22 22:28:15 2023 From: r1ch+nginx at teamliquid.net (Richard Stanway) Date: Wed, 22 Mar 2023 23:28:15 +0100 Subject: How to compile Nginx with zlib-ng In-Reply-To: References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: I regularly build with zlib-ng, unfortunately it requires patching the zlib-ng files to enable zlib compatibility mode as nginx doesn't seem to have a way to pass options to configure. Edit "configure" in the zlib-ng directory and change the line compat=0 to compat=1. Then specify --with-zlib=/path/to/zlib-ng in your nginx configure and you should be set. Be aware that the memory requirements of zlib-ng have changed since support for it was added to nginx, so you will see a lot of "gzip filter failed to use preallocated memory" alerts in your log file when using zlib-ng. On Wed, 22 Mar 2023 at 15:50, Sergey A. Osokin wrote: > Hi Lance, > > thanks for your question. > > Since this is more or less related to nginx development or > new features I'd suggest to use nginx-devel mailing list > instead, thank you. > > On Tue, Mar 21, 2023 at 04:06:00PM -0500, Lance Dockins wrote: > > > > Has anyone had success compiling Nginx with zlib-ng instead of > > default Zlib versions? I seem to be able to compile Nginx with > > standard Zlib and various other Zlib libraries (e.g. Intel > > optimized or Cloudflare) but compiling with Zlib-NG always fails. > > NGINX builds well with zlib. In case of new functionality, like > an ability to build with zlib-ng, the source code requires some > patches. > > > I’ve tried passing in various options via with-zlib-opt to try > > to include the —zlib-compat flag for the Zlib NG configure > > directives but no matter what syntax I use, it seems like it > > always fails (whether I have that param or not). Perhaps I’m > > just struggling with the proper use of Zlib NG in an Nginx > > compile context. > > > > If Nginx should compile with Zlib NG, is there any documentation > > on what params to use in the Nginx compile command to get it to > > work? > > Some ideas can be found inside the zlib-ng project on GH, not > sure is that working solution or not, so you can try. > > I'd also recommend to raise a request in https://trac.nginx.org/nginx/ > about this feature request and provide patches for source code > and documentation. > > Thank you. > > -- > Sergey A. Osokin > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance at wordkeeper.com Thu Mar 23 03:16:03 2023 From: lance at wordkeeper.com (Lance Dockins) Date: Wed, 22 Mar 2023 22:16:03 -0500 Subject: How to compile Nginx with zlib-ng In-Reply-To: References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: Thank you, Richard.  I’ll give that a shot.   I already have to do that sort of patching with a variety of other things in the build that I use so that particular adjustment isn’t too bad. Just for clarity, are you saying that the hash sizes within zlib-ng have increased since Maxim’s last patch for that to accommodate zlib-ng?  That patch was back in 2021 and is part of Nginx core now. https://mailman.nginx.org/pipermail/nginx-devel/2021-April/013945.html I think it’s coded to use a 128k hash per that patch.  If the hash size has increased again since that patch, that might justify a bug report to Nginx devel.  Since the code in that patch specifically relates to that error, I thought I’d ask in case you have still been seeing that error with newer Nginx versions that have come out since that patch was implemented. -- Lance On Mar 22, 2023 at 5:28 PM -0500, Richard Stanway via nginx , wrote: > I regularly build with zlib-ng, unfortunately it requires patching the zlib-ng files to enable zlib compatibility mode as nginx doesn't seem to have a way to pass options to configure. > > Edit "configure" in the zlib-ng directory and change the line compat=0 to compat=1. Then specify --with-zlib=/path/to/zlib-ng in your nginx configure and you should be set. > > Be aware that the memory requirements of zlib-ng have changed since support for it was added to nginx, so you will see a lot of "gzip filter failed to use preallocated memory" alerts in your log file when using zlib-ng. > > > > On Wed, 22 Mar 2023 at 15:50, Sergey A. Osokin wrote: > > > Hi Lance, > > > > > > thanks for your question. > > > > > > Since this is more or less related to nginx development or > > > new features I'd suggest to use nginx-devel mailing list > > > instead, thank you. > > > > > > On Tue, Mar 21, 2023 at 04:06:00PM -0500, Lance Dockins wrote: > > > > > > > > Has anyone had success compiling Nginx with zlib-ng instead of > > > > default Zlib versions?  I seem to be able to compile Nginx with > > > > standard Zlib and various other Zlib libraries (e.g. Intel > > > > optimized or Cloudflare) but compiling with Zlib-NG always fails. > > > > > > NGINX builds well with zlib.  In case of new functionality, like > > > an ability to build with zlib-ng, the source code requires some > > > patches. > > > > > > > I’ve tried passing in various options via with-zlib-opt to try > > > > to include the —zlib-compat flag for the Zlib NG configure > > > > directives but no matter what syntax I use, it seems like it > > > > always fails (whether I have that param or not).  Perhaps I’m > > > > just struggling with the proper use of Zlib NG in an Nginx > > > > compile context. > > > > > > > > If Nginx should compile with Zlib NG, is there any documentation > > > > on what params to use in the Nginx compile command to get it to > > > > work? > > > > > > Some ideas can be found inside the zlib-ng project on GH, not > > > sure is that working solution or not, so you can try. > > > > > > I'd also recommend to raise a request in https://trac.nginx.org/nginx/ > > > about this feature request and provide patches for source code > > > and documentation. > > > > > > Thank you. > > > > > > -- > > > Sergey A. Osokin > > > _______________________________________________ > > > nginx mailing list > > > nginx at nginx.org > > > https://mailman.nginx.org/mailman/listinfo/nginx > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx -------------- next part -------------- An HTML attachment was scrubbed... URL: From r1ch+nginx at teamliquid.net Thu Mar 23 20:33:19 2023 From: r1ch+nginx at teamliquid.net (Richard Stanway) Date: Thu, 23 Mar 2023 21:33:19 +0100 Subject: How to compile Nginx with zlib-ng In-Reply-To: References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: Yes, when using the latest zlib-ng on nginx-1.21.6 I received the alerts. Previous versions of zlib-ng have worked great after the 2021 patch. I tried to update it myself as follows based on advice of zlib-ng GitHub issues, while it reduced the number of alerts logged it did not completely solve the issue so it seems the memory requirements may have further changed. While I would appreciate a proper patch making it into nginx, the seemingly-frequent upstream changes may make this difficult to maintain. - ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) + ctx->allocated = 8192 + 288 + 16 + (1 << (wbits + 2)) + 131072 + (1 << (memlevel + 8)); On Thu, 23 Mar 2023 at 04:16, Lance Dockins wrote: > > Thank you, Richard. I’ll give that a shot. I already have to do that sort of patching with a variety of other things in the build that I use so that particular adjustment isn’t too bad. > > Just for clarity, are you saying that the hash sizes within zlib-ng have increased since Maxim’s last patch for that to accommodate zlib-ng? That patch was back in 2021 and is part of Nginx core now. > https://mailman.nginx.org/pipermail/nginx-devel/2021-April/013945.html > > I think it’s coded to use a 128k hash per that patch. If the hash size has increased again since that patch, that might justify a bug report to Nginx devel. Since the code in that patch specifically relates to that error, I thought I’d ask in case you have still been seeing that error with newer Nginx versions that have come out since that patch was implemented. > > > -- > Lance > > On Mar 22, 2023 at 5:28 PM -0500, Richard Stanway via nginx , wrote: > > I regularly build with zlib-ng, unfortunately it requires patching the zlib-ng files to enable zlib compatibility mode as nginx doesn't seem to have a way to pass options to configure. > > Edit "configure" in the zlib-ng directory and change the line compat=0 to compat=1. Then specify --with-zlib=/path/to/zlib-ng in your nginx configure and you should be set. > > Be aware that the memory requirements of zlib-ng have changed since support for it was added to nginx, so you will see a lot of "gzip filter failed to use preallocated memory" alerts in your log file when using zlib-ng. > > > On Wed, 22 Mar 2023 at 15:50, Sergey A. Osokin wrote: >> >> Hi Lance, >> >> thanks for your question. >> >> Since this is more or less related to nginx development or >> new features I'd suggest to use nginx-devel mailing list >> instead, thank you. >> >> On Tue, Mar 21, 2023 at 04:06:00PM -0500, Lance Dockins wrote: >> > >> > Has anyone had success compiling Nginx with zlib-ng instead of >> > default Zlib versions? I seem to be able to compile Nginx with >> > standard Zlib and various other Zlib libraries (e.g. Intel >> > optimized or Cloudflare) but compiling with Zlib-NG always fails. >> >> NGINX builds well with zlib. In case of new functionality, like >> an ability to build with zlib-ng, the source code requires some >> patches. >> >> > I’ve tried passing in various options via with-zlib-opt to try >> > to include the —zlib-compat flag for the Zlib NG configure >> > directives but no matter what syntax I use, it seems like it >> > always fails (whether I have that param or not). Perhaps I’m >> > just struggling with the proper use of Zlib NG in an Nginx >> > compile context. >> > >> > If Nginx should compile with Zlib NG, is there any documentation >> > on what params to use in the Nginx compile command to get it to >> > work? >> >> Some ideas can be found inside the zlib-ng project on GH, not >> sure is that working solution or not, so you can try. >> >> I'd also recommend to raise a request in https://trac.nginx.org/nginx/ >> about this feature request and provide patches for source code >> and documentation. >> >> Thank you. >> >> -- >> Sergey A. Osokin >> _______________________________________________ >> nginx mailing list >> nginx at nginx.org >> https://mailman.nginx.org/mailman/listinfo/nginx > > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx From francis at daoine.org Thu Mar 23 21:58:27 2023 From: francis at daoine.org (Francis Daly) Date: Thu, 23 Mar 2023 21:58:27 +0000 Subject: failure to limit access to a secure area with self-signed client SSL cert fingerprint match In-Reply-To: References: <20230321214844.GC6170@daoine.org> <4017fae1-88bd-1301-7bae-c7ea19d189ad@gmail.com> <20230322005400.GD6170@daoine.org> Message-ID: <20230323215827.GE6170@daoine.org> On Wed, Mar 22, 2023 at 08:48:50AM -0400, PGNet Dev wrote: Hi there, > > Do you have the certificate that has that value as the Subject? What > > is that certificate's Issuer? And repeat until you get to the root > > certificate. > > > > And which of the ssl*certificate files named in your config holds those certificates? > > i verified all my certs/chains. all good. You verified things in your way, and saw they were good. The nginx logs you provided indicated that nginx verified things in its way, and saw they were not good. It seems like you have a system that works for you now, and that is good. If you want to keep testing for another system, then based on what you reported, and what you provided here, my guess is that your client certificate does verify against whatever is in myCA.CHAIN.crt.pem, and does not verify against whatever is in intermediate_ca.ec.crt.pem. So I suspect that if you put the contents of those two files into a single file, and then refer to that either as ssl_client_certificate or as ssl_trusted_certificate, and do not use the other directive at all; then things might work more like you want. Good luck with it, f -- Francis Daly francis at daoine.org From mdounin at mdounin.ru Fri Mar 24 02:07:22 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Fri, 24 Mar 2023 05:07:22 +0300 Subject: How to compile Nginx with zlib-ng In-Reply-To: References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: Hello! On Thu, Mar 23, 2023 at 09:33:19PM +0100, Richard Stanway via nginx wrote: > Yes, when using the latest zlib-ng on nginx-1.21.6 I received the > alerts. Previous versions of zlib-ng have worked great after the 2021 > patch. I tried to update it myself as follows based on advice of > zlib-ng GitHub issues, while it reduced the number of alerts logged it > did not completely solve the issue so it seems the memory requirements > may have further changed. While I would appreciate a proper patch > making it into nginx, the seemingly-frequent upstream changes may make > this difficult to maintain. > > - ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > + ctx->allocated = 8192 + 288 + 16 + (1 << (wbits + 2)) > + 131072 + (1 << (memlevel + 8)); It looks like there are at least two changes in zlib-ng since I looked into it: - Window bits are no longer forced to 13 on compression level 1. - All allocations use custom alloc_aligned() wrapper, and therefore all allocations are larger than expected by (64 + sizeof(void*)). Further, due to the wrapper nginx sees all allocations as an allocation of 1 element of a given size, so it misinterprets some allocations as the state allocation. For example, allocations for a 1k responses are as follows (note "a:8192" in most of the lines, that is, nginx thinks these are state allocations): 2023/03/24 03:26:10 [debug] 36809#100069: *2 http gzip filter 2023/03/24 03:26:10 [debug] 36809#100069: *2 malloc: 21DEE5C0:176144 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:6036 a:8192 p:21DEE5C0 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:4180 a:8192 p:21DF05C0 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:4164 a:8192 p:21DF25C0 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:131140 a:131140 p:21DF45C0 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:4164 a:8192 p:21E14604 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip in: 21C31D84 Allocations for 4k response are as follows (and generate an alert): 2023/03/24 03:44:29 [debug] 36863#100652: *2 http gzip filter 2023/03/24 03:44:29 [debug] 36863#100652: *2 malloc: 21DEE5C0:188432 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:6036 a:8192 p:21DEE5C0 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:16468 a:16468 p:21DF05C0 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:16452 a:16452 p:21DF4614 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:131140 a:131140 p:21DF8658 2023/03/24 03:44:29 [alert] 36863#100652: *2 gzip filter failed to use preallocated memory: 16452 of 16180 while sending response to client, client: 127.0.0.1, server: one, request: "GET /t/4k HTTP/1.1", host: "127.0.0.1:8080" 2023/03/24 03:44:29 [debug] 36863#100652: *2 malloc: 21DC58C0:16452 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip in: 21C31D98 The "+ 288" you are using should be enough to cover additional memory used for alignment, but it is not enough to account for misinterpretation when using gzip_comp_level above 1 (so nginx won't allocate additional memory assuming window bits will be adjusted to 13). Please try the following patch, it should help with recent versions: # HG changeset patch # User Maxim Dounin # Date 1679622670 -10800 # Fri Mar 24 04:51:10 2023 +0300 # Node ID 67a0999550c3622e51639acb8bde57d199826f7e # Parent d1cf09451ae84b930ce66fa6d63ae3f7eeeac5a5 Gzip: compatibility with recent zlib-ng versions. It now uses custom alloc_aligned() wrapper for all allocations, therefore all allocations are larger than expected by (64 + sizeof(void*)). Further, they are seen as allocations of 1 element. Relevant calculations were adjusted to reflect this, and state allocation is now protected with a flag to avoid misinterpreting other allocations as the zlib deflate_state allocation. Further, it no longer forces window bits to 13 on compression level 1, so the comment was adjusted to reflect this. diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c --- a/src/http/modules/ngx_http_gzip_filter_module.c +++ b/src/http/modules/ngx_http_gzip_filter_module.c @@ -57,6 +57,7 @@ typedef struct { unsigned nomem:1; unsigned buffering:1; unsigned zlib_ng:1; + unsigned state_allocated:1; size_t zin; size_t zout; @@ -514,9 +515,10 @@ ngx_http_gzip_filter_memory(ngx_http_req } else { /* * Another zlib variant, https://github.com/zlib-ng/zlib-ng. - * It forces window bits to 13 for fast compression level, - * uses 16-byte padding in one of window-sized buffers, and - * uses 128K hash. + * It used to force window bits to 13 for fast compression level, + * uses (64 + sizeof(void*)) additional space on all allocations + * for alignment, 16-byte padding in one of window-sized buffers, + * and 128K hash. */ if (conf->level == 1) { @@ -524,7 +526,8 @@ ngx_http_gzip_filter_memory(ngx_http_req } ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) - + 131072 + (1 << (memlevel + 8)); + + 131072 + (1 << (memlevel + 8)) + + 4 * (64 + sizeof(void*)); ctx->zlib_ng = 1; } } @@ -926,13 +929,16 @@ ngx_http_gzip_filter_alloc(void *opaque, alloc = items * size; - if (items == 1 && alloc % 512 != 0 && alloc < 8192) { - + if (items == 1 && alloc % 512 != 0 && alloc < 8192 + && !ctx->state_allocated) + { /* * The zlib deflate_state allocation, it takes about 6K, * we allocate 8K. Other allocations are divisible by 512. */ + ctx->state_allocated = 1; + alloc = 8192; } -- Maxim Dounin http://mdounin.ru/ From r1ch+nginx at teamliquid.net Fri Mar 24 14:33:02 2023 From: r1ch+nginx at teamliquid.net (Richard Stanway) Date: Fri, 24 Mar 2023 15:33:02 +0100 Subject: How to compile Nginx with zlib-ng In-Reply-To: References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: Thanks for the patch! I've been running it for about an hour and haven't seen the preallocated memory alert since, so it's looking good here. On Fri, 24 Mar 2023 at 03:07, Maxim Dounin wrote: > > Hello! > > On Thu, Mar 23, 2023 at 09:33:19PM +0100, Richard Stanway via nginx wrote: > > > Yes, when using the latest zlib-ng on nginx-1.21.6 I received the > > alerts. Previous versions of zlib-ng have worked great after the 2021 > > patch. I tried to update it myself as follows based on advice of > > zlib-ng GitHub issues, while it reduced the number of alerts logged it > > did not completely solve the issue so it seems the memory requirements > > may have further changed. While I would appreciate a proper patch > > making it into nginx, the seemingly-frequent upstream changes may make > > this difficult to maintain. > > > > - ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > > + ctx->allocated = 8192 + 288 + 16 + (1 << (wbits + 2)) > > + 131072 + (1 << (memlevel + 8)); > > It looks like there are at least two changes in zlib-ng since I > looked into it: > > - Window bits are no longer forced to 13 on compression level 1. > > - All allocations use custom alloc_aligned() wrapper, and > therefore all allocations are larger than expected by (64 + > sizeof(void*)). > > Further, due to the wrapper nginx sees all allocations as an > allocation of 1 element of a given size, so it misinterprets > some allocations as the state allocation. > > For example, allocations for a 1k responses are as follows (note > "a:8192" in most of the lines, that is, nginx thinks these are > state allocations): > > 2023/03/24 03:26:10 [debug] 36809#100069: *2 http gzip filter > 2023/03/24 03:26:10 [debug] 36809#100069: *2 malloc: 21DEE5C0:176144 > 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:6036 a:8192 p:21DEE5C0 > 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:4180 a:8192 p:21DF05C0 > 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:4164 a:8192 p:21DF25C0 > 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:131140 a:131140 p:21DF45C0 > 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip alloc: n:1 s:4164 a:8192 p:21E14604 > 2023/03/24 03:26:10 [debug] 36809#100069: *2 gzip in: 21C31D84 > > Allocations for 4k response are as follows (and generate an > alert): > > 2023/03/24 03:44:29 [debug] 36863#100652: *2 http gzip filter > 2023/03/24 03:44:29 [debug] 36863#100652: *2 malloc: 21DEE5C0:188432 > 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:6036 a:8192 p:21DEE5C0 > 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:16468 a:16468 p:21DF05C0 > 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:16452 a:16452 p:21DF4614 > 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip alloc: n:1 s:131140 a:131140 p:21DF8658 > 2023/03/24 03:44:29 [alert] 36863#100652: *2 gzip filter failed to use preallocated memory: 16452 of 16180 while sending response to client, client: 127.0.0.1, server: one, request: "GET /t/4k HTTP/1.1", host: "127.0.0.1:8080" > 2023/03/24 03:44:29 [debug] 36863#100652: *2 malloc: 21DC58C0:16452 > 2023/03/24 03:44:29 [debug] 36863#100652: *2 gzip in: 21C31D98 > > The "+ 288" you are using should be enough to cover additional > memory used for alignment, but it is not enough to account > for misinterpretation when using gzip_comp_level above 1 (so nginx > won't allocate additional memory assuming window bits will be > adjusted to 13). > > Please try the following patch, it should help with recent versions: > > # HG changeset patch > # User Maxim Dounin > # Date 1679622670 -10800 > # Fri Mar 24 04:51:10 2023 +0300 > # Node ID 67a0999550c3622e51639acb8bde57d199826f7e > # Parent d1cf09451ae84b930ce66fa6d63ae3f7eeeac5a5 > Gzip: compatibility with recent zlib-ng versions. > > It now uses custom alloc_aligned() wrapper for all allocations, > therefore all allocations are larger than expected by (64 + sizeof(void*)). > Further, they are seen as allocations of 1 element. Relevant calculations > were adjusted to reflect this, and state allocation is now protected > with a flag to avoid misinterpreting other allocations as the zlib > deflate_state allocation. > > Further, it no longer forces window bits to 13 on compression level 1, > so the comment was adjusted to reflect this. > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > --- a/src/http/modules/ngx_http_gzip_filter_module.c > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > @@ -57,6 +57,7 @@ typedef struct { > unsigned nomem:1; > unsigned buffering:1; > unsigned zlib_ng:1; > + unsigned state_allocated:1; > > size_t zin; > size_t zout; > @@ -514,9 +515,10 @@ ngx_http_gzip_filter_memory(ngx_http_req > } else { > /* > * Another zlib variant, https://github.com/zlib-ng/zlib-ng. > - * It forces window bits to 13 for fast compression level, > - * uses 16-byte padding in one of window-sized buffers, and > - * uses 128K hash. > + * It used to force window bits to 13 for fast compression level, > + * uses (64 + sizeof(void*)) additional space on all allocations > + * for alignment, 16-byte padding in one of window-sized buffers, > + * and 128K hash. > */ > > if (conf->level == 1) { > @@ -524,7 +526,8 @@ ngx_http_gzip_filter_memory(ngx_http_req > } > > ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > - + 131072 + (1 << (memlevel + 8)); > + + 131072 + (1 << (memlevel + 8)) > + + 4 * (64 + sizeof(void*)); > ctx->zlib_ng = 1; > } > } > @@ -926,13 +929,16 @@ ngx_http_gzip_filter_alloc(void *opaque, > > alloc = items * size; > > - if (items == 1 && alloc % 512 != 0 && alloc < 8192) { > - > + if (items == 1 && alloc % 512 != 0 && alloc < 8192 > + && !ctx->state_allocated) > + { > /* > * The zlib deflate_state allocation, it takes about 6K, > * we allocate 8K. Other allocations are divisible by 512. > */ > > + ctx->state_allocated = 1; > + > alloc = 8192; > } > > > -- > Maxim Dounin > http://mdounin.ru/ > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx From vilius.sumskas at rivile.lt Mon Mar 27 15:24:06 2023 From: vilius.sumskas at rivile.lt (=?utf-8?B?VmlsaXVzIMWgdW1za2Fz?=) Date: Mon, 27 Mar 2023 15:24:06 +0000 Subject: nginx configuration variable interpolation Message-ID: Hello, I have the following directive in Nginx configuration: location /docs { add_header Access-Control-Allow-Origin $cors_origin; } $cors_origin comes from the map {} where the value is set to * or something else. I have noticed that if $cors_origin is set to 0, add_header doesn’t add Access-Control-Allow-Origin header at all. Is this expected? I don’t see anything about such behaviour in the add_header documentation. -- Best Regards, Vilius -------------- next part -------------- An HTML attachment was scrubbed... URL: From mdounin at mdounin.ru Mon Mar 27 16:08:37 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Mar 2023 19:08:37 +0300 Subject: nginx configuration variable interpolation In-Reply-To: References: Message-ID: Hello! On Mon, Mar 27, 2023 at 03:24:06PM +0000, Vilius Šumskas wrote: > I have the following directive in Nginx configuration: > > location /docs { > add_header Access-Control-Allow-Origin $cors_origin; > } > > $cors_origin comes from the map {} where the value is set to * or something else. > > I have noticed that if $cors_origin is set to 0, add_header > doesn’t add Access-Control-Allow-Origin header at all. Is this > expected? I don’t see anything about such behaviour in the > add_header documentation. The header will not be added if the value is an empty string. If it is not empty but "0", the header will be added just fine. For example, consider the following configuration: map $uri $cors_origin { default 0; } server { ... location / { add_header Access-Control-Allow-Origin $cors_origin; return 204; } } Test: $ telnet 127.0.0.1 8080 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 204 No Content Server: nginx/1.22.1 Date: Mon, 27 Mar 2023 16:01:05 GMT Connection: close Access-Control-Allow-Origin: 0 Connection closed by foreign host. As you can see from the telnet output, the Access-Control-Allow-Origin is properly added. If you are seeing a different behaviour, you may want to recheck the value actually being used. If it is indeed "0", and not an empty string, please provide more details. -- Maxim Dounin http://mdounin.ru/ From pluknet at nginx.com Mon Mar 27 17:57:34 2023 From: pluknet at nginx.com (Sergey Kandaurov) Date: Mon, 27 Mar 2023 21:57:34 +0400 Subject: How to compile Nginx with zlib-ng In-Reply-To: References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: > On 24 Mar 2023, at 06:07, Maxim Dounin wrote: > > Hello! > > On Thu, Mar 23, 2023 at 09:33:19PM +0100, Richard Stanway via nginx wrote: > >> Yes, when using the latest zlib-ng on nginx-1.21.6 I received the >> alerts. Previous versions of zlib-ng have worked great after the 2021 >> patch. I tried to update it myself as follows based on advice of >> zlib-ng GitHub issues, while it reduced the number of alerts logged it >> did not completely solve the issue so it seems the memory requirements >> may have further changed. While I would appreciate a proper patch >> making it into nginx, the seemingly-frequent upstream changes may make >> this difficult to maintain. >> >> - ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) >> + ctx->allocated = 8192 + 288 + 16 + (1 << (wbits + 2)) >> + 131072 + (1 << (memlevel + 8)); > > It looks like there are at least two changes in zlib-ng since I > looked into it: > > - Window bits are no longer forced to 13 on compression level 1. > > - All allocations use custom alloc_aligned() wrapper, and > therefore all allocations are larger than expected by (64 + > sizeof(void*)). > > Further, due to the wrapper nginx sees all allocations as an > allocation of 1 element of a given size, so it misinterprets > some allocations as the state allocation. > > [..] > > Please try the following patch, it should help with recent versions: > > # HG changeset patch > # User Maxim Dounin > # Date 1679622670 -10800 > # Fri Mar 24 04:51:10 2023 +0300 > # Node ID 67a0999550c3622e51639acb8bde57d199826f7e > # Parent d1cf09451ae84b930ce66fa6d63ae3f7eeeac5a5 > Gzip: compatibility with recent zlib-ng versions. > > It now uses custom alloc_aligned() wrapper for all allocations, > therefore all allocations are larger than expected by (64 + sizeof(void*)). > Further, they are seen as allocations of 1 element. Relevant calculations > were adjusted to reflect this, and state allocation is now protected > with a flag to avoid misinterpreting other allocations as the zlib > deflate_state allocation. > > Further, it no longer forces window bits to 13 on compression level 1, > so the comment was adjusted to reflect this. For the record, the corresponding zlib-ng git commits: ce6789c7e093e8e6bb6fc591bbdf0f805999bdb9 a39e323a4db80a57feecf2ae212c08070234050c > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > --- a/src/http/modules/ngx_http_gzip_filter_module.c > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > @@ -57,6 +57,7 @@ typedef struct { > unsigned nomem:1; > unsigned buffering:1; > unsigned zlib_ng:1; > + unsigned state_allocated:1; > > size_t zin; > size_t zout; > @@ -514,9 +515,10 @@ ngx_http_gzip_filter_memory(ngx_http_req > } else { > /* > * Another zlib variant, https://github.com/zlib-ng/zlib-ng. > - * It forces window bits to 13 for fast compression level, > - * uses 16-byte padding in one of window-sized buffers, and > - * uses 128K hash. > + * It used to force window bits to 13 for fast compression level, BTW, it makes sense to peel off this extra allocation somewhere in future, similar to how it was done for updated handling of zlib variant from Intel. > + * uses (64 + sizeof(void*)) additional space on all allocations > + * for alignment, 16-byte padding in one of window-sized buffers, > + * and 128K hash. > */ > > if (conf->level == 1) { > @@ -524,7 +526,8 @@ ngx_http_gzip_filter_memory(ngx_http_req > } > > ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > - + 131072 + (1 << (memlevel + 8)); > + + 131072 + (1 << (memlevel + 8)) > + + 4 * (64 + sizeof(void*)); > ctx->zlib_ng = 1; > } > } > @@ -926,13 +929,16 @@ ngx_http_gzip_filter_alloc(void *opaque, > > alloc = items * size; > > - if (items == 1 && alloc % 512 != 0 && alloc < 8192) { > - > + if (items == 1 && alloc % 512 != 0 && alloc < 8192 > + && !ctx->state_allocated) > + { > /* > * The zlib deflate_state allocation, it takes about 6K, > * we allocate 8K. Other allocations are divisible by 512. > */ > > + ctx->state_allocated = 1; > + > alloc = 8192; Nitpicking: now the allocation size comment and assignment look separated. Mind moving the ctx->state_allocated line below? > } > Looks good otherwise. -- Sergey Kandaurov From mdounin at mdounin.ru Mon Mar 27 18:28:02 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Mon, 27 Mar 2023 21:28:02 +0300 Subject: How to compile Nginx with zlib-ng In-Reply-To: References: <2a5edb2b-854d-4022-8f10-106dc5fd68b7@Spark> <078b9cb1-2e76-400b-a43b-f53971467897@Spark> Message-ID: Hello! On Mon, Mar 27, 2023 at 09:57:34PM +0400, Sergey Kandaurov wrote: > > On 24 Mar 2023, at 06:07, Maxim Dounin wrote: > > > > Hello! > > > > On Thu, Mar 23, 2023 at 09:33:19PM +0100, Richard Stanway via nginx wrote: > > > >> Yes, when using the latest zlib-ng on nginx-1.21.6 I received the > >> alerts. Previous versions of zlib-ng have worked great after the 2021 > >> patch. I tried to update it myself as follows based on advice of > >> zlib-ng GitHub issues, while it reduced the number of alerts logged it > >> did not completely solve the issue so it seems the memory requirements > >> may have further changed. While I would appreciate a proper patch > >> making it into nginx, the seemingly-frequent upstream changes may make > >> this difficult to maintain. > >> > >> - ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > >> + ctx->allocated = 8192 + 288 + 16 + (1 << (wbits + 2)) > >> + 131072 + (1 << (memlevel + 8)); > > > > It looks like there are at least two changes in zlib-ng since I > > looked into it: > > > > - Window bits are no longer forced to 13 on compression level 1. > > > > - All allocations use custom alloc_aligned() wrapper, and > > therefore all allocations are larger than expected by (64 + > > sizeof(void*)). > > > > Further, due to the wrapper nginx sees all allocations as an > > allocation of 1 element of a given size, so it misinterprets > > some allocations as the state allocation. > > > > [..] > > > > Please try the following patch, it should help with recent versions: > > > > # HG changeset patch > > # User Maxim Dounin > > # Date 1679622670 -10800 > > # Fri Mar 24 04:51:10 2023 +0300 > > # Node ID 67a0999550c3622e51639acb8bde57d199826f7e > > # Parent d1cf09451ae84b930ce66fa6d63ae3f7eeeac5a5 > > Gzip: compatibility with recent zlib-ng versions. > > > > It now uses custom alloc_aligned() wrapper for all allocations, > > therefore all allocations are larger than expected by (64 + sizeof(void*)). > > Further, they are seen as allocations of 1 element. Relevant calculations > > were adjusted to reflect this, and state allocation is now protected > > with a flag to avoid misinterpreting other allocations as the zlib > > deflate_state allocation. > > > > Further, it no longer forces window bits to 13 on compression level 1, > > so the comment was adjusted to reflect this. > > For the record, the corresponding zlib-ng git commits: > ce6789c7e093e8e6bb6fc591bbdf0f805999bdb9 > a39e323a4db80a57feecf2ae212c08070234050c > > > > > diff --git a/src/http/modules/ngx_http_gzip_filter_module.c b/src/http/modules/ngx_http_gzip_filter_module.c > > --- a/src/http/modules/ngx_http_gzip_filter_module.c > > +++ b/src/http/modules/ngx_http_gzip_filter_module.c > > @@ -57,6 +57,7 @@ typedef struct { > > unsigned nomem:1; > > unsigned buffering:1; > > unsigned zlib_ng:1; > > + unsigned state_allocated:1; > > > > size_t zin; > > size_t zout; > > @@ -514,9 +515,10 @@ ngx_http_gzip_filter_memory(ngx_http_req > > } else { > > /* > > * Another zlib variant, https://github.com/zlib-ng/zlib-ng. > > - * It forces window bits to 13 for fast compression level, > > - * uses 16-byte padding in one of window-sized buffers, and > > - * uses 128K hash. > > + * It used to force window bits to 13 for fast compression level, > > BTW, it makes sense to peel off this extra allocation somewhere in future, > similar to how it was done for updated handling of zlib variant from Intel. Sure, but it's not significant compared to the 128k hash anyway. > > + * uses (64 + sizeof(void*)) additional space on all allocations > > + * for alignment, 16-byte padding in one of window-sized buffers, > > + * and 128K hash. > > */ > > > > if (conf->level == 1) { > > @@ -524,7 +526,8 @@ ngx_http_gzip_filter_memory(ngx_http_req > > } > > > > ctx->allocated = 8192 + 16 + (1 << (wbits + 2)) > > - + 131072 + (1 << (memlevel + 8)); > > + + 131072 + (1 << (memlevel + 8)) > > + + 4 * (64 + sizeof(void*)); > > ctx->zlib_ng = 1; > > } > > } > > @@ -926,13 +929,16 @@ ngx_http_gzip_filter_alloc(void *opaque, > > > > alloc = items * size; > > > > - if (items == 1 && alloc % 512 != 0 && alloc < 8192) { > > - > > + if (items == 1 && alloc % 512 != 0 && alloc < 8192 > > + && !ctx->state_allocated) > > + { > > /* > > * The zlib deflate_state allocation, it takes about 6K, > > * we allocate 8K. Other allocations are divisible by 512. > > */ > > > > + ctx->state_allocated = 1; > > + > > alloc = 8192; > > Nitpicking: > now the allocation size comment and assignment look separated. > Mind moving the ctx->state_allocated line below? I've tried previously, and it looks ugly. So it ended up in this way. Note well that the comment is not about setting "alloc" to 8192, but mostly about the whole if() branch: it describes the allocation we are going to do, and how this particular allocation is selected among others. As such, the order as currently used in the patch is quite logical, as the code first ensures that we won't accidentally enter the same if() again, and then updates "alloc" to be 8192. > > > } > > > > Looks good otherwise. Thanks for the review, pushed to http://mdounin.ru/hg/nginx. -- Maxim Dounin http://mdounin.ru/ From vilius.sumskas at rivile.lt Tue Mar 28 05:50:55 2023 From: vilius.sumskas at rivile.lt (=?utf-8?B?VmlsaXVzIMWgdW1za2Fz?=) Date: Tue, 28 Mar 2023 05:50:55 +0000 Subject: nginx configuration variable interpolation In-Reply-To: References: Message-ID: Thank you for your response. I've made a mistake. I've made my initial tests with a lot of different combinations and last value I have used, which doesn't add header at all, is indeed an empty string, not 0. So it seems this works as expected. I think it is functionality worth documenting though. When I searched the internet for "how to add nginx header conditionally" there was dozen of examples which used only ifs, or a combination of maps and ifs, but none of them actually mentioned that add_header is on itself conditional. -- Best Regards, Vilius -----Original Message----- From: nginx On Behalf Of Maxim Dounin Sent: Monday, March 27, 2023 7:09 PM To: nginx at nginx.org Subject: Re: nginx configuration variable interpolation Hello! On Mon, Mar 27, 2023 at 03:24:06PM +0000, Vilius Šumskas wrote: > I have the following directive in Nginx configuration: > > location /docs { > add_header Access-Control-Allow-Origin $cors_origin; } > > $cors_origin comes from the map {} where the value is set to * or something else. > > I have noticed that if $cors_origin is set to 0, add_header doesn’t > add Access-Control-Allow-Origin header at all. Is this expected? I > don’t see anything about such behaviour in the add_header > documentation. The header will not be added if the value is an empty string. If it is not empty but "0", the header will be added just fine. For example, consider the following configuration: map $uri $cors_origin { default 0; } server { ... location / { add_header Access-Control-Allow-Origin $cors_origin; return 204; } } Test: $ telnet 127.0.0.1 8080 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. GET / HTTP/1.0 HTTP/1.1 204 No Content Server: nginx/1.22.1 Date: Mon, 27 Mar 2023 16:01:05 GMT Connection: close Access-Control-Allow-Origin: 0 Connection closed by foreign host. As you can see from the telnet output, the Access-Control-Allow-Origin is properly added. If you are seeing a different behaviour, you may want to recheck the value actually being used. If it is indeed "0", and not an empty string, please provide more details. -- Maxim Dounin http://mdounin.ru/ _______________________________________________ nginx mailing list nginx at nginx.org https://mailman.nginx.org/mailman/listinfo/nginx From mdounin at mdounin.ru Tue Mar 28 16:43:54 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Tue, 28 Mar 2023 19:43:54 +0300 Subject: nginx-1.23.4 Message-ID: Changes with nginx 1.23.4 28 Mar 2023 *) Change: now TLSv1.3 protocol is enabled by default. *) Change: now nginx issues a warning if protocol parameters of a listening socket are redefined. *) Change: now nginx closes connections with lingering if pipelining was used by the client. *) Feature: byte ranges support in the ngx_http_gzip_static_module. *) Bugfix: port ranges in the "listen" directive did not work; the bug had appeared in 1.23.3. Thanks to Valentin Bartenev. *) Bugfix: incorrect location might be chosen to process a request if a prefix location longer than 255 characters was used in the configuration. *) Bugfix: non-ASCII characters in file names on Windows were not supported by the ngx_http_autoindex_module, the ngx_http_dav_module, and the "include" directive. *) Change: the logging level of the "data length too long", "length too short", "bad legacy version", "no shared signature algorithms", "bad digest length", "missing sigalgs extension", "encrypted length too long", "bad length", "bad key update", "mixed handshake and non handshake data", "ccs received early", "data between ccs and finished", "packet length too long", "too many warn alerts", "record too small", and "got a fin before a ccs" SSL errors has been lowered from "crit" to "info". *) Bugfix: a socket leak might occur when using HTTP/2 and the "error_page" directive to redirect errors with code 400. *) Bugfix: messages about logging to syslog errors did not contain information that the errors happened while logging to syslog. Thanks to Safar Safarly. *) Workaround: "gzip filter failed to use preallocated memory" alerts appeared in logs when using zlib-ng. *) Bugfix: in the mail proxy server. -- Maxim Dounin http://nginx.org/ From droidbittin at gmail.com Tue Mar 28 16:50:59 2023 From: droidbittin at gmail.com (Luna Jernberg) Date: Tue, 28 Mar 2023 18:50:59 +0200 Subject: nginx-1.23.4 In-Reply-To: References: Message-ID: Any plans to package this up for Almalinux? On Tue, Mar 28, 2023 at 6:44 PM Maxim Dounin wrote: > > Changes with nginx 1.23.4 28 Mar 2023 > > *) Change: now TLSv1.3 protocol is enabled by default. > > *) Change: now nginx issues a warning if protocol parameters of a > listening socket are redefined. > > *) Change: now nginx closes connections with lingering if pipelining was > used by the client. > > *) Feature: byte ranges support in the ngx_http_gzip_static_module. > > *) Bugfix: port ranges in the "listen" directive did not work; the bug > had appeared in 1.23.3. > Thanks to Valentin Bartenev. > > *) Bugfix: incorrect location might be chosen to process a request if a > prefix location longer than 255 characters was used in the > configuration. > > *) Bugfix: non-ASCII characters in file names on Windows were not > supported by the ngx_http_autoindex_module, the ngx_http_dav_module, > and the "include" directive. > > *) Change: the logging level of the "data length too long", "length too > short", "bad legacy version", "no shared signature algorithms", "bad > digest length", "missing sigalgs extension", "encrypted length too > long", "bad length", "bad key update", "mixed handshake and non > handshake data", "ccs received early", "data between ccs and > finished", "packet length too long", "too many warn alerts", "record > too small", and "got a fin before a ccs" SSL errors has been lowered > from "crit" to "info". > > *) Bugfix: a socket leak might occur when using HTTP/2 and the > "error_page" directive to redirect errors with code 400. > > *) Bugfix: messages about logging to syslog errors did not contain > information that the errors happened while logging to syslog. > Thanks to Safar Safarly. > > *) Workaround: "gzip filter failed to use preallocated memory" alerts > appeared in logs when using zlib-ng. > > *) Bugfix: in the mail proxy server. > > > -- > Maxim Dounin > http://nginx.org/ > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx From droidbittin at gmail.com Tue Mar 28 16:52:12 2023 From: droidbittin at gmail.com (Luna Jernberg) Date: Tue, 28 Mar 2023 18:52:12 +0200 Subject: nginx-1.23.4 In-Reply-To: References: Message-ID: Got an answer on #nginx @ Libera On Tue, Mar 28, 2023 at 6:50 PM Luna Jernberg wrote: > > Any plans to package this up for Almalinux? > > On Tue, Mar 28, 2023 at 6:44 PM Maxim Dounin wrote: > > > > Changes with nginx 1.23.4 28 Mar 2023 > > > > *) Change: now TLSv1.3 protocol is enabled by default. > > > > *) Change: now nginx issues a warning if protocol parameters of a > > listening socket are redefined. > > > > *) Change: now nginx closes connections with lingering if pipelining was > > used by the client. > > > > *) Feature: byte ranges support in the ngx_http_gzip_static_module. > > > > *) Bugfix: port ranges in the "listen" directive did not work; the bug > > had appeared in 1.23.3. > > Thanks to Valentin Bartenev. > > > > *) Bugfix: incorrect location might be chosen to process a request if a > > prefix location longer than 255 characters was used in the > > configuration. > > > > *) Bugfix: non-ASCII characters in file names on Windows were not > > supported by the ngx_http_autoindex_module, the ngx_http_dav_module, > > and the "include" directive. > > > > *) Change: the logging level of the "data length too long", "length too > > short", "bad legacy version", "no shared signature algorithms", "bad > > digest length", "missing sigalgs extension", "encrypted length too > > long", "bad length", "bad key update", "mixed handshake and non > > handshake data", "ccs received early", "data between ccs and > > finished", "packet length too long", "too many warn alerts", "record > > too small", and "got a fin before a ccs" SSL errors has been lowered > > from "crit" to "info". > > > > *) Bugfix: a socket leak might occur when using HTTP/2 and the > > "error_page" directive to redirect errors with code 400. > > > > *) Bugfix: messages about logging to syslog errors did not contain > > information that the errors happened while logging to syslog. > > Thanks to Safar Safarly. > > > > *) Workaround: "gzip filter failed to use preallocated memory" alerts > > appeared in logs when using zlib-ng. > > > > *) Bugfix: in the mail proxy server. > > > > > > -- > > Maxim Dounin > > http://nginx.org/ > > _______________________________________________ > > nginx mailing list > > nginx at nginx.org > > https://mailman.nginx.org/mailman/listinfo/nginx From bmvishwas at gmail.com Wed Mar 29 07:43:10 2023 From: bmvishwas at gmail.com (Vishwas Bm) Date: Wed, 29 Mar 2023 13:13:10 +0530 Subject: client certificate to upstream via nginx Message-ID: Hi We have a client certificate in pem format and it is having below content and all these certificates are present in a single file. serverCertificate -> intermediate CA -> rootCA Now in the nginx.conf have below directives set: ` server { ... ssl_client_certificate ca-pg-ca.pem; * ssl_verify_client optional_no_ca; * ssl_verify_depth 4; location ~* "^/" { ... proxy_set_header Host $best_http_host; # Pass the extracted client certificate to the backend * proxy_set_header ssl-client-cert $ssl_client_escaped_cert; * proxy_set_header ssl-client-verify $ssl_client_verify; proxy_set_header ssl-client-subject-dn $ssl_client_s_dn; proxy_set_header ssl-client-issuer-dn $ssl_client_i_dn; } }` Now in the nginx logs we see below traces: ` {"message":"83#83: *874 http script var: '10.15.176.110:10443'"} {"message":"83#83: *874 http script copy: 'ssl-client-cert'"} {"message":"83#83: *874 http script var: '-----BEGIN%20CERTIFICATE----------END%20CERTIFICATE-----%0A'"}} {"message":"83#83: *874 http script copy: 'ssl-client-verify'"}} {"message":"83#83: *874 http script var: 'SUCCESS'"}} {"message":"83#83: *874 http script copy: 'ssl-client-subject-dn'"}} {"message":"83#83: *874 http script var: 'CN=clientcert.com,O=ABCD,L=Ba,ST=Ka,C=US'"}} {"message":"83#83: *874 http script copy: 'ssl-client-issuer-dn'"}} {"message":"83#83: *874 http script var: 'CN=intermediateca.com,O=Nk,ST=Ka,C=US'"}} ` So based on above only the client certificate is sent to the upstream server but our expectation was that the complete pem contents including all the 3 certs (client, intermediate and root) will be sent to the backend. Is our expectation correct or wrong ? Any change has to be done to handle this ? Nginx version used: 1.22.1 *Thanks & Regards,* *Vishwas * -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekgermann at semperen.com Wed Mar 29 21:09:45 2023 From: ekgermann at semperen.com (Eric Germann) Date: Wed, 29 Mar 2023 17:09:45 -0400 Subject: QUIC oddity (gets h2 the first time around, subsequent retrievals are h3) Message-ID: Wondering if anyone can explain this. With Chrome and Curl, it seems like the first connect from a restarted client, seems to return data over HTTP/2. Subsequent rounds return HTTP/3. Here’s some output showing it curl --http3 https://noc2.semperen.com/lslr.b64 -I HTTP/2 200 server: nginx/1.23.4 date: Wed, 29 Mar 2023 21:03:34 GMT content-type: application/octet-stream content-length: 40832805 last-modified: Wed, 22 Mar 2023 01:11:00 GMT etag: "641a55a4-26f0f25" x-cache-debug: /lslr.b64 accept-ranges: bytes alt-svc: h3=":443"; ma=60, h2=":443"; ma=60 alt-svc: h2=":443"; ma=86400; x-frame-options: SAMEORIGIN strict-transport-security: max-age=31104000; includeSubdomains opt/curl/bin on  stable on ☁️ (us-east-2) ➜ curl --http3 https://noc2.semperen.com/lslr.b64 -I HTTP/3 200 server: nginx/1.23.4 date: Wed, 29 Mar 2023 21:03:41 GMT content-type: application/octet-stream content-length: 40832805 last-modified: Wed, 22 Mar 2023 01:11:00 GMT etag: "641a55a4-26f0f25" x-cache-debug: /lslr.b64 accept-ranges: bytes alt-svc: h3=":443"; ma=60, h2=":443"; ma=60 alt-svc: h2=":443"; ma=86400; x-frame-options: SAMEORIGIN strict-transport-security: max-age=31104000; includeSubdomains notice the HTTP/2 and HTTP/3 headers. Changing the ma on the alt-sec-header seemed to make it reproducible, but not now. It seems to do it randomly, in Chrome and now curl. FF always has a h3 session the first hit to the site. Thoughts? -- Eric Germann ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com LinkedIn: https://www.linkedin.com/in/ericgermann Medium: https://ekgermann.medium.com Twitter: @ekgermann Telegram || Signal || Skype || WhatsApp || Phone +1 {dash} 419 {dash} 513 {dash} 0712 GPG Fingerprint: 89ED 36B3 515A 211B 6390 60A9 E30D 9B9B 3EBF F1A1 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: Message signed with OpenPGP URL: From mdounin at mdounin.ru Wed Mar 29 21:39:33 2023 From: mdounin at mdounin.ru (Maxim Dounin) Date: Thu, 30 Mar 2023 00:39:33 +0300 Subject: client certificate to upstream via nginx In-Reply-To: References: Message-ID: Hello! On Wed, Mar 29, 2023 at 01:13:10PM +0530, Vishwas Bm wrote: > We have a client certificate in pem format and it is having below content > and all these certificates are present in a single file. > serverCertificate -> intermediate CA -> rootCA > > Now in the nginx.conf have below directives set: [...] > * proxy_set_header ssl-client-cert $ssl_client_escaped_cert; * [...] > So based on above only the client certificate is sent to the upstream > server but our expectation was that the complete pem contents including all > the 3 certs (client, intermediate and root) will be sent to the backend. > > Is our expectation correct or wrong ? > Any change has to be done to handle this ? I've already replied in the ticket #2476, which I assume is created by you (https://trac.nginx.org/nginx/ticket/2476). For the record: The $ssl_client_escaped_cert variable is expected to contain only the client certificate, and not the additional/extra certificates sent by the client. This matches the behaviour you are seeing. Further, it is not generally possible to provide a variable with extra certificates sent by the client: these certificates are not saved into the session data and therefore not available in resumed SSL sessions, see ticket #2297 (https://trac.nginx.org/nginx/ticket/2297) and here: https://mailman.nginx.org/pipermail/nginx-devel/2022-January/L3RBOEOUD5OFU23DYJAJG775ZJDASNEF.html Summing the above, it might be a good idea to reconsider the setup you are using. Hope this helps. -- Maxim Dounin http://mdounin.ru/ From xserverlinux at gmail.com Thu Mar 30 11:15:34 2023 From: xserverlinux at gmail.com (Rick Gutierrez) Date: Thu, 30 Mar 2023 07:15:34 -0400 Subject: situation with friendly urls Message-ID: Hi list, I have a situation that I want to share, we develop a small application in php that has friendly urls, it has a section in English and the other in Spanish, but when we put it in the backend server the project does not load correctly. I want to share a bit about the design of our infrastructure: users =========> Proxy reverse ===========backend server I've tried different configurations on the backend server and the reverse proxy, but still can't get it to load. For example, in the backend I put this type of application to load: location / { try_files $uri $uri/ /index.php?$args; # try_files $uri /index.php; root /var/tmp/sites/site.com/htdocs; index index.php index.html index.htm; } proxy reverse : location / { proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_connect_timeout 900s; proxy_send_timeout 900s; proxy_read_timeout 900s; proxy_buffer_size 64k; proxy_buffers 16 32k; proxy_busy_buffers_size 64k; proxy_redirect off; proxy_request_buffering off; proxy_buffering off; proxy_pass http://backend2; } I don't see any errors in the log, any advice? -- rickygm http://gnuforever.homelinux.com From justdan23 at gmail.com Thu Mar 30 23:32:22 2023 From: justdan23 at gmail.com (Dan Swaney) Date: Thu, 30 Mar 2023 19:32:22 -0400 Subject: situation with friendly urls In-Reply-To: References: Message-ID: Check to make sure the file is stored as UTF-8 Unicode instead of ANSI. I once had an issue where NGINX wouldn't load and the log showed nothing useful. It turned out I had to convert the file to UTF-8 Unicode to get it to work again. On Thu, Mar 30, 2023, 7:16 AM Rick Gutierrez wrote: > Hi list, I have a situation that I want to share, we develop a small > application in php that has friendly urls, it has a section in English > and the other in Spanish, but when we put it in the backend server the > project does not load correctly. > > I want to share a bit about the design of our infrastructure: > > users =========> Proxy reverse ===========backend server > > I've tried different configurations on the backend server and the > reverse proxy, but still can't get it to load. > > For example, in the backend I put this type of application to load: > > location / > > { > > try_files $uri $uri/ /index.php?$args; > # try_files $uri /index.php; > root /var/tmp/sites/site.com/htdocs; > index index.php index.html index.htm; > > } > > > > proxy reverse : > > location / { > > > proxy_http_version 1.1; > proxy_set_header Connection ""; > proxy_set_header Host $host; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > proxy_connect_timeout 900s; > > proxy_send_timeout 900s; > > proxy_read_timeout 900s; > > proxy_buffer_size 64k; > > proxy_buffers 16 32k; > > proxy_busy_buffers_size 64k; > > proxy_redirect off; > > proxy_request_buffering off; > > proxy_buffering off; > > proxy_pass http://backend2; > > > } > > I don't see any errors in the log, > > any advice? > > -- > rickygm > > http://gnuforever.homelinux.com > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdan23 at gmail.com Thu Mar 30 23:38:44 2023 From: justdan23 at gmail.com (Dan Swaney) Date: Thu, 30 Mar 2023 19:38:44 -0400 Subject: situation with friendly urls In-Reply-To: References: Message-ID: Another thing to try would be to enable debug to your output log. Add this line to the top of your nginx.conf file and restart NGINX: error_log /var/log/nginx/error.log debug; This assumes you have built NGINX with the configure option of --with-debug Here's the URL to the NGINX docs for convenience: https://docs.nginx.com/nginx/admin-guide/monitoring/debugging/ On Thu, Mar 30, 2023, 7:16 AM Rick Gutierrez wrote: > Hi list, I have a situation that I want to share, we develop a small > application in php that has friendly urls, it has a section in English > and the other in Spanish, but when we put it in the backend server the > project does not load correctly. > > I want to share a bit about the design of our infrastructure: > > users =========> Proxy reverse ===========backend server > > I've tried different configurations on the backend server and the > reverse proxy, but still can't get it to load. > > For example, in the backend I put this type of application to load: > > location / > > { > > try_files $uri $uri/ /index.php?$args; > # try_files $uri /index.php; > root /var/tmp/sites/site.com/htdocs; > index index.php index.html index.htm; > > } > > > > proxy reverse : > > location / { > > > proxy_http_version 1.1; > proxy_set_header Connection ""; > proxy_set_header Host $host; > > proxy_set_header X-Real-IP $remote_addr; > > proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; > > proxy_connect_timeout 900s; > > proxy_send_timeout 900s; > > proxy_read_timeout 900s; > > proxy_buffer_size 64k; > > proxy_buffers 16 32k; > > proxy_busy_buffers_size 64k; > > proxy_redirect off; > > proxy_request_buffering off; > > proxy_buffering off; > > proxy_pass http://backend2; > > > } > > I don't see any errors in the log, > > any advice? > > -- > rickygm > > http://gnuforever.homelinux.com > _______________________________________________ > nginx mailing list > nginx at nginx.org > https://mailman.nginx.org/mailman/listinfo/nginx > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xserverlinux at gmail.com Fri Mar 31 02:50:17 2023 From: xserverlinux at gmail.com (Rick Gutierrez) Date: Thu, 30 Mar 2023 22:50:17 -0400 Subject: situation with friendly urls In-Reply-To: References: Message-ID: El jue, 30 mar 2023 a las 19:32, Dan Swaney () escribió: > > Check to make sure the file is stored as UTF-8 Unicode instead of ANSI. > > I once had an issue where NGINX wouldn't load and the log showed nothing useful. It turned out I had to convert the file to UTF-8 Unicode to get it to work again. > Hi Dan , I have it encoded in that format. From xserverlinux at gmail.com Fri Mar 31 03:12:05 2023 From: xserverlinux at gmail.com (Rick Gutierrez) Date: Thu, 30 Mar 2023 23:12:05 -0400 Subject: situation with friendly urls In-Reply-To: References: Message-ID: El jue, 30 mar 2023 a las 19:39, Dan Swaney () escribió: > > Another thing to try would be to enable debug to your output log. > > Add this line to the top of your nginx.conf file and restart NGINX: > > error_log /var/log/nginx/error.log debug; > > > This assumes you have built NGINX with the configure option of --with-debug > Let me try, I'll put it in the reverse proxy