I appreciate your thoughtful reply and I didn't think you were tossing any shade for what it's worth. I was just arguing that to me, both are "app embedded". IMO, the fact that traffic relays or not to me is non-consequential, what's important is where the encryption starts and where it ends (and where authorization happens but that's also separate). If it starts the client and ends at the 'server' then it's fully e2ee -- it doesn't matter if traffic traverses only IP-based underlays or if it traverses over an overlay at that point.
I very much appreciate the "outsider" perspective though and thank you very much for sharing it. That perspective is impossible to obtain after you work on a project for long enough! :)
At this time OpenZiti still operates in relay pattern. All your traffic travels through an OpenZiti router. It's also a zero trust overlay so having an external server is important to make policy decisions about whether an identity is authorized to dial a service or not. OpenZiti also allows for bespoke pathing via OpenZiti routers so that path traversal over the overlay is also coordinated.
The project has been moving to supporting directly connecting to other identities but it hasn't been a priority yet.
The connections an OpenZiti identity makes to another OpenZiti identity are direct-over-OpenZiti (not direct over IP underlay) if that makes sense. I don't know if you'll ever be able to have two process communicate without that third 'arbiter' process (I'll call it). It might happen, but right now it seems less likely than the direct connect approach.
hope that helps. But you can definitely have an SDK app client connect to an SDK app "server" and be fully zero trust, fully app embedded, fully end to end encrypted, peer-to-peer (over the overlay) connections.
OpenZiti has numerous SDKs. If you are a developer and you can integrate an SDK into your application, it 100% is application-embedded. It is incorrect stating that it can't be app-embedded... (i am a maintainer on the project). Perhaps I just don't understand the response?
FINALLY. This is actually exciting to me... Mind you the linux ports (cygwin, msys2, git bash) are all great to have and I make sure one version or the other is always on my path but having MS maintain them (assuming they continue to do so) is great news
Tailscale and Wireguard are great. I'm an OpenZiti maintainer and I've written/spoken about application embedded zero trust for many, many years. Still it seems most devs don't think it's important for whatever reason... It'll make me happy if Tailscale is successful here and can spread the word out to get more devs interested in embedding the secure connectivity directly into the apps instead of relying on the classic underlay network and bolting on security. If that sort of thing interests you, you could check out OpenZiti. It's not Wireguard-based for better or for worse you can decide (if you do end up checking it out)
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.
You don't need to dream about it. You can absolutely do this today with OpenZiti. You just need to be able to set it up which is - imo (I am a dev on the project and wrote the quickstarts) just as easy to get up and running as anything. I do it in "under a minute" but I work on the project so my timing is not fair... :)
You can find information about it over at https://openziti.github.io/ you don't even need to trust the software itself. You can add a 3rd party certificate to the server and mint your own private keys/certs and deliver them to your friends and have 100% control over where and how and whom you trust. You control access down to individual services, not CIDR blocks, not IP addresses. You can embed the sdks into any of your own apps if you're into that sort of thing. :) you could setup a relay server in some cloud provider for the 'untrusted' traffic (hmmmm you make me wonder if we could integrate with tor somehow now too...)
Seems like it'd do most/much of the things you want it to. I'd be happy to help you out. We have a discourse you can post questions to.
i generally end up liking what teleport is doing and what they are all about... i keep meaning to try their opensource stuff out. does teleport's sshd 'listen' on port 22 and does it need an opening in a firewall?
still, having sshd listen on localhost and not a public ip is pretty cool imo. Ken and I did exactly that on a stream one day https://youtu.be/oSlwZcwZcsU if anyone is interested. The one extra step one could do is to convert sshd to only allow connections from localhost by editing /etc/ssh/sshd_config and set the ListenAddress to only 127.0.0.1
I very much appreciate the "outsider" perspective though and thank you very much for sharing it. That perspective is impossible to obtain after you work on a project for long enough! :)
Cheers!