Hacker News Reader

Comment by dovholuknf | Hacker News Reader

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.

View on HN

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?

edit, this is what I'm looking for: https://github.com/openziti/fabric/blob/main/docs/p12_smart_...

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 ...

What attacks does this realistically protect from? Is it for when you want to run a process in a Raw Sewage network?

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

Reply on news.ycombinator.com