When http_port is set in the Procfile, the Caddy validation correctly requires that port to also appear in ports. However, this has a side effect: the app port ends up both in the EC2 security group (open to 0.0.0.0/0) and served by a vsock proxy that binds on 0.0.0.0 (no bind=127.0.0.1).
The result is that the raw unencrypted app port is publicly reachable directly, bypassing Caddy and its TLS entirely.
Observed in user-data.sh:
# Custom user ports
ExecStart=/usr/bin/socat TCP-LISTEN:${port},reuseaddr,fork VSOCK-CONNECT:16:${port}
No bind= restriction -> listens on all interfaces.
Security group opens every port in var.ports to 0.0.0.0/0, and since http_port must be listed in ports, it gets opened too.
Questions:
- Is this intentional? Is there a reason the http_port vsock proxy needs to be reachable from outside rather than only from 127.0.0.1 (for Caddy to upstream to)?
- Should the security group skip opening http_port since Caddy already fronts it on 443?
- Or is the expectation that users who want TLS-only access manage their own firewall rules?
When http_port is set in the Procfile, the Caddy validation correctly requires that port to also appear in ports. However, this has a side effect: the app port ends up both in the EC2 security group (open to 0.0.0.0/0) and served by a vsock proxy that binds on 0.0.0.0 (no `bind=127.0.0.1`).
The result is that the raw unencrypted app port is publicly reachable directly, bypassing Caddy and its TLS entirely.
Observed in user-data.sh:
```bash
# Custom user ports
ExecStart=/usr/bin/socat TCP-LISTEN:${port},reuseaddr,fork VSOCK-CONNECT:16:${port}
```
No `bind=` restriction -> listens on all interfaces.
Security group opens every port in var.ports to 0.0.0.0/0, and since http_port must be listed in ports, it gets opened too.
Questions:
1. Is this intentional? Is there a reason the http_port vsock proxy needs to be reachable from outside rather than only from 127.0.0.1 (for Caddy to upstream to)?
2. Should the security group skip opening http_port since Caddy already fronts it on 443?
3. Or is the expectation that users who want TLS-only access manage their own firewall rules?