Support for proxying to self-signed HTTPS internal service (tls_insecure_skip_verify)

[changhoon-sung]

Summary

When configuring pingoo as a reverse proxy to an upstream that serves HTTPS with a self-signed certificate, requests fail with 502 Bad Gateway. I need a way to allow http_proxy to target https://... backends and optionally skip TLS verification (similar to Caddy’s tls_insecure_skip_verify).

Use case

Nextcloud AIO’s master container automatically exposes its dashboard over HTTPS using a self-signed certificate. Even from inside the same Docker network, the service must be reached via HTTPS. Other reverse proxies (e.g., Caddy) support this by allowing TLS verification to be skipped explicitly.

Caddy example (works):

@nextcloud-master host nextcloud-master.{env.DOMAIN}
handle @nextcloud-master {
  reverse_proxy https://nextcloud-aio-mastercontainer:8080 {
    transport http {
      tls_insecure_skip_verify
    }
  }
}

What I tried with pingoo

services:
  nextcloud-master:
    route: http_request.host.starts_with("nextcloud-master.")
    http_proxy: ["https://nextcloud-aio-mastercontainer:8080"]

pingoo returns 502 Bad Gateway when the upstream is HTTPS with a self-signed cert.

Expected behavior

• pingoo should be able to proxy to an HTTPS upstream using a self-signed certificate, when explicitly configured to skip TLS verification.
• Ideally, an opt-in setting in the service (or global) config, e.g.:

services:
  nextcloud-master:
    route: http_request.host.starts_with("nextcloud-master.")
    http_proxy:
      - url: "https://nextcloud-aio-mastercontainer:8080"
        tls_insecure_skip_verify: true   # opt-in, default false

[notABot101010]

Hello and thank you for your feedback!

The current plan is to implement all the services' configuration as rule actions. It allows more fine-grained control, and also avoid repeating the same configuration for 100 services, for example.

The user experience would be something like:

services:
  nextcloud-master:
    route: http_request.host.starts_with("nextcloud-master.")
    http_proxy: ["https://nextcloud-aio-mastercontainer:8080"]

rules:
  expression: http_request.host.starts_with("nextcloud-master.") # optional
  allow_self_signed_certificates_for_nextcloud:
    actions:
      - action: allow_self_signed_certificates

I would like to take a little bit of time to find a good name for this action.

Here are a few initial ideas:

• tls.insecure_skip_verify: same as your proposal, but "namespaced" under tls
• proxy.tls_verify
• http_proxy.allow_self_signed_certificates: where self-signed certificates would be any cert by a Certificate Authority no present on the OS / Pingoo's config

Any other idea?

[changhoon-sung]

I suppose this is what you meant with the example using rules:

rules:
  allow_self_signed_certificates_for_nextcloud:  
    expression: http_request.host.starts_with("nextcloud-master.") # optional
    actions:
      - action: allow_self_signed_certificates

I think the configuration where requests are filtered by an expression under rule and permitted through an action is already quite intuitive.
Also, the name allow_self_signed_certificates should be clear to anyone who deals with proxies or certificates.

[BjoernPetersen]

I think allow_self_signed_certificates is not clear enough if the effect is to totally disable certificate validation. Quite a few people use the terms "self-signed" and "self-issued" (using a private CA) interchangeably (also noted on the Wikipedia article). Those users might conclude that they'd need the allow_self_signed_certificates option, even though the better option would be to configure pingoo to trust their private CA.

[changhoon-sung]

I completely agree with that point. In that case, how about using insecure_skip_verify instead? This term is clearly indicates that certificate verification is entirely disabled.

Also it’s the same naming used in both Go’s standard library (tls.Config.InsecureSkipVerify) and Caddy’s proxy transport configuration (transport http { tls_insecure_skip_verify }).

[notABot101010]

Interesting, thanks for the feedback!

Before taking a "final" decision, I'm currently trying to make a list of future actions to implement to see if there are some patterns in the names (e.g. allow vs block / deny, enable vs skip vs bypass ...).

examples (not final):

• set_http_header
• connect_timeout
• auth.basic
• auth.jwt
• rewrite_url

Please feel free to post any name of action that may cross your mind so we can see if we can deduce some pattern / convention from the names.

As a reminder, we currently plan to use rule actions for basically everything: manipulating requests, configuring services...