[HN Gopher] Show HN: MQZiti - Zero Trust MQTT server and client
___________________________________________________________________
Show HN: MQZiti - Zero Trust MQTT server and client
Author : ekoby
Score : 24 points
Date : 2022-08-25 19:55 UTC (3 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| RedShift1 wrote:
| So it's like creating a VPN connection and then connecting to
| your MQTT(/whatever) service?
| [deleted]
| dovholuknf wrote:
| 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.
| RedShift1 wrote:
| 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?
| PLG88 wrote:
| 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
| injinj wrote:
| 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/op
| enziti/fabric/blob/main/docs/p12_smart_...
| dovholuknf wrote:
| 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.
| injinj wrote:
| 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?
| dovholuknf wrote:
| 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.
| dovholuknf wrote:
| 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 ...
| ekoby wrote:
| 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.
___________________________________________________________________
(page generated 2022-08-25 23:00 UTC)