I created this project to demonstrate the ease of embedding OpenZiti SDK in golang applications. The server is a fully functional MQTT server listening on the overlay network without any open listening ports. The client can be used for testing.
Not OP but I also work on the OpenZiti project. Yeah that's basically the idea. The biggest difference is that the "VPN Connection" is basically entirely handled by the SDKs on both sides and only available to strong identities that are authorized to send data/act as the server. No IP addresses to worrry about, no ports to open at all not even to localhost. Those SDKs connect to the overlay network (the "VPN"), the network sends the bits to the server and you have a solid, zero trust MQTT connection with e2ee as well. Neat stuff.
Ok, but you're going to need to open at least a port to your overlay network service. So "no open ports" isn't really true. And how is security better than using a TLS encrypted MQTT connection?
No ports are required to be opened at the edge (i.e., source and destination). The OpenZiti edge makes outbound connections using the strong identity into the fabric mesh network. Therefore its only the fabric dataplane which needs inbound ports but it does not listen to any connections other than those of edge components which are authenticated and authorised.
Vs standard MQTT there are several advantages incl. (not limited):
- mTLS connections rather than just TLS
- least privilege and microsegmentation
- outbound only (authenticate and authorise before connect) meaning we can close or deny inbound connections at source and destination
- private DNS with unique naming (e.g., instead of xxx.xxx.xx.xx to antoher IP, you could say MQTT client to MQTT server
- smart routing on the overlay to reduce latency, increase availability and in general increase visibilty without owning the underlay network
This implies that Ziti layers the stream endpoints on top of a packet switched network, which could mean authentication of each packet and maintaining stream reliability in a different way than TCP does. Is that correct?
Yes. All connections are synthesized over the same connection to the overlay, making all your traffic look like "port 443" (or whatever port you use for the data plane). Inferring traffic from port number is thus made even harder.
OpenZiti is using TCP to deliver packets to the routers, so TCP is still used there for stream reliability. Once delivered to the overlay fabric, the fabric is responsible for delivering the payloads as quickly as possible to the endpoint reliably. It uses TCP currently but we've worked on using other protocols like UDP.
Ok, thanks. The Ziti mesh optimizes for latency. Does it move existing streams around the fabric mesh when it finds a better route or only new streams? Are there plans for multicast?
Yes. If it needs to reroute, it will do so as long as the "terminating" site doesn't go offline. That's the one maintaining the "final" TCP stream so that one can't be rerouted.
Multicast support has been discussed, but it's not at the top of the pile of features that are getting worked at this time that I know of. I'm sort of on the other end, closer to the SDKs than the fabric, but I am pretty sure it's not in the immediate priority list as I recall.
Sorry, I should clarify. The overlay network definitely has a listening port/s. The network will be somewhere (usually best on the open internet) listening that is quite correct, that port is listening.
The "no open ports" bit comes from the MQTT client and the MQTT server. Those have no open, listening ports because they will establish connections to the edge-routers. They'll have outbound connections, but no open ports.
The security is better than TLS for a few reasons, mostly it's due to the whole "no open ports" on the server or the client. That's a pretty big difference. Also the connections will be mutual TLS, not only TLS to the server. There's other zero trust things that the overall OpenZiti overlay covers too. So there's a bunch of good reasons and I didn't want to blather on ...
Not gonna lie - "Raw Sewage network" is pretty spot on. A huge part of zero trust principles is that all networks are untrustworthy, raw sewage networks.
So the types of attacks that this protects against are all the 0day CVEs that are AV:N/PR:N. (attack vector=network, privileges required=none). That's the sort of thing like log4shell and the like. The only devices that could leverage those types of attacks would be trusted and authorized identities. That's probably a small number of machines, making the attack that much harder.
Also DoS attacks are a lot harder because the "server" (whatever accepts connections) is generally dark to the network and only available over the overlay network. Being on the same subnet (or you know, the whole internet) doesn't help if you're not authorized to access the service in the first place.
Where it's really cool is that you don't need to worry about cloud ACLs. Pick your laptop from one raw sewage network to another and it doesn't matter. You don't need to whitelist a new IP in the ACL. That's really convenient for today's road warriors. Similarly, you don't need to whitelist the whole enterprise's exit IP to the cloud.
So that sort of thing. Hopefully that answers your question enough but if not lemme know
there are few things that improve your defense posture:
- DDOS attacks can only attack the fabric and not the business logic service. Fabric nodes can be easily moved around or added to change attack surface.
- you can have multiple services hidden and you don't have to worry about protecting them individually
- service nodes themselves can be moved around or added for redundancy without having to stand up additional protection middleware
Zero trust (ZT) is a set of ideas to move defenses from static, network-based perimeters to focus on users, assets, and resources. It allows us to focus is on protecting resources and applications, not network segments (which are inherently insecure).
ZT assumes there is no implicit trust granted to assets or user accounts solely on their physical or network location or asset ownership. Authentication and authorization need to be performed before a session to an enterprise resource is established.
OpenZiti provides anyone the tools to embed zero trust mesh networking into their solution or application. It allows you to close all inbound ports on your firewall (one inbound firewall rule of deny-all), making your network unreachable from other networks, at layer 3. Your private OpenZiti Fabric allows your apps and users to outbound connect both 'sides' of the app, e.g. a client and server, into one bidirectional session, regardless of which side initiated the specific connection request.
I like the way metadat put it: "a Raw Sewage network". Zero trust is the idea that all networks are hostile and you shouldn't trust any of them.
Worst case scenario, when you attach to an unknown network (public WiFi) without knowing what other devices are on that network, they might be hostile and attempt to attack/compromise the machine that just joined the network.
Sometimes it's not active. Other compromised machines might do the same even on a trusted network like the corporate LAN or just your friend's house WiFi.
So zero trust encourages you to trust no network, open no hole in your firewall, allow no inbound connections. Any connections that are established need to be verified first before allowing the connection.
17 comments
[ 2.9 ms ] story [ 55.7 ms ] threadVs standard MQTT there are several advantages incl. (not limited): - mTLS connections rather than just TLS - least privilege and microsegmentation - outbound only (authenticate and authorise before connect) meaning we can close or deny inbound connections at source and destination - private DNS with unique naming (e.g., instead of xxx.xxx.xx.xx to antoher IP, you could say MQTT client to MQTT server - smart routing on the overlay to reduce latency, increase availability and in general increase visibilty without owning the underlay network
edit, this is what I'm looking for: https://github.com/openziti/fabric/blob/main/docs/p12_smart_...
OpenZiti is using TCP to deliver packets to the routers, so TCP is still used there for stream reliability. Once delivered to the overlay fabric, the fabric is responsible for delivering the payloads as quickly as possible to the endpoint reliably. It uses TCP currently but we've worked on using other protocols like UDP.
Multicast support has been discussed, but it's not at the top of the pile of features that are getting worked at this time that I know of. I'm sort of on the other end, closer to the SDKs than the fabric, but I am pretty sure it's not in the immediate priority list as I recall.
The "no open ports" bit comes from the MQTT client and the MQTT server. Those have no open, listening ports because they will establish connections to the edge-routers. They'll have outbound connections, but no open ports.
The security is better than TLS for a few reasons, mostly it's due to the whole "no open ports" on the server or the client. That's a pretty big difference. Also the connections will be mutual TLS, not only TLS to the server. There's other zero trust things that the overall OpenZiti overlay covers too. So there's a bunch of good reasons and I didn't want to blather on ...
So the types of attacks that this protects against are all the 0day CVEs that are AV:N/PR:N. (attack vector=network, privileges required=none). That's the sort of thing like log4shell and the like. The only devices that could leverage those types of attacks would be trusted and authorized identities. That's probably a small number of machines, making the attack that much harder.
Also DoS attacks are a lot harder because the "server" (whatever accepts connections) is generally dark to the network and only available over the overlay network. Being on the same subnet (or you know, the whole internet) doesn't help if you're not authorized to access the service in the first place.
Where it's really cool is that you don't need to worry about cloud ACLs. Pick your laptop from one raw sewage network to another and it doesn't matter. You don't need to whitelist a new IP in the ACL. That's really convenient for today's road warriors. Similarly, you don't need to whitelist the whole enterprise's exit IP to the cloud.
So that sort of thing. Hopefully that answers your question enough but if not lemme know
- DDOS attacks can only attack the fabric and not the business logic service. Fabric nodes can be easily moved around or added to change attack surface.
- you can have multiple services hidden and you don't have to worry about protecting them individually
- service nodes themselves can be moved around or added for redundancy without having to stand up additional protection middleware
ZT assumes there is no implicit trust granted to assets or user accounts solely on their physical or network location or asset ownership. Authentication and authorization need to be performed before a session to an enterprise resource is established.
OpenZiti provides anyone the tools to embed zero trust mesh networking into their solution or application. It allows you to close all inbound ports on your firewall (one inbound firewall rule of deny-all), making your network unreachable from other networks, at layer 3. Your private OpenZiti Fabric allows your apps and users to outbound connect both 'sides' of the app, e.g. a client and server, into one bidirectional session, regardless of which side initiated the specific connection request.
Worst case scenario, when you attach to an unknown network (public WiFi) without knowing what other devices are on that network, they might be hostile and attempt to attack/compromise the machine that just joined the network.
Sometimes it's not active. Other compromised machines might do the same even on a trusted network like the corporate LAN or just your friend's house WiFi.
So zero trust encourages you to trust no network, open no hole in your firewall, allow no inbound connections. Any connections that are established need to be verified first before allowing the connection.