insecure schemes are only allowed to localhost upstreams

[noed0ps]

1. Is bug reproducible with latest forwardproxy build?

yes

2. What are you trying to do?

3. What is your entire Caddyfile?

Caddyfile

:8082
route {
	forward_proxy {
		hide_ip
		hide_via
		upstream http://xxx:xxx@xxx:22225
		acl {
			allow     all
		}
	}
  file_server
}

4. How is your client configured?

v2.7.6 h1:w0NymbG2m9PcvKWsrXO6EEkY9Ru4FJK8uQbYcev1p3A=

5. How did you run Caddy? (give the full command and describe the execution environment). If multiple servers are used (for example with upstream), describe those as well.

caddy run --config Caddyfile

6. Please paste any relevant HTTP request(s) here.

7. What did you expect to see?

8. What did you see instead (give full error messages and/or log)?

9. How can someone who is starting from scratch reproduce the bug as minimally as possible?

[smrzlina]

I think i'm faced with a similar problem. Tried to set up a proxy chain - both on a local net. First one is caddy and the second is squid. I wanted to upstream form caddy to squid.

Caddyfile:

:1234 {
log {
output stdout
}

    route {
            forward_proxy {
                    upstream http://ip_of_squid.local:8080
            }
    }

}

Error: loading initial config: loading new config: loading http app module: provision http: server srv0: setting up route handlers: route 0: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 0: loading handler modules: position 0: loading module 'forward_proxy': provision http.handlers.forward_proxy: insecure schemes are only allowed to localhost upstreams

[cachius]

Please allow the http:// scheme for arbitrary upstreams, not only localhost. If a downstream client connects via TLS, use the CONNECT method to establish a secure channel with the upsteam HTTP proxy.

This way security is preserved and usability greatly improved. I was so hopeful to find caddy/forwardproxy after trying to use mitmproxy as proxy redirect, but it will always intercept. Then I got insecure schemes are only allowed to localhost upstreams and was stuck again. In a place that, as I understand it, is not necessary. @mholt What do you think?

[zoulja]

Dear forwardproxy author, please take a look at this issue

[mholt]

FWIW the "forwardproxy author" is no longer active on this repo, and hasn't been for years; I only aided its development originally (about 10 years ago!) and attempted to upgrade it for v2, but I haven't done any of the actual threat modeling of this.

So I don't know if simply removing the insecure upstreams check is the right thing to do. Alas, I don't have the time to work on this as I have my attention being pulled in mainline Caddy development right now, but if a sufficiently-tiered sponsor needed this worked on, I could prioritize it. I would just have to spend a lot of time getting deeply familiar with the code.

In the meantime, anyone else is welcome to become qualified to decide whether the linked PR is a security risk or not.

[jerry-wolf]

I don't think removing this restriction would be a big risk. There is no such restriction on reverse proxy upstreams unless you use a secure upstream and certificate verification fails (which can be turned off via configuration).