up:: Migration Architecture MOC

Wire Over Config

Wire over config is the verification rule for negotiated cryptography: the configuration is the menu, and the wire is what was ordered. A configuration file lists every cryptographic option a system is willing to use, and each real connection then settles on one option from that list, chosen jointly with whatever client showed up. So a configuration states an upper bound on the cryptography a system runs, while the wire, the record of what live connections actually negotiated, states the fact. Verification is the negotiated reality, and its instrument is a single pull: every distinct cipher suite, key-exchange group, and certificate signature algorithm the system negotiated in the last 30 days, with counts, taken from the edge devices and load balancers that terminate the traffic and are usually logging it already.

The short version:

• The config lists what a system permits. The wire records what real connections chose. Verification reads the wire.
• A server passes its configuration review and still negotiates the weakest permitted option every day, because that’s what an old client keeps asking for.
• The instrument is one pull: every distinct cipher suite, key-exchange group, and certificate signature algorithm negotiated in the last 30 days, with counts.
• The logs usually exist already at the network edge and the load balancers, so the pull is a question to whoever runs that tier rather than a tooling purchase.
• Where there’s no wire to read (SaaS platforms, vendor-sealed surfaces), the rule degrades honestly to configuration plus a dated written attestation, labeled as the weaker evidence it is.

The menu line carries the whole rule, so play it out. Auditing a restaurant’s menu tells you what the kitchen is willing to cook, and an impressive menu passes that audit easily. It still tells you nothing about dinner service, because a kitchen can print a careful, health-forward menu and spend the whole night sending out fried food, since that’s what the regulars keep ordering. The stack of order tickets is the only document that records what the kitchen actually produced, and the tickets come with counts, so they show which items dominated, which appeared once, and which were never ordered at all. Cryptographic verification reads the tickets.

What does wire over config actually say?

The rule has two halves, a claim and an instrument, and both are precise.

The claim: for any protocol where cryptography is negotiated per connection, the configuration is an upper bound on what runs, never a statement of what ran. Reviewing the configuration verifies the menu. Verifying the cryptography means reading the negotiated outcomes on real traffic.

The instrument: one pull, specified tightly enough to hand to a network team as written.

1. Scope: every TLS termination point you control, starting at the network edge, the load balancers, and the CDN configuration, because that tier consolidates the traffic of everything behind it.
2. Fields: the negotiated cipher suite, the negotiated key-exchange group, and the certificate signature algorithm actually served, per connection. Protocol version rides along free in nearly every log format.
3. Window: the last 30 days.
4. Shape: distinct values with counts, so every outcome carries its share of the traffic.

The rule applies wherever a protocol negotiates: TLS on every HTTPS, API, and service-to-service connection, SSH key-exchange lists, IPsec proposal sets. Each of those protocols opens with the two sides comparing menus and settling on an option, so each has a config that permits and a wire that records.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, §4.1.2 and §4.2.7 (the client’s offered lists and the server’s selection), August 2018, datatracker.ietf.org.

Source: T. Ylonen, C. Lonvick, “The Secure Shell (SSH) Transport Layer Protocol,” RFC 4253, §7.1 (Algorithm Negotiation), January 2006, datatracker.ietf.org.

The rule stops where negotiation stops. Cryptography that’s fixed at build time or applied to data at rest (disk encryption, code signing, key wrapping) has no per-connection choice to observe, so its verification instruments are different: certificate inventories, key-management records, and the evidence layers a cryptographic bill of materials collects. Wire over config is the verification instrument for the negotiated layer specifically, and the negotiated layer is where the gap between permitted and actual grows widest.

Why is a configuration an upper bound and never a fact?

Because in a negotiated protocol, the configuration controls only one side of a two-sided choice. A TLS handshake opens with the client listing the versions, cipher suites, and key-exchange groups it supports, and the server then picks from the overlap between that list and its own configuration. The full mechanics live in TLS; the piece that matters here is the shape of the decision. The server’s config defines the permitted set, the client’s offer defines what’s reachable within it, and every connection lands wherever that intersection puts it.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, §4.1.2 and §4.2.7, August 2018, datatracker.ietf.org.

Clients arrive as a population, and the population has a long tail. A browser updated last week negotiates the best option on the menu. Alongside it come an SDK pinned in a partner’s build years ago, a payment terminal, a monitoring agent, a warehouse scanner, and a batch job that connects on the last day of every month, each offering only what it learned when it was written. Keep TLS 1.2 enabled for compatibility, and every session with a client that never learned 1.3 is a TLS 1.2 session, quietly, daily, while the configuration review reads “TLS 1.3 preferred.” The scale of that tail is measurable: a 2026 study of Nginx configurations published on GitHub found 28.9% of TLS-enabled contexts still specifying RSA key exchange with no forward secrecy, a pattern that survives on menus precisely because old clients keep ordering it.

