Am I the only one who is having trouble understanding what this is doing, and why I would want to use it? Maybe I should have had that cup of coffee earlier.
In the simplest terms, it's an application embedded VPN (on both client and server)
The SDK allows you to integrate OpenZiti directly into your applications so that it can access network resources securely from anywhere in the world. This is based on strong identity so that the overlay cannot be access by untrusted endpoints. This is ensuring your application has zero trust in the network, WAN, LAN and even host OS - in fact, your app does not even need to know the IP and port to communicate with on the underlying host.
Comparing to traditional VPNs this solution is a lot more secure -- instead giving you access to internal network, OpenZiti gives you access to specific service endpoints.
> Also what the threat model is, and how ziti solves it.
Your service (anything that accepts incoming connections) is never exposed to open internet. any incoming connections are guaranteed to be from authenticated and authorized clients.
> I assume it does little to thwart traffic analysis?
It does -- the traffic is routed throw OpenZiti fabric.
> Does it suffer from tcp-over-tcp problems?
OpenZiti is not a VPN and it does not forward network packets. In application embedded cases payload is end-to-end encrypted and forwarded on overlay network.
> Would be fair to say it's similar to a private Tor network with hidden services - but without anonymity and (probably much) higher throughput?
I believe that is a fair comparison, except anonymity is replaced with strong identity support to allow configuration of authorization policies.
> OpenZiti is not a VPN and it does not forward network packets. In application embedded cases payload is end-to-end encrypted and forwarded on overlay network.
Ok, but messages/RPC calls go over the network - can i return a 1gb video file/stream/fragment - or send real-time audio - or is it limited to more of a "secure RPC"?
I more meant: what is the network transport like - does it offer tcp-like guarantees and re-submissions, along with poor suitability for real-time streams? How does it cross firewalls (that increasingly filter by protocol)?
at this time OpenZiti connection are guaranteed-delivery (like TCP). We are evaluating offering lossy connections in the future.
At the edges connection are always outbound and are seen as mTLS to the firewalls. the application payloads are end-to-end encrypted (using libsodium) an d transferred inside mTLS channels
You are not, every time I look at the OpenZiti site I get more confused, but I also can't really figure out why. The team behind OpenZiti is super helpful, and I wish I could provide them feedback like "This confused me" or "this isn't clear", but I can't really figure it out.
My TL;DR of OpenZiti is:
It is a meshed overlay with endpoint authentication and ACLs. Endpoints can be: application-embedded (think TLS) or system level (think PtP VPN) or routers to subnets (think routing VPN).
One thing that took me a long time to wrap my head around is: You can incrementally implement OpenZiti by: setting it up as a traditional VPN, then start putting individual server endpoints directly on OpenZiti, then put individual services directly on the fabric (application embedded).
This is a pretty accurate description of OpenZiti.
The incremental approach is something that many of our customers go through: start with tunneling agents (quick and low investment), then transition to application embedded solutions
There is a lot of truth to this. To provide some further context on differences with a comparison of Tailscale and OpenZiti.
- Tailscale is a great VPN, super easy to use. Being based on wireguard means, it differs from OpenZiti (note, I work on the project too).
- Tailscale has proprietary features to make it easier to use (e.g., DERP). OpenZiti includes those as part of open source.
- Wireguard/TS will allow peers to join the same network segment, so if I want to restrict access, I have to start using firewalls to block ports or implement segmentation. This can be surmised as WG being 'default-open' whereas OpenZiti is 'default-closed' with outbound tunnels, least privilege, micro-segmentation, and attribute-based access.
- Wireguard/TS really cares about "connecting machines" and not so much about connecting "services". This includes operating at the host level. While OpenZiti can do this too, it also has SDKs which can be embedded in an application. That's useful for developers or creating 'clientless' solutions, which we are actively working on.
OpenZiti uses the Windows TUN (WinTun) that the Wireguard project made as (at least) part of our Windows tunneler. Thanks, Wireguard!
This is very cool, Python is my primary programming language and OpenZiti is something that looks promising for communication between public endpoints (like a Lambda receiver for Slack messages) and private infrastructure (like triggering a cron job to run).
How does this compare with libp2p? Every time I try to use it I get the feeling that the python support was abandoned half-way, maybe OpenZiti would be better.
The good news is you don't have to stand up your OpenZiti network to try it out.
We have Ziti Edge Developer Sandbox (ZEDS) https://zeds.openziti.org exactly for this reason. It is a simple way to try OpenZiti, and exercise OpenZiti SDKs.
Am I the only one who is having trouble understanding what this is doing, and why I would want to use it? Maybe I should have had that cup of coffee earlier.
In the simplest terms, it's an application embedded VPN (on both client and server)
The SDK allows you to integrate OpenZiti directly into your applications so that it can access network resources securely from anywhere in the world. This is based on strong identity so that the overlay cannot be access by untrusted endpoints. This is ensuring your application has zero trust in the network, WAN, LAN and even host OS - in fact, your app does not even need to know the IP and port to communicate with on the underlying host.
Comparing to traditional VPNs this solution is a lot more secure -- instead giving you access to internal network, OpenZiti gives you access to specific service endpoints.
Thank you. It was entirely opaque for me from the "about" page what it allowed me to have "zero trust" in.
Also what the threat model is, and how ziti solves it.
I assume it does little to thwart traffic analysis?
Does it suffer from tcp-over-tcp problems?
Would be fair to say it's similar to a private Tor network with hidden services - but without anonymity and (probably much) higher throughput?
> Also what the threat model is, and how ziti solves it.
Your service (anything that accepts incoming connections) is never exposed to open internet. any incoming connections are guaranteed to be from authenticated and authorized clients.
> I assume it does little to thwart traffic analysis?
It does -- the traffic is routed throw OpenZiti fabric.
> Does it suffer from tcp-over-tcp problems?
OpenZiti is not a VPN and it does not forward network packets. In application embedded cases payload is end-to-end encrypted and forwarded on overlay network.
> Would be fair to say it's similar to a private Tor network with hidden services - but without anonymity and (probably much) higher throughput?
I believe that is a fair comparison, except anonymity is replaced with strong identity support to allow configuration of authorization policies.
Thank you!
> OpenZiti is not a VPN and it does not forward network packets. In application embedded cases payload is end-to-end encrypted and forwarded on overlay network.
Ok, but messages/RPC calls go over the network - can i return a 1gb video file/stream/fragment - or send real-time audio - or is it limited to more of a "secure RPC"?
Absolutely, from your application's view it is just a socket that can live and be used to send/receive data indefinitely
I more meant: what is the network transport like - does it offer tcp-like guarantees and re-submissions, along with poor suitability for real-time streams? How does it cross firewalls (that increasingly filter by protocol)?
at this time OpenZiti connection are guaranteed-delivery (like TCP). We are evaluating offering lossy connections in the future.
At the edges connection are always outbound and are seen as mTLS to the firewalls. the application payloads are end-to-end encrypted (using libsodium) an d transferred inside mTLS channels
You are not, every time I look at the OpenZiti site I get more confused, but I also can't really figure out why. The team behind OpenZiti is super helpful, and I wish I could provide them feedback like "This confused me" or "this isn't clear", but I can't really figure it out.
My TL;DR of OpenZiti is:
It is a meshed overlay with endpoint authentication and ACLs. Endpoints can be: application-embedded (think TLS) or system level (think PtP VPN) or routers to subnets (think routing VPN).
One thing that took me a long time to wrap my head around is: You can incrementally implement OpenZiti by: setting it up as a traditional VPN, then start putting individual server endpoints directly on OpenZiti, then put individual services directly on the fabric (application embedded).
OpenZiti team: Is this a fair TL;DR?
This is a pretty accurate description of OpenZiti.
The incremental approach is something that many of our customers go through: start with tunneling agents (quick and low investment), then transition to application embedded solutions
It looks like it's like tailscale/zerotier but at the individual app level rather than the device level.
There is a lot of truth to this. To provide some further context on differences with a comparison of Tailscale and OpenZiti.
- Tailscale is a great VPN, super easy to use. Being based on wireguard means, it differs from OpenZiti (note, I work on the project too). - Tailscale has proprietary features to make it easier to use (e.g., DERP). OpenZiti includes those as part of open source. - Wireguard/TS will allow peers to join the same network segment, so if I want to restrict access, I have to start using firewalls to block ports or implement segmentation. This can be surmised as WG being 'default-open' whereas OpenZiti is 'default-closed' with outbound tunnels, least privilege, micro-segmentation, and attribute-based access. - Wireguard/TS really cares about "connecting machines" and not so much about connecting "services". This includes operating at the host level. While OpenZiti can do this too, it also has SDKs which can be embedded in an application. That's useful for developers or creating 'clientless' solutions, which we are actively working on.
OpenZiti uses the Windows TUN (WinTun) that the Wireguard project made as (at least) part of our Windows tunneler. Thanks, Wireguard!
is it app embedded VPN?
I am happy to introduce OpenZiti Python SDK.
It allows you to:
* embed zero trust secure networking right into your Python application
* run your Python services without any open network ports.
Powered by: https://github.com/openziti/ziti
How does Ziti compare to something like nats (https://nats.io)?
I am not deeply familiar with nats.io, so I could be wrong in my comparisons.
OpenZiti is a connection-oriented overlay network vs NATS a messaging system.
OpenZiti SDKs are more easily embeddable in existing applications as it does not require changes in networking semantics.
FWI, the OpenZiti project 'integrated' their Go SDK into NATS last year - https://www.youtube.com/watch?v=8V_HlDZy6M8&ab_channel=OpenZ....
I say 'integrated' as it was a quick and dirty integration rather than anywhere near production ready.
Congrats on the release!
- Your former Orion pal, P :)
This is very cool, Python is my primary programming language and OpenZiti is something that looks promising for communication between public endpoints (like a Lambda receiver for Slack messages) and private infrastructure (like triggering a cron job to run).
funny you should mention this, here is another post covering exactly that: https://news.ycombinator.com/item?id=32924212
Thanks for that pointer, didn't see that.
How does this compare with libp2p? Every time I try to use it I get the feeling that the python support was abandoned half-way, maybe OpenZiti would be better.
there are significant differences from libp2p:
* strong identity support: authenticate before connect
* it is service oriented vs point-to-point
We would love for you to try OpenZiti it give us feedback :)
It'll be a bit. Gotta get standalone mode working before I go multiuser, but I absolutely will.
The good news is you don't have to stand up your OpenZiti network to try it out.
We have Ziti Edge Developer Sandbox (ZEDS) https://zeds.openziti.org exactly for this reason. It is a simple way to try OpenZiti, and exercise OpenZiti SDKs.