Traffic between Caddy and Server

1. Caddy version (caddy version):


2. How I run Caddy:

Docker or Service

a. System environment:

Deb, docker

b. Command:

Paste command here.

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

Paste config here, replacing this text.
Use `caddy fmt` to make it readable.
DO NOT REDACT anything except credentials.
Make sure the backticks stay on their own lines.

3. The problem I’m having:

Traffic between Client and Caddy is beautifully encrypted. But
If there’s a network intrusion (eavesdropping) traffic between Caddy and Http server is not encrypted.

What Is the best practice to avoid that? (or Am I totally missing something)

4. Error messages and/or full log output:

5. What I already tried:

1- Docker-compose context: I believe that if Caddy and the Targeted server are both configured i nthe same file, Redirection to the ‘‘docker container’’ is made internally (Like the suggested configuration for Vaultwarden). Is this one way to go?
2- Localhost context: If caddy is running on the server itself, doing a: ‘‘localhost’’/ will it keep the packets inside the server without worries?
3- Vlan twist:
-A vlan is configured to allow only Caddy server and target server(s) to be possible. (limited CIDR range)
-Traffic between LAN/other Vlans to this VLAN only allow traffic toward Caddy and 443port
Will this prevent anything? I doubt so.

Sorry for the formatting, since this is not a ‘‘bug’’ but rather looking for best practices.

Thank you

6. Links to relevant resources:

You want to limit the amount of machines/servers/hops the HTTP connection from Caddy to your upstream needs to take, to avoid potential man-in-the-middle attacks.

If you’re running your backend on the same machine as Caddy, then the only risk of using HTTP is if an attacker managed to run their own code on your server. If they managed to do that, it’s already game-over anyways, so there’s no use worrying about the connection between them being encrypted at that point.

If you’re connecting to another maching in your LAN, it’s also probably fine as long as you trust all the devices connected to your network, and that your router is locked down so it can’t become a target for sniffing traffic.

If you’re going back over the public web, you absolutely should be proxying over HTTPS, because then you can’t implicitly trust anything.