Source: Balaji, H., et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955, 2026, arxiv.org.

The post-quantum rollout sharpens the same gap. A server can enable the hybrid group X25519MLKEM768 and still complete a meaningful share of its handshakes on classical key exchange, because a client never offered the group or because a middlebox on the path broke the oversized ClientHello and the connection fell back to a non-post-quantum key agreement. TLS 1.3 Hybrid Key Exchange covers the mechanism and Downgrade and Rollback Attacks covers why the fallback is invisible by construction: a downgraded connection succeeds and looks healthy. All of it lands on the same conclusion. The config can only ever tell you what was possible, and the possible and the actual diverge every day, on real traffic, without a single error being raised.

Sources: Cloudflare, “Defending against future threats: Cloudflare goes post-quantum,” blog.cloudflare.com, for the middleboxes and load balancers that “tacitly assume the ClientHello always fits in a single packet” and for TLS 1.3 negotiation letting both sides “fall back” to a non-post-quantum key agreement when necessary. That post predates ML-KEM and tests X25519Kyber768Draft00 rather than X25519MLKEM768; Cloudflare, “The state of the post-quantum Internet,” blog.cloudflare.com, for the fallback in practice: “if the origin does not support it, we fall back to traditional key-agreement.”

What exactly do you pull from the wire?

Three fields, with counts, over 30 days, from the tier that terminates your TLS. Each element of that sentence is doing work.

The three fields.

1. The negotiated cipher suite. Under TLS 1.2 the suite name carries the key exchange and authentication inside it (ECDHE-RSA-AES128-GCM-SHA256 names all three roles), so for 1.2 traffic this field alone describes the negotiated cryptography almost completely.
2. The negotiated key-exchange group. Under TLS 1.3 this became its own field, because RFC 8446 deliberately separated the key exchange and authentication from the record-protection algorithm the cipher suite names. A TLS 1.3 suite like TLS_AES_128_GCM_SHA256 describes the record encryption and hash only, so the group field (x25519, secp256r1, X25519MLKEM768) is the only place the key exchange appears, and it’s the field that answers whether post-quantum key exchange actually happened on a connection.
3. The certificate signature algorithm actually served. Servers can hold an RSA and an ECDSA certificate side by side and select per client capability, so the certificate a config review looked at and the certificate a given connection received can differ.

Source: E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, §1.2 (the cipher-suite concept changed to separate authentication and key exchange from the record protection algorithm), August 2018, datatracker.ietf.org.

Source: nginx, “Module ngx_http_ssl_module,” multiple certificates of different types (RSA and ECDSA) per server, nginx.org.

With counts. A distinct-values list tells you the weakest thing that happened at least once. Counts tell you how much of the traffic each outcome carries, which is what separates a curiosity from an exposure, and they make the pull repeatable as a baseline: the next pull against the same fields shows whether the weak share is shrinking. One legacy negotiation in 40 million is a client to chase; 4 million is a migration finding.

Over 30 days. The window is long enough to catch weekly cycles and the month-end batch clients that a single-day sample misses, and short enough that the result describes the estate as it is now rather than a blend of eras. It’s also a workable log-retention ask for most edge tiers.

From the edge and load balancers. TLS terminates and concentrates there, so one tier of devices sees the negotiated outcome for hundreds of applications behind it, and that tier usually logs per-connection TLS details already. nginx exposes the negotiated protocol, cipher, and curve as the $ssl_protocol, $ssl_cipher, and $ssl_curve variables, and AWS Application Load Balancer access logs carry ssl_cipher and ssl_protocol fields on every entry. The pull is a log query on infrastructure you already run, which is why the first move is a question to the network team rather than a procurement.

Source: nginx, “Module ngx_http_ssl_module,” embedded variables $ssl_protocol, $ssl_cipher, $ssl_curve (1.21.5), nginx.org.

Source: AWS, “Access logs for your Application Load Balancer,” Elastic Load Balancing documentation, ssl_cipher and ssl_protocol fields, docs.aws.amazon.com.

What does the pull look like on a real system?

Take a generic public API edge. The numbers below are illustrative; the shape is what recurs. The configuration review passed cleanly: TLS 1.3 preferred with 1.2 retained for compatibility, the hybrid group X25519MLKEM768 enabled and listed first, modern cipher suites, an ECDSA P-256 certificate installed, and a clean report from an external scan. On paper, a migrated endpoint.

The 30-day wire pull over 40 million handshakes comes back like this:

Negotiated outcome	Connections	Share	What it means
TLS 1.3, X25519MLKEM768, ECDSA cert	24.4M	61%	Post-quantum key exchange genuinely happened here
TLS 1.3, classical x25519, ECDSA cert	11.2M	28%	Clients without the hybrid group, plus paths where a middlebox forced classical retry
TLS 1.2, ECDHE secp256r1, RSA cert	4.0M	10%	Clients that never learned TLS 1.3, served the RSA fallback certificate
TLS 1.2, RSA key transport, RSA cert	0.4M	1%	One partner’s pinned integration, no forward secrecy at all

