WebTunnel bridge with Caddy

Support Relay Operator
1

As I prefer Caddy over nginx just because of easier configuration, in my opinion, and

By default, Caddy automatically obtains and renews TLS certificates for all your sites.

I replaced nginx + ACME with Caddy v2.8.4.

As an example for a simple configuration:

/etc/caddy/Caddyfile

# After changing the Caddyfile:
# caddy fmt --overwrite /etc/caddy/Caddyfile
# caddy validate --config /etc/caddy/Caddyfile
# caddy reload --config /etc/caddy/Caddyfile

# Global options:
{
        # Restrict access to admin API endpoint, see
        # https://caddyserver.com/docs/api
        admin 127.0.0.1:2019

        # HTTP server port - as we don't use port 80 we force
        # 'TLS-ALPN challenge', see
        # https://caddyserver.com/docs/automatic-https#http-challenge
        # https://caddyserver.com/docs/automatic-https#tls-alpn-challenge
        # Do not open port 80 and 85 in the firewall
        http_port 85

        # Use the same email address for all sites
        email MAIL@YOURDOMAIN.TLD
}

(DefaultSecHeader) {
        header {
                Strict-Transport-Security "max-age=31536000; includeSubDomains"
                Referrer-Policy "same-origin"
                X-Content-Type-Options "nosniff"
                X-Frame-Options "SAMEORIGIN"
                X-XSS-Protection "1; mode=block"
                # Disable FLoC tracking
                Permissions-Policy "interest-cohort=()"
                # Hide "Server" header / server information
                -Server
                -X-Powered-By
        }
}

YOURDOMAIN.TLD, www.YOURDOMAIN.TLD {
        handle_errors {
                import DefaultSecHeader
        }

        import DefaultSecHeader

        # Ensure that the server does not run out of memory
        request_body {
                max_size 10MB
        }

        handle /YOURSECRETPATH {
                reverse_proxy 127.0.0.1:15000
        }

        handle {
                root * /var/www/YOURDOMAIN.TLD/
                file_server
        }
}

With that I can reach and use my own WebTunnel bridge.

2 Likes
2

It is even in the Debian repo: apt-get install caddy

And I have to agree the caddy default page in Debian 12 is definitely better than the one from nginx…

:smiley_cat:

3

I use the developers’ repo because the version in it is much more up-to-date - as is so often the case compared to Debian’s own repos. Especially in view of the fact that the service is publicly available on the net.

I did exactly the same with nginx.

4

Similar simplicity can be achieved on Apache by enabling mod_md.

apt install apache2
a2enmod md
systemctl restart apache2

Virtual host configuration example for Apache is here.

5

I’d be quite interested to know about Caddy’s efficiency. Specifically memory, thread, and CPU usage. I have, in the past, observed several other services written in go have been inefficient in the extreme.

It is also something to note that go-tls is very restrictive. It offers no fine-tuning and no way to select or reject algorithms. So, if like me, you do not feel that (for example) secp curves are secure, then for literally any TLS service written in go you are out of luck.

That said, caddy does look quite compelling. I tend to be wary of “just relax, we will do everything for you, you don’t need to worry about a thing, trust us!” systems, which is a very “go” thing and which caddy seems to espouse.

1 Like
6

I’d be quite interested to know about Caddy’s efficiency. Specifically memory, thread, and CPU usage. I have, in the past, observed several other services written in go have been inefficient in the extreme.

In my experience, Caddy uses 3x the resources compared to NGINX. If I have very limited memory/CPU, I’d use NGINX. But if you have the resources and enjoy the benefits of Caddy, then by all means, it’s a fine webserver.

2 Likes
7

Editor war, browser wars, web server wars… But probably usual in times of Information warfare^^

:dove: