A broker cluster encrypts client connections but not the node-to-node hop — what is exposed there?

## The two hops a record crosses A broker cluster does not present one wire to protect. It presents at least two kinds of connection, and an operator configures encryption on each kind separately. - **The client hop** — the connection between an application and a node. A writer sending records in, a reader pulling them out, an operator issuing an administrative call. This is the connection that leaves your network, terminates in someone else's code, and appears in every security review. - **The node-to-node hop** — the traffic between cluster members. Where copies of a record are kept by one node forwarding it to others, the record body travels here in full; alongside it runs the coordination traffic that settles which node currently owns which part of a stream, which copies are caught up, and who has joined or left. Because a cluster can answer on several separately-configured endpoints, each with its own rules, "the cluster is encrypted" is not one fact. It is one fact per hop, and in most estates the honest reading is: the client hop yes, the node-to-node hop no. ## What actually crosses the unencrypted hop - **Whole record payloads.** Replication is not a digest or a checksum exchange. A node that must hold a copy receives the body. Anything sensitive that was protected on the way in is unprotected on the way across. - **Routing keys, headers and timestamps.** The key is frequently the account, device or customer identifier. It leaks even when a reader would find the body meaningless. - **Coordination traffic.** Not payload, but it describes the cluster: who leads what, which copies are behind, when membership is changing. That is a map of where the system is weak and when. - **More bytes than the reviewed hop, usually.** If every record is kept in three places and copies are made by forwarding, the writer sent the record once and the cluster ships it twice more. The hop nobody looked at carries the larger share of the record bytes. - **Continuously.** Replication is not a migration window that closes. It runs for as long as the cluster is up, and it re-runs in bulk whenever a node is rebuilt. ## Why this is the hop that stays open 1. **Reviews follow exposure.** The threat model people write starts at the client and stops at the first thing that answers it. Traffic between machines that are all "ours", often on one private network, is assumed rather than examined. 2. **Turning it on is a cluster-wide change, not a client-side one.** Encrypting the client hop can be rolled out per application; encrypting the node-to-node hop touches every member and every member's trust set at once, so it is easy to defer and hard to schedule. 3. **The cost is visible and the risk is not.** Encrypting the node-to-node hop has a measurable throughput price on some platforms, and no visible benefit on the dashboard the next morning. 4. **On a rented cluster you may not be able to see it.** A managed tier may encrypt member traffic for you, may do it on a network you never see, and may not expose the setting at all — which is an answer, but only if you have asked for it in writing rather than assumed it. ## Where platforms differ | Cluster shape | What the node-to-node hop carries | What encrypting it mainly costs | |---|---|---| | Copies kept by nodes forwarding records | Full record bodies, once per extra copy, plus coordination | Throughput on the busiest flow in the cluster | | Storage shared beneath the members | Mostly coordination and metadata; little or no per-record copy | Little; the hop is small | | Rented, operator-run | Whatever the operator says, on a network you cannot inspect | Nothing you pay separately — but also nothing you control | This is why a candidate should never answer as if every cluster replicates records between nodes. It is the common shape, not the universal one, and saying which shape you mean is part of the answer. ## What to ask about a cluster you inherited - Which endpoints does this cluster answer on, and what is the encryption rule on each? - Are records forwarded between nodes here at all, or is storage shared beneath them? - Does the coordination traffic travel on the same connection as the record copies, or on its own — and is the second one configured? - If a copy is mirrored to another cluster, is that a third hop with its own rules? It almost always is, and it usually crosses more network than either of the first two. - If the cluster is rented, what has the operator actually committed to for member traffic?