Great question! Yes you can use Ockam in that setting to terminate encryption just before your cloud service needs to use the data instead of at the LoadBalancer or another intermediary like Cloudflare.
The Ockam TCP transport can move end-to-end encrypted through a Layer 4 Network Load Balancer. The Ockam WebSocket transport can move end-to-end encrypted through a Layer 7 Application Load Balancer.
Great question. It helps to think in terms of vulnerability surfaces and the amount of harm that can be caused by a compromise.
If we use a VPN, then access is controlled to the boundary of that VPN. All code that is running within that boundary must remain secure for our remote services to stay protected. This is a large vulnerability surface, the likelihood of a compromise is proportional to the the size of our vulnerability surface.
If any service within a VPN boundary is compromised, then there are no safeguards preventing an attacker from jumping service to service and causing a lot more harm.
With VPNs, our vulnerability surface is large and amount of harm that can happen is also very large.
In contrast, the approach described in the above guide dynamically creates short-lived access to a specific service. In such a setup, our vulnerability surface is a lot smaller - it is limited to the code of our secure tunnel and our target service. It doesn't include all the other code within the same network boundary because our target is not listening on a network accessible port - even within its local network - it only needs to listen on the loopback address.
Just-in-time, short lived creation and deletion of the Inlet also reduces the amount of time traffic can reach the private service - which further reduces our vulnerability surface,
If a compromise does happen, the amount of harm that can be caused is also a lot smaller, in this setting, because other services within the same boundary also don't have open unnecessary ports - lateral movement becomes a lot more difficult for an attacker.
1. The protections of TLS are constrained by the length and duration of the underlying TCP connection. If an application's data flow involves two or more TCP connections then TLS can't guarantee end-to-end data integrity and authenticity.
If an application involves communication between entities that are not online at the same time or if the data flow involves multiple transport protocols like the first hop is bluetooth and the second hop in TCP etc. - In all these cases TLS and other transport layer solutions cannot keep an applications data safe from forgery and tampering.
Turns out application entities are rarely connected by a simple point-to-point TCP connections - even the simplest web app these days is at least - on tcp hop to a load balancer, second tcp connection hop to an application web server. For example, in a different guide, we show how application data could remain end-to-end protected while traveling from Alice to a Cloud Service to Kafka to Bob https://github.com/ockam-network/ockam/tree/develop/document...
2. Our long term plan is to have Ockam libraries available in many languages. We started our development in C and Elixir and later added Rust.
Elixir - because it's easy to scale concurrent messaging systems on the Erlang BEAM virtual machine (see RabbitMQ, WhatsApp, Discord and many other messaging systems that have achieved scale with Erlang BEAM).
C - because we want to support embedded environments along with server environments. However, a few months into developing with C, our team discovered Rust and got very excited about how memory safety features of Rust eliminate a large class of security bugs. It is much easier to create performant yet loosely coupled abstractions in Rust - this makes it possible for us to keep our library modular and pluggable. Rust tooling is also a lot better than C so we've moved development focus from C to Rust.
Later we plan to wrap the Rust library in FFI wrappers and expose it in other languages (including C). The Ockam Elixir library already uses our Rust crates for various cryptographic features.
Can this library help me if I have existing sensors I'd like to connect to securely? E.g. could I somehow proxy their requests to our remote backend via some local application?
That's an awesome question! Yes, any arbitrary protocol can be tunneled through an Ockam SecureChannel. So if you have a device that produces readings as some binary structure or JSON or some other encoding ... a secure channel can deliver that data end-to-end protected to your backend application. You can even tunnel high-level protocols through a secure channel, we recently tried tunneling SSH through Ockam to create secure remote access to a machine that is behind a NAT .. and it worked like a charm.
To make this simple and transparent, we're building a feature called Transport Inlets & Outlets. With that you can easy create a proxy (either on the same device if it has an OS or in a nearby device) without modifying your original device application - the code of your sensor. There is an open PR on TCP Inlets & Outlets (portals), if you're interested: https://github.com/ockam-network/ockam/pull/1756
