ssl.upgrade_insecure uses wrong port
nickbreen opened this issue · comments
The ssl.upgrade_insecure: true setting issues a redirect to https:// but uses the http port.
E.g.
curl -i http://example.com:1980/
HTTP/1.1 301 Moved Permanently
Content-Type: text/html; charset=utf-8
Location: https://example.com:1980/
Date: Sun, 26 Mar 2023 20:36:07 GMT
Content-Length: 62
<a href="https://example.com:1980/">Moved Permanently</a>.
ssl.enable_ssl is true and --ssl_port is specified as 1981.
app.build_buddy_url is specified as https://example.com:1981.
Nice catch, this seems like a bug to me.
The problematic code seems to be libmain.go -> interceptors.RedirectIfNotForwardedHTTPS() (1)
It seems like we should be passing sslServer.Addr value from libmain into the interceptors to redirect to the right host 🤔
cc: @tempoz @vadimberezniker wdyt?
(1):
I took a quick crack at fixing this via #3655 👀
I think the issue here is that this flag is intended to be used behind an ingress / load balancer that serves traffic on standard http / https ports, i.e. http traffic over port 80 and ssl traffic over port 443.
The flag does know about or alter the requested port, it simply changes the scheme from http:// to https://.
If you make an http request to http://yourbuildbuddyinstance.com/ the scheme will be upgraded to https://yourbuildbuddyinstance.com/ (and your browser or curl will use the correct port, 80 in one case and 443 in the other).
The --ssl_port flag is intended as an "internal" port, i.e. not exposed to the internet via an ingress / load balancer and defaults to 8081. The internal port to external port mapping is typically done via a service like this.
We don't want requests to http://app.buildbuddy.io to be redirected to https://app.buildbuddy.io:8081 (which is what #3655 would unintentionally do - or realistically it'd probably redirect to https://0.0.0.0:8081 which is also not what you'd want).
If you want this to work correctly without an ingress / load balancer / service (which I wouldn't necessarily recommend), then you can set --port=80 and --ssl_port=443 and make your http requests without specifying a port.
Makes sense.
It'd be worth noting the intent for ssl.upgrade_insecure and those assumptions above (there being an ingress HTTP/S service) in the configuration documentation for the next person who makes the same assumption as me.
I'm also running it as the container image: so there's an additional layer of port-mapping shenanigans on top.
Sounds good, done in #3666