Unable to stop auto_https on v2.2.1

[Neiby (John Neiberger)]

1. Caddy version (caddy version): 2.2.1

2. How I run Caddy: I run caddy as a service

a. System environment: CentOS 7.8

b. Command:

sudo systemctl start caddy

c. Service/unit/compose file:

[Unit]
Description=Caddy
Documentation=https://caddyserver.com/docs/
After=network.target network-online.target
Requires=network-online.target

[Service]
User=caddy
Group=caddy
ExecStart=/usr/bin/caddy run --environ --config /etc/caddy/Caddyfile
ExecReload=/usr/bin/caddy reload --config /etc/caddy/Caddyfile
TimeoutStopSec=5s
LimitNOFILE=1048576
LimitNPROC=512
PrivateTmp=true
ProtectSystem=full
AmbientCapabilities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multi-user.target`

d. My complete Caddyfile or JSON config:

http://bblg.mydomain.net {
	tls off
	file_server {
		root /etc/hyperglass/static/ui
		index /etc/hyperglass/static/ui/index.html
	}
	file_server /custom {
		root /etc/hyperglass/static/custom
	}
	file_server /images {
		root /etc/hyperglass/static/images
	}
	reverse_proxy localhost:8001
}

3. The problem I’m having:

I cannot get https redirects to stop. I’m installing a service on an internal device with no public DNS, so auto_https is going to fail. It is not needed for this tool, so I want to disable it entirely. I’ve tried explicitly setting HTTP:// in the site name, I’ve tried ‘tls off’ in the config, and I’ve tried using a global block in the Caddyfile with “auto_https off” set. Nothing seems to be working. I immediately get redirected to an https site that then fails to load.

4. Error messages and/or full log output:

No error messages other than the browser error message due to failing TLS

5. What I already tried:

I’ve tried explicitly setting http:// in the site name. I’ve tried “tls off”. I’ve tried setting “auto_https off” in a global block in the caddyfile.

[francislavoie]

The http:// in the site block should be enough.

Did you ever add a line to serve the header Strict-Transport-Security? If so, your browser will remember that (for a very very long time depending on what duration was on the header) and continue to redirect you anyways.

Check your Caddy logs with journalctl -u caddy --no-pager | less.

Also try making a request with curl -vL to see if Caddy is actually serving a redirect or if it’s just your browser doing it.

[Neiby (John Neiberger)]

Great catch! I had never added the strict TLS line, but the end result appears to be the same. It is my browser (Edge Chromium) remembering the setting. I tried it in other browsers and got the correct, expected http page. It never occurred to me that the browser would hang on to that like it is doing.

Thanks for the help!

[francislavoie]

Yeah that’s actually the point of that setting. It’s meant to be a protection against downgrade attacks if someone manages to force your site to serve http. But browsers remember it for a very long time so it’s a foot-gun, i.e. you can shoot yourself in the foot if you wield that tool incorrectly. You should only ever set that header if you’re certain you’ll never need to serve content over http in the future.

[Neiby (John Neiberger)]

Is that a caddy setting? If so, I never set it. I hadn’t actually seen the setting before until you mentioned it.

[francislavoie]

I’m talking about this header:

Strict-Transport-Security - HTTP | MDN

Caddy does not touch that on its own, you would’ve had to have added a line like header Strict-Transport-Security max-age=31536000; to your site at some point.

[Neiby (John Neiberger)]

Ah, okay, that’s what I wanted to verify. The site is built in the tool I’m installing. It’s a BGP looking glass called Hyperglass. I’ll ask the dev about that.

Thanks again!

[matt (Matt Holt)]

Always use curl to test: curl -v ... and you can see the headers and what exactly is happening. Use -L to follow redirects.

[Neiby (John Neiberger)]

Thanks! It’s definitely my browser doing the redirect, but I’m not sure why it is remembering a setting that I never set. It’s odd. But that sure seems to be what’s happening. When I try it in Firefox instead, it works as expected, and curl -vL localhost proves it’s the browser doing it, not the site itself.