Rust and Elixir libraries for end-to-end encrypted secure communication(github.com)
github.com
Rust and Elixir libraries for end-to-end encrypted secure communication
https://github.com/build-trust/ockam
20 comments
Aw. Thanks for posting this. Hi, I'm Matt, the CEO at Ockam. If anyone has any questions, we are happy to take them on in this thread today.
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
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
Great question!
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.
5. Encrypted Relays through Ockam Orchestrator. UDP hole puncturing coming soon.
6. Store keys and run cryptography in hardware or in cloud KMS.
7. Plug into enterprise Identity Providers and Policy Providers and enforce Attribute based access control policies.
8. Operate very lightweight credential authorities
9. Scale Enrollment Protocols, Credentials rotation/revocation etc.
and more.
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.
5. Encrypted Relays through Ockam Orchestrator. UDP hole puncturing coming soon.
6. Store keys and run cryptography in hardware or in cloud KMS.
7. Plug into enterprise Identity Providers and Policy Providers and enforce Attribute based access control policies.
8. Operate very lightweight credential authorities
9. Scale Enrollment Protocols, Credentials rotation/revocation etc.
and more.
I have a few questions:
- Are there any benchmarks?
- 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.
- Are there any benchmarks?
- 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.
Thanks for trying out the examples:
1. No benchmarks yet. We'd welcome contributions & research in that area.
2. Here's an example of using the TCP transport without using an Inlet / Outlet. https://github.com/build-trust/ockam/blob/develop/documentat...
Give it a try. Would love to know if that fits what you're going for.
1. No benchmarks yet. We'd welcome contributions & research in that area.
2. Here's an example of using the TCP transport without using an Inlet / Outlet. https://github.com/build-trust/ockam/blob/develop/documentat...
Give it a try. Would love to know if that fits what you're going for.
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 see that Worker has `is_authorized` method and even before that method executed `Mailbox` also uses, so I see how to avoid issue from above. However, middle node would forward any traffic without any questions unless https://docs.rs/ockam/latest/ockam/struct.Context.html#metho... is used? Then I'm curious if middle node will be able to use https://docs.rs/ockam/latest/ockam/access_control/struct.Ide... given that it doesn't know much about the channel?
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.
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 see that Worker has `is_authorized` method and even before that method executed `Mailbox` also uses, so I see how to avoid issue from above. However, middle node would forward any traffic without any questions unless https://docs.rs/ockam/latest/ockam/struct.Context.html#metho... is used? Then I'm curious if middle node will be able to use https://docs.rs/ockam/latest/ockam/access_control/struct.Ide... given that it doesn't know much about the channel?
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.
To move this off of HN and to a channel that we look at more regularly, I'd like to suggest a couple alts: 1) GitHub Discussions: https://github.com/build-trust/ockam/discussions/categories/...
2) We can schedule a zoom call: https://www.ockam.io/contact/form
To move this off of HN and to a channel that we look at more regularly, I'd like to suggest a couple alts: 1) GitHub Discussions: https://github.com/build-trust/ockam/discussions/categories/...
2) We can schedule a zoom call: https://www.ockam.io/contact/form
Does the name Ockam have any relation to Occam's Razor?
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.
The full story: https://www.ockam.io/blog/whats_behind_the_ockam_name
The full story: https://www.ockam.io/blog/whats_behind_the_ockam_name
If they solved only discovery, handshake and hole-punching problems and made relay optional, it would be more useful. Also, for relay, if they provided store-and-forward and also scatter/gather topologies, it would be more useful.
Key/Route Discovery, Credential Issuance/Presentation, Secure Channel Handshakes and Message Routing that is decoupled from transport protocols have been our main focus.
We chose to build the more reliable e2ee strategy first - Relays. UDP hole puncturing is in development right now. However there is extensive research that proves it in only successful in making connections in 60 to 80% of real world networks. This is why Signal does relays for example. Relays provide a highly reliable strategy. So we knew we'll want to support both and give devs and option to choose what is right for their application. Or failover from one to the other.
In addition, relays also allow store and forward and integration to other enterprise systems like Kafka. This is how we're able to to move end-to-end encrypted data through Kafka https://github.com/build-trust/ockam/tree/develop/documentat...
Store and forward as a first class feature is in development.
Scatter/Gather is a much harder problem since it involves group key agreement and challenges that come with doing that safely. This is in our long term roadmap, but we've not done any development for this yet.
We chose to build the more reliable e2ee strategy first - Relays. UDP hole puncturing is in development right now. However there is extensive research that proves it in only successful in making connections in 60 to 80% of real world networks. This is why Signal does relays for example. Relays provide a highly reliable strategy. So we knew we'll want to support both and give devs and option to choose what is right for their application. Or failover from one to the other.
In addition, relays also allow store and forward and integration to other enterprise systems like Kafka. This is how we're able to to move end-to-end encrypted data through Kafka https://github.com/build-trust/ockam/tree/develop/documentat...
Store and forward as a first class feature is in development.
Scatter/Gather is a much harder problem since it involves group key agreement and challenges that come with doing that safely. This is in our long term roadmap, but we've not done any development for this yet.
great feedback!
What is the business model for this? The enterprise addons?
We have two products. The first is avail under Apache 2 lic. The second is available as a paid subscription through AWS marketplace.
1. Ockam Open Source: It's all the protocols, packages, and tools (like CLI) for building things.
2. Ockam Orchestrator: It allows for running small to massive scale systems. It's also has add-ons for Okta, Confluent Cloud, various DBs...
1. Ockam Open Source: It's all the protocols, packages, and tools (like CLI) for building things.
2. Ockam Orchestrator: It allows for running small to massive scale systems. It's also has add-ons for Okta, Confluent Cloud, various DBs...
I just wanted to compliment you on your landing page :)