The config predicted none of these proportions, because it couldn’t: every row is the intersection of the menu with a different client population. Read as a migration statement, 39% of this endpoint’s sessions ran classical key exchange and remain harvestable, the 1% slice is decryptable with a stolen server key and no quantum computer at all, and a third of connections received an RSA certificate the config review never mentioned, because the dual-certificate selection happens per client. The endpoint that “passed everything” is 61% migrated, and now, for the first time, that’s a number with evidence under it, a denominator, and a trend line waiting for the next pull.

The recurring gaps are worth tabulating, because they’re the failure modes the rule exists to catch:

What the config says	What the wire shows	Why the gap exists
TLS 1.3 enabled and preferred	A steady share of TLS 1.2 sessions	Old clients never offer 1.3, and the server picks from the intersection
Hybrid group enabled, listed first	Classical key exchange on a meaningful share of connections	Clients without the group, plus middlebox drops that trigger a classical retry
Weak suite removed last quarter	The suite still appearing in fresh negotiations	A second listener, a forgotten config file, or another termination point still serving the old menu
Strong options listed first	Weak-but-permitted options negotiated daily	Preference ordering steers the choice; permission decides what can be chosen at all
ECDSA certificate installed	RSA certificate served to part of the traffic	Dual-certificate deployments select the certificate per client capability

Common misconceptions

• “The configuration review is the verification.” A configuration review verifies the menu, and it’s worth doing, because a bad menu guarantees bad outcomes. It answers what the system is permitted to do. Verification answers what the system did, and only the negotiated record holds that answer. The two are different artifacts answering different questions, and a program needs both with the labels kept straight.
• “Our external scan passed, so we’re proven.” A scanner is one modern, well-behaved client making a handful of connections, so its report shows the best available intersection between the scanner and your server. It says nothing about the thousands of real clients whose intersections land elsewhere on the menu. A clean scan proves the strong option exists and is reachable, and the wire pull proves how often it’s what actually runs.
• “We disabled it, so it’s gone.” Disabling changes the menu going forward on the box you changed. Evidence that it’s gone is a wire pull after the change showing 0 negotiations of the disabled option across every termination point, and estates routinely rediscover a retired suite alive on a listener the change never reached. “We disabled it” is an intention with a date; the zero-count is the receipt.
• “We enabled the hybrid group and our test connection used it, so we’re migrated.” One test from a modern browser proves the best case exists. The client population decides everything else, which is exactly the offered-versus-used gap Downgrade and Rollback Attacks walks through, and the wire pull is the instrument that measures it.
• “Zero legacy negotiations in 30 days means zero legacy clients.” The window bounds the claim. A quarterly reporting job, an annual audit integration, or a disaster-recovery path can sit outside any 30-day sample, which is one of the reasons the pull runs on a cadence rather than once.
• “We log cipher suites, so we have this covered.” Complete for TLS 1.2 traffic, where the suite name carries the key exchange. Silent for TLS 1.3, where RFC 8446 moved the key exchange out of the suite name entirely, so cipher-suite-only logging can’t distinguish a hybrid post-quantum handshake from a classical one. The field that answers the migration question is the negotiated group, and it has to be logged explicitly.

Pro tips

1. Ask before you buy. The edge and load-balancer tier is usually logging most of these fields already, so the pull typically starts as one question to whoever runs that tier, and the gap analysis is about fields and retention rather than tooling. Reach for discovery tooling for the surfaces the edge can’t see, after the free evidence is in hand.
2. Check the group field explicitly. The negotiated key-exchange group is the blind spot in real logging setups: nginx only added $ssl_curve in 1.21.5, long after the protocol and cipher variables, and AWS ALB access logs carry the cipher and protocol with no field for the group. Many pipelines therefore record everything except the one field that says whether post-quantum key exchange happened. Confirm the field exists in your format, switch it on where it’s off, and start the 30-day clock from there.
3. Keep the denominator. Report counts and shares, never a bare list of distinct values. The share is what ranks the findings, gives the board a number it can track, and turns the second pull into a trend instead of a repeat.
4. Re-pull on a cadence. The wire changes as clients update, partners ship, and middleboxes get replaced, so a monthly pull against the same fields becomes the migration’s progress meter: the hybrid share should rise, the legacy share should fall, and a flat line names the stuck population before a deadline does.
5. Segment the weak rows. For each weak negotiated outcome, pull the client side where the logs carry it (source network, SNI, user agent), so a percentage becomes a named population with an owner. “1% RSA key transport” is a statistic; “one partner’s pinned SDK” is a work item.

Where does the rule break?

