This fits their expectation of the reverse-proxy being presented into a fleet of HTTP workers which are all either running HTTP (ick) or else self-signed arbitrary certificates which we don't really care about.
This patch introduces two new on-by-default settings:
nginx_proxy_ssl_verify - default 1, or set to 0 to disable
The first of these settings controls whether proxy_ssl_verify (see this page) is enabled.
The second defines a default for proxy_ssl_trusted_certificate (see ditto) which may need to be changed by the user.
We are currently considering options for inclusion of: (as documented)
proxy_ssl_verify_depth
proxy_ssl_session_reuse
proxy_ssl_protocols
proxy_ssl_ciphers
...which need more research for a new feature to be launched.
This patch is:
not fully tested
making the feature default-on
making the feature switch separate from the pathname
using the canonical if-else-endif to provide documentation in the rendered template
fixing the linter script
This bug/issue was reported by The Tor Project, who are working on their own fork of EOTKwhich may have a different approach towards fixing this issue.
From a practical perspective, the issue is hard to exploit without pwning the DNS of an Onion proxy (or: messing with upstream like BGP) and given that for large EOTK deployments mostly those are within the bounds of trust of the web fleet this bug is not an active threat and may actually cause a performance issue; but it is an issue for small EOTK deployments where an onion proxy is not co-located.
Aside: If you run EOTK with a website that contains legacy port-80 URLs AND ALSO services traffic on port 80, it is essential that you break that behaviour by use of force_ssl due to behaviour of Tor Browser as documented here
So it turns out that by default NGINX does not validate the TLS certificates of its backend servers when used as a reverse-proxy:
https://docs.nginx.com/nginx/admin-guide/security-controls/securing-http-traffic-upstream/
This fits their expectation of the reverse-proxy being presented into a fleet of HTTP workers which are all either running HTTP (ick) or else self-signed arbitrary certificates which we don't really care about.
This patch introduces two new on-by-default settings:
nginx_proxy_ssl_verify- default1, or set to0to disablenginx_proxy_ssl_trusted_certificatedefault/etc/ssl/certs/ca-certificates.crtThe first of these settings controls whether
proxy_ssl_verify(see this page) is enabled.The second defines a default for
proxy_ssl_trusted_certificate(see ditto) which may need to be changed by the user.We are currently considering options for inclusion of: (as documented)
...which need more research for a new feature to be launched.
This patch is:
This bug/issue was reported by The Tor Project, who are working on their own fork of EOTKwhich may have a different approach towards fixing this issue.
From a practical perspective, the issue is hard to exploit without pwning the DNS of an Onion proxy (or: messing with upstream like BGP) and given that for large EOTK deployments mostly those are within the bounds of trust of the web fleet this bug is not an active threat and may actually cause a performance issue; but it is an issue for small EOTK deployments where an onion proxy is not co-located.
More relevant documentation is at: https://stackoverflow.com/questions/66111292/nginx-proxy-ssl-trusted-certificate-with-letsencrypt-upstream
Aside: If you run EOTK with a website that contains legacy port-80 URLs AND ALSO services traffic on port 80, it is essential that you break that behaviour by use of
force_ssldue to behaviour of Tor Browser as documented here