I think a reasonable first step towards true end-to-end encryption would be supporting "multi-hop" encryption where the communication looks something like User → TLS → shared proxy → TLS → upstream service with the shared proxy to upstream service leg being an unverified TLS connection.

This would not be the final perfect outcome, but it feels like a reasonable starting step. It would not support more advanced use cases such as x509 cert authentication between the user and the upstream service. It would also not add any real trust between the shared proxy and the upstream services without cert chain verification. It would however provide a way to transit traffic from the front proxy to a service in another Cloud VPS project with TLS protection for that traffic stream to help prevent shared network eavesdropping attacks.

Untested idea for multi-hop:

--- i/modules/dynamicproxy/templates/domainproxy.conf
+++ w/modules/dynamicproxy/templates/domainproxy.conf
@@ -148,6 +148,11 @@ server {
         proxy_pass $backend;
         proxy_set_header Host $vhost;

+        # T274386: allow unverified TLS to upstream when $backend starts with
+        # `https://` to trigger TLS usage by `proxy_pass`.
+        proxy_ssl_verify off;
+        proxy_ssl_session_reuse on;
+
         proxy_set_header X-Forwarded-Proto $scheme;

         proxy_http_version 1.1;

This would also need changes in the data retrieved via domainproxy.lua to allow it to return an https:// prefixed upstream route when appropriate. We may also want to add proxy_ssl_protocols and proxy_ssl_ciphers settings in this block to tune the "internal" TLS connection configuration.

My two cents / use case for this: production frontend reverse proxy has moved to https for all its backends, so having the web proxy talk https would allow as-is reuse of the same vhosts / configs in prod and cloud vps

Just a quick note/reminder that having the shared Cloud VPS web proxy speak https to its backends would be very nice and welcome

In T274386#6819605, @bd808 wrote:

Untested idea for multi-hop:

Based on https://nginx.org/en/docs/http/ngx_http_proxy_module.html those are already the defaults. So basically we only need to expose this setting in Horizon and document it, otherwise the infrastructure should already support https:// backends as is.

Change #1143541 had a related patch set uploaded (by Majavah; author: Majavah):

[openstack/horizon/wmf-proxy-dashboard@main] Support specifying a protocol

https://gerrit.wikimedia.org/r/1143541

Change #1143541 merged by jenkins-bot:

[openstack/horizon/wmf-proxy-dashboard@main] Support specifying a protocol

https://gerrit.wikimedia.org/r/1143541