Caddy doesn't listen on port 80 on all bind addresses

[theel0ja]

:443 {
	bind 95.216.178.135 2a01:4f9:c010:85b9::f00

	tls {
		on_demand
	}
}

On Port 80 on the IPv4 address, it fails:

$ curl 95.216.178.135 -v
*   Trying 95.216.178.135:80...
* connect to 95.216.178.135 port 80 failed: Connection refused
* Failed to connect to 95.216.178.135 port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 95.216.178.135 port 80: Connection refused

On Port 80 on the IPv6 address, it works:

$ curl [2a01:4f9:c010:85b9::f00] -v
*   Trying 2a01:4f9:c010:85b9::f00:80...
* Connected to 2a01:4f9:c010:85b9::f00 (2a01:4f9:c010:85b9::f00) port 80 (#0)
> GET / HTTP/1.1
> Host: [2a01:4f9:c010:85b9::f00]
> User-Agent: curl/7.70.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 308 Permanent Redirect
< Connection: close
< Location: https://[2a01:4f9:c010:85b9::f00]/
< Server: Caddy
< Date: Sun, 24 May 2020 18:16:02 GMT
< Content-Length: 0
<
* Closing connection 0

This breaks redirects on IPv4-only machines.

$ caddy version
v2.0.0 h1:pQSaIJGFluFvu8KDGDODV8u4/QRED/OPyIR+MWYYse8=

$ uname -a
Linux srv01 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2 (2020-04-29) x86_64 GNU/Linux

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Debian
Description:	Debian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

$ sudo netstat -lntpuW | grep caddy
tcp        0      0 95.216.178.135:443      0.0.0.0:*               LISTEN      14509/caddy
tcp6       0      0 2a01:4f9:c010:85b9::f00:80 :::*                    LISTEN      14509/caddy
tcp6       0      0 2a01:4f9:c010:85b9::f00:443 :::*                    LISTEN      14509/caddy

[francislavoie]

Interesting. That Caddyfile adapts to this:

{
  "apps": {
    "http": {
      "servers": {
        "srv0": {
          "listen": [
            "[2a01:4f9:c010:85b9::f00]:443",
            "95.216.178.135:443"
          ]
        }
      }
    },
    "tls": {
      "automation": {
        "policies": [
          {
            "issuer": {
              "challenges": {
                "bind_host": "95.216.178.135"
              },
              "module": "acme"
            },
            "on_demand": true
          }
        ]
      }
    }
  }
}

You'll notice that the IPv6 address is ordered first - I think a loop is missing somewhere in the Automatic HTTPS logic and it's only binding to the HTTP port for the first listen address. I'll dig a bit more.

[francislavoie]

Okay @mholt I think this part of the code is the issue:

https://github.com/caddyserver/caddy/blob/master/modules/caddyhttp/autohttps.go#L222

The redirDomains array gets overwritten as it loops here, so only the last one encountered is kept. I added a couple lines of logging immediately after the redirDomains[""] line with redirDomains's value:

2020/05/24 22:02:20.337 INFO  http  Hmmm... {"redirDomains": {"":{"Network":"tcp","Host":"95.216.178.135","StartPort":443,"EndPort":443}}}
2020/05/24 22:02:20.337 INFO  http  Hmmm... {"redirDomains": {"":{"Network":"tcp","Host":"2a01:4f9:c010:85b9::f00","StartPort":443,"EndPort":443}}}

I think this needs needs to be reworked to handle IPs as well as domains.

[mholt]

@francislavoie For me, it adapts to JSON with the opposite order:

        "srv0": {
          "listen": [
            "95.216.178.135:443",
            "[2a01:4f9:c010:85b9::f00]:443"
          ]

probably due to use of a map, which has nondeterministic order.

Anyway, I think the fix was simple enough. @theel0ja and @francislavoie please try it out! Thanks :)