Posted on

Traffic Management With Istio (1): Unified Management of TCP Ingress Traffic Routing Based on Istio Rules

The Istio traffic management model basically allows for the decoupling of traffic from infrastructure scaling, allowing operations personnel to specify the rules to apply to traffic using Pilot instead of specifying which pods/VMS should receive traffic. Decoupling traffic from infrastructure scaling allows Istio to provide a variety of traffic management functions independent of application code. The Envoy sidecar proxy implements these functions.

In a typical mesh, you often have one or more finalizing external TLS connections at the end to guide traffic into the mesh's load balancer (known as a gateway); the traffic then flows through internal services after the sidecar gateway. The following figure illustrates the use of gateways in a mesh:

Posted on

Using TLS in Rust: The Complexity of Async, Macros, and Madness

After a lot of trouble, I’m really happy that I was able to build an async I/O implementation of my protocol. However, for real code, I think that I would probably recommend using with the sync API instead since at least it's straightforward and doesn’t incur so much overhead at development time. The async stuff is still very much a “use at your own risk” kind of deal from my perspective. And I can’t imagine trying to use it in a large project and no suffering from the complexity.

As a good example, take a look at the following bit of code:

Posted on

Using TLS With Rust: Authentication

After running into a few hurdles, I managed to get rust openssl bindings to work, which means that this is now the time to actually wire things properly in my network protocol. Let’s see how that works, shall we?

First, we have the OpenSSL setup:

Posted on

Using TLS in Rust: Getting Async I/O With tokio (Part 2)

On my last post, I got really frustrated with tokio’s complexity and wanted to move to using mio directly. The advantages are that the programming model is pretty simple, even if actually working with it is hard. Event loops can cause your logic to spread over many different locations and make it hard to follow. I started to go that path until I figured out just how much work it would take. I decided to give tokio a second change, and at this point, I looked into attempts to provide async/await functionality to Rust.

It seems that at least some work is already available for this, using futures + some Rust macros. That let me write code that is much more natural looking, and I actually managed to make it work.

Posted on

Using TLS in Rust: Going to async I/O With tokio (Part 1)

Now that we have a secured and authentication connection, the next stage in making a proper library is to make it run more than a single connection at a time. I could have used a thread per connection, of course, or even use a thread pool, but neither of those options is valid for the kind of work that I want to see, so I’m going to jump directly into async I/O in Rust and see how that goes.

The sad thing about this is that I expect that this will make me lose some/ all of the nice APIs that I get for OpenSSL in the sync mode.

Posted on

Trust Models for Secure Network Connections

The Concept of Trust in Cybersecurity

Everyone is talking about the strength of cryptography and its susceptibility to new generations of computing programs. For example, there’s a wealth of discussion about preferable algorithms that should be used for authentication and encryption. Much of this debate is framed within the context of fears and assumptions about a future in which quantum computing holds sway.

Quantum computing may make it possible to execute certain algorithms in a matter of seconds instead of days. The ramifications, should this eventuality come to pass, are huge, not just for cryptocurrencies but for the entire Internet. A quantum breakthrough raises the risk of breaking most of our existing encrypted security protocols — think online banking, VPNs, database storage, digital signatures, blockchains, and disk encryption. Although it looks like functional quantum computers are still a few years off, no one can be entirely sure quite how well they will work against cryptography until they are readily available.

Posted on

Server Name Indication (SNI) and Ingress TLS in Kubernetes with Ambassador

The open-source Ambassador 0.50 API gateway adds support for Server Name Indication (SNI), a much-requested feature from the community that allows the configuration of multiple TLS certificates to be served from a single ingress IP address. In this tutorial, we explore how multiple secure domains (e.g., https://www.datawire.io and https://www.getambassador.io.) can be provided by a single or load balanced Ambassador running within a Kubernetes cluster.

SNI Use Cases

In a nutshell (and with thanks to Wikipedia), SNI is an extension to the TLS protocol, which allows a client to indicate which hostname it is attempting to connect to at the start of the TCP handshaking process. This allows the server to present multiple certificates on the same IP address and TCP port number, which in turn enables the serving of multiple secure websites or API services without requiring all those sites to use the same certificate.