The rule breaks wherever there’s no wire you can read, and it’s built to say so out loud rather than paper over it.

1. Surfaces with no wire access. A SaaS platform, a vendor-hosted termination point, or a sealed appliance negotiates cryptography you never observe, because the handshake lands on infrastructure you can’t instrument. For those surfaces the rule degrades honestly: the evidence becomes the vendor’s configuration claim plus a dated written attestation, recorded as exactly that, attestation-grade rather than negotiated-reality-grade. The defensible sentence is “we verified what we terminate, and we hold dated attestations for the rest,” and the boundary between the two belongs on the map itself, which is the territory The Three Zones covers.
2. Cryptography that never negotiates. Data-at-rest encryption, code signing, firmware trust anchors, and key wrapping run fixed algorithms with no per-connection choice, so there’s no order ticket to read. Their verification runs on different instruments (certificate and key inventories, the evidence a CBOM assembles), and applying wire-over-config language to them overstates what the pull covered.
3. The window itself. A 30-day pull proves 30 days. Clients on longer cycles, cold standby paths, and seasonal integrations sit outside any single window, which the cadence mitigates and honesty covers: the claim is always “in this window, on these termination points,” never “ever, everywhere.”

Within its lane, one more limit deserves naming: the wire shows outcomes and only hints at causes. A classical-only session tells you post-quantum key exchange was absent, and deciding whether the cause was the client, a middlebox, or a config regression takes the follow-up work that Testing as the Control Surface describes.

How do you use it in the boardroom?

A configuration screenshot is the most common artifact offered as proof of cryptographic posture, by internal teams and vendors alike, and the rule compresses to one sentence for exactly that moment: “That shows what’s permitted. Show me every cipher suite, key-exchange group, and certificate signature algorithm we actually negotiated in the last 30 days, with counts.”

The answer sorts itself. A team that produces the pull has verification, and the conversation moves to what the counts say. A team that responds with more configuration has told you, precisely and without conflict, where the program actually stands. The same sentence works pointed upward: written into a board pack or an audit response as the acceptance standard, it makes “migrated” mean “the wire shows it,” which is a standard a regulator can also stand on.

Questions people ask

Where do these logs actually live? At whatever terminates TLS for you: the reverse proxies and web servers at the edge, the load balancers, the CDN’s log delivery, VPN concentrators, and API gateways. The owning team is usually networking or platform engineering, and the practical first step is sending them the three fields and the 30-day window as written.

What if we record the cipher suite but the key-exchange group field is off? Switch the field on, then let a full 30-day window accumulate before claiming a result. In the interim the cipher suite still fully describes your TLS 1.2 traffic, since 1.2 suite names carry the key exchange; the gap is confined to TLS 1.3 connections, which is unfortunately exactly where the post-quantum question lives.

Why 30 days instead of a week or a year? A week misses monthly clients, batch jobs, and billing-cycle integrations, so it undercounts the long tail. A year blends eras together and stalls the first result. A 30-day window catches the weekly and monthly cycles, stays current, and matches a log-retention ask most teams can meet, with the cadence covering anything slower.

Do I need new tooling for this? Usually not for the negotiated layer, because the termination tier logs it or can be switched on to log it. Tooling earns its place on the surfaces the edge can’t see, which is the broader territory of Cryptographic Discovery, and the wire pull is the evidence you collect for free before any of that.

Is this the same thing as downgrade testing? They’re adjacent and they compose. Downgrade testing actively tries to force a connection onto weak cryptography and confirms the deployment refuses or catches it, while wire over config passively measures which outcomes real traffic produced. Downgrade and Rollback Attacks covers the attack side and Testing as the Control Surface places both inside the validation stack.

Can the wire pull replace a cryptographic inventory? It’s one evidence stream inside it, and the cheapest one to start. The wire covers negotiated, in-motion cryptography at the points you terminate; a full CBOM also has to cover data at rest, code signing, embedded keys, and vendor products, so the pull seeds the inventory rather than substituting for it.

Would a packet capture do instead of logs? For a spot check, yes, and it’s the ground truth for a single connection, including reading the negotiated group directly off the handshake. For verification you need counts across a month of traffic, and per-connection negotiation logging scales to that where captured packets don’t, so captures confirm and logs measure.

What do I do with the weak rows once I have them? Each row is a client population with a share, and the counts rank them. Deciding whether a population gets upgraded, retired, or wrapped is migration sequencing, and it inherits its priorities from what the traffic protects, which is where the wire pull hands off to the risk models under Migration Architecture MOC.

---

Everything here is the map, given freely. When your team needs its own negotiated reality pulled, read, and turned into a migration baseline that stands up in front of a board or an auditor, that’s a working session with your team.

Last verified 2026-07-26 · Updated 2026-08-25 · Maintained by Addie LaMarr, LaMarr Labs.