←back to thread

I finally understand Cloudflare Zero Trust tunnels

(david.coffee)
311 points eustoria | 3 comments | 16 Nov 25 17:39 UTC | HN request time: 0s | source
Show context
jchw ◴[16 Nov 25 20:21 UTC] No.45948083[source]▶
One thing that makes Cloudflare worse for home usage is it acts as a termination point for TLS, whereas Tailscale does not. If you use a Tailscale Funnel, you get the TLS certificate on your endpoint. With Cloudflare, they get a TLS certificate for you, and then strip and optionally re-add TLS as traffic passes through them.

I actually have no idea how private networks with WARP are here, but that's a pretty big privacy downgrade for tunneling from the Internet.

I also consider P2P with relay fallback to be highly desirable over always relaying traffic through a third party, too. Firstly, less middlemen. Secondly, it continues working even if the coordination service is unavailable.

replies(11): >>45948135 #>>45948861 #>>45950399 #>>45950603 #>>45950673 #>>45950728 #>>45951628 #>>45951656 #>>45951950 #>>45957225 #>>45963338 #
gz5 ◴[17 Nov 25 03:41 UTC] No.45950673[source]▶
The other option from this great list https://github.com/anderspitman/awesome-tunneling which seems to meet both sets of goals is NetFoundry.

1. End-to-end encryption.

2. Performance and reliability. 100+ PoPs in all major clouds running their data plane routers if they host (still E2EE), or run routers anywhere if you self-host. Dynamic routing to find best paths across the routers.

replies(1): >>45954212 #
indigo945 ◴[17 Nov 25 15:04 UTC] No.45954212[source]▶
I don't see any indication that NetFoundry zrok supports end-to-end encryption from the client to the web server. The default configuration definitely terminates SSL on NetFoundry's server, and I don't see any documentation for how to avoid that. There's a TCP tunneling mode, but servers that use this mode can only be accessed by clients that are themselves also connected to the NetFoundry VPN service, not by clients on the public web. What's needed is a TLS tunneling mode that figures out the correct target via SNI, and zrok doesn't seem to provide that.
replies(1): >>45954441 #
dovholuknf ◴[17 Nov 25 15:31 UTC] No.45954441[source]▶
You are correct, zrok doesn't support mutual TLS. zrok is the free offering that NetFoundry supports so it's easy to see why you looked there for information.

The productized version, NetFoundry Frontdoor (doc here https://netfoundry.io/docs/frontdoor/how-to-guides/create-mt...) is what offers mutual TLS support.

It'll still terminate TLS at the servers, though. It's not mTLS all the way through to the endpoint.

replies(1): >>45954647 #
1. indigo945 ◴[17 Nov 25 15:50 UTC] No.45954647{3}[source]▶

    > It'll still terminate TLS at the servers, though. It's not mTLS all the way 
    > through to the endpoint.
That was the entire point, though. If NetFoundry Frontdoor can see the traffic (because it gets terminated on their servers, mTLS or not), then it's not end-to-end encrypted as the parent commenter claimed.
replies(2): >>45957709 #>>45957851 #
2. gz5 ◴[17 Nov 25 20:11 UTC] No.45957709[source]▶
i should have been more clear - you have the option:

+ e2ee via netfoundry's zero trust products

+ non-e2ee via netfoundry frontdoor

3. gormami ◴[17 Nov 25 20:24 UTC] No.45957851[source]▶
I think the issue is zrok vs. NetFoundry/OpenZiti. Zrok is the easy button to project a public endpoint from inside a network. It is not encrypted all the way through, as it is a proxy solution. NetFoundry/OpenZiti provides methods to provide tunnels all the way through. NetFoundry is a company, OpenZiti is a FOSS project/technology sponsored by NetFoundry, and zrok is a product of NetFoundry built on OpenZiti tech, so it is easy to cross things up. I think the comment was in regard to NetFoundry/OpenZiti, while your response referenced zrok. The list above has both.