Skip to content

PATTERN Cited by 1 source

Noise over HTTP

Pattern

Use the Noise Protocol Framework as the cryptographic envelope for a security-critical RPC channel, running it over HTTP (not directly over TCP, not over TLS). The Noise framing provides authenticated, confidential channels between peers with very narrow (pinned) keypair lists; HTTP provides familiar routing, proxying, and load-balancing.

Why not just TLS?

TLS does authenticated-confidential channels well, but the certificate-based authentication model leans toward "anyone with a valid cert from any valid CA". For a token-authority service where "across many thousands of machines, there are only a handful with the cryptographic material needed to mint a new Macaroon token", you want explicit keypair pinning at the application layer — not PKI semantics.

Fly.io's trajectory (source: sources/2025-03-27-flyio-operationalizing-macaroons):

  1. v0: RPC over NATS message bus. Product security team rejected: "Our product security team can't trust NATS (it's not our code). That means a vulnerability in NATS can't result in us losing control of all our tokens, or allow attackers to spoof authentication."
  2. v1: Implement Noise directly. "I highly recommend implementing Noise; the spec is kind of a joy in a way you can't appreciate until you use it, and it's educational." Plain TLS over NATS isn't possible ("NATS is a message bus, not a streaming secure channel") — Noise over NATS works because it's a framed protocol.
  3. v2: Migrate transport to HTTP but keep the Noise layer. "Out of laziness, we kept the Noise stuff, which means the interface to tkdb is now HTTP/Noise. This is a design smell, but the security model is nice."

The design-smell admission is important — it's a demo of why it's defensible rather than a claim it's optimal.

Two Noise handshake variants

Fly.io uses Noise's handshake-pattern vocabulary directly:

  • Noise_IK — like normal TLS. "Anybody can verify, but everyone needs to prove they're talking to the real tkdb." Used on the verification path: many thousands of callers.
  • Noise_KK — like mTLS. "Only a few components in our system can mint tokens, and they get a special client key." Used on the signing path: very narrow set of clients.

Handshake-pattern choice maps directly to the principal-set trust model per endpoint — finer-grained than PKI-style CA-chained authentication.

When this is worth doing

  • Extremely sensitive RPC where the keypair-pinning model is a better fit than X.509 PKI.
  • Service boundaries where you don't want to inherit CA- ecosystem risk (BYOCA-style risk).
  • Engineering teams with the budget to implement a non-stock cryptographic envelope correctly and keep it correct.

When it's wrong

  • Most RPC. TLS with service mesh + certificate rotation is operationally simpler and plenty secure. The Fly.io authors are explicit that this was motivated by the original NATS move, not a pure-design optimum.

Seen in

Last updated · 319 distilled / 1,201 read