This one is pretty weird. All the docs about everything talk about privacy and security and Ockam Orchestrator. This last part seems to be a completely proprietary and undocumented cloud service. Why would anyone trust this?
The Portals for Mac app is an example of the type of thing you could build using the open source stack of protocols. The README (linked by parent) links out to all of the relevant parts of the protocol documentation to explain how these work together. The NAT Traversal (https://github.com/build-trust/ockam/blob/develop/examples/a...) part of the README is probably the best explanation of why the free relay you get via Ockam Orchestrator is a useful part of this demo.
As for why would anyone trust this: The protocols are designed so you absolutely don't have to trust the relay. Trust is pushed out to the edges that you control and so you're not susceptible to a MITM attack if something like a relay is compromised. The protocol design for all of this is open and documented, and was independently audited by (IMO) some of the best in the business, Trail of Bits: https://docs.ockam.io/reference/protocols.
I don't find it the least bit interesting. Rust is good for reducing memory related bugs, it's not like many of these projects require that and it's not like you can't have the same level of safety using other languages if you have quality code. I'm not hating on rust, it's a plenty fine language with great safety and features. It's just irrelevant to most of the projects listed.
Looks good, Matt, and thanks for open source and SaaS flexibility. Can you add to or correct the comparisons to OpenZiti and Wireguard to help us frame the sweet spot for Ockam?
OpenZiti
In common: mTLS w/ built in PKI mgmt; attribute based access control; SDKs to embed in apps.
Different: OpenZiti includes the network overlay as well. Ockam add-ons may target other use cases?
Wireguard
In common: E2E encryption; hosted SaaS avail
Different: UDP hole punching; network-level segmentation; no mTLS; no app embed
I led the design of Ockam. I am somewhat familiar with Wiregaurd and not at all familiar with OpenZiti. All tools that are helping us build application that have much much smaller vulnerability surfaces are awesome!!
Some things that you can do with Ockam:
1. Create Noise based secure channels all sorts of multi-hop, multi-protocol, network topologies - TCP <> TCP, or TCP <> TCP <> TCP, or UDP <> Kafka <> TCP, or BlueTooth <> TCP <> TCP etc.
2. Move end-to-end encrypted data through Kafka, RabbitMQ, and other messaging and streaming systems.
3. Run on small embedded devices (Rust no_std) or run on large servers.
- Examples are focused around TCP inlet to TCP outlet. Any way you can add more complicated examples? I take I can have a TCP inlet and a Worker that would would receive TCP stream wrapped into Routed, then I can unwrap it and work with it kinda as if it was “normal” TCP.
I’m curious about second one because while connecting some clients to legacy is fun, it’s more fun when services connected directly. For example, I want some kind of RPC or database without “external” TCP connection from node to database.
That's close to what I was thinking. I guess a message here could be just a bag of bytes, and then you can plug listener side into `tower` stack.
Can't exactly wrap my head around access control here. In this example, let's assume I'm using a proper policy and not `TrustEveryonePolicy`. What's stopping someone from using this route: route![(TCP, "localhost:3000"), (TCP, "localhost:4000"), "echoer"]; in this example?
I'm just working on something that could use this, but right now, we use wireguard + nftables + convoluted routing policies + TLS. I would go far to not use TLS and manage X.509 infrastructure and hopefully avoid double encryption.
would you like to schedule some time with us to dig into this further. This sounds really interesting and pretty close to things we've seen others do before.
Good question. It's a nested reference. I named the company Ockam as a tribute to a company that a mentor of mine built and ran in the 70's - 2000's. He named his company after Occam's Razor.
One good thing about data from Sequoia is that they handle payroll for a lot of companies. They know exactly what companies are paying each of their employees, so it's a really good data set from that perspective. It's not self-reported by employees, for example.
