switch to get nginx to validate proxy tls connections

[alecmuffett]

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 - default 1, or set to 0 to disable
• nginx_proxy_ssl_trusted_certificate default /etc/ssl/certs/ca-certificates.crt

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.

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_ssl due to behaviour of Tor Browser as documented here