The Tunnel daemon creates an encrypted tunnel between your origin web server and Cloudflare’s nearest data center, all without opening any public inbound ports.

From https://www.cloudflare.com/products/tunnel/

The answer depends on how you’re serving your content. Based on what you’ve described about your setup, your content is likely served over HTTP through the secured tunnel. The tunnel acts like an encrypted VPN, which allows unencrypted content to be sent securely over the wire. This means although your web server is serving unencrypted content, it gets encrypted before it goes to Cloudflare, so no one along the path could snoop on it.

The tunnels are encrypted. But I don’t know if they use SSL or something else.

You should be able to set it up, which seems to be the crux of your question.

The reason for the conflict is likely that the traffic is encrypted through the tunnel, but cloudflare holds the certificates needed to verify the identity of your site and can see all the traffic.

But tunnels are done by having your server initiate the connection with cloudflare, so it behaves like a client in terms of networking, and it should work in most cases.

(Worth noting that video was against their policies for using at least the free tunnels last I was aware, so if that’s part of your use case you might not be able to use it.)

Cloudflare tunnels uses a QUIC connection between the cloudflared on the server and Cloudflare itself, which is encrypted similarly to HTTPS.

Whatever protocol cloudflared uses to talk to your webserver locally is configurable through the Cloudflare access web UI (just change http to https). I’ve actually got it configured to use unix sockets, which lets me treat it differently in my nginx config.

I believe Cloudflare has a trusted root cert that is distributed with browsers and such, and for tunnels, they generate a signed cert for that hostname interaction, and act as a reverse proxy to your machine when called. This should always show as an HTTPS host, but there must be a mechanism via DNS or something to identify and authorize your host to serve HTTPS, and if that lapses for some reason, I would assume they default to plain HTTP.

I’m just thinking about this logically and having used this particular setup though.

Nobody can answer this because it depends entirely on how you set it up. It can be set up either way. Whatever you point your internal endpoint at is what it is.

Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

6 acronyms in this thread; the most compressed thread commented on today has 10 acronyms.

[Thread #929 for this sub, first seen 20th Aug 2024, 20:05] [FAQ] [Full list] [Contact] [Source code]