Summary

  • Four government TLS guidelines produced non-compliance rates ranging from about 14% to 80% when applied to the same 50.7 million Server Hello packets from one research institution over 14 days.
  • The study counted 6.85 million handshakes using X25519MLKEM768, a hybrid post-quantum key-exchange group that the four evaluated guidelines did not mention. “Not listed” is not the same as “broken.”
  • TLSGatekeeper can observe selected handshake parameters and optionally block connections without decrypting application traffic. Its 100-Gbps result came from a lab setup with blocking disabled, not a reported production deployment.

The percentage that changes with the rulebook

In a network-security dashboard, “80% non-compliant” looks like a property of the network. In this case it is also a property of the rulebook chosen to score it.

A guest post on the APNIC Blog describes research by Henrique Becker Brum and colleagues at the University of Trento and Fondazione Bruno Kessler. Their paper, published as arXiv:2605.31020v1, compares a two-week sample of TLS traffic against four national cybersecurity guidelines: Italy’s ACN, France’s ANSSI, Germany’s BSI and the United States’ NIST. For the three measured fields, the study reports non-compliance ranging from roughly 14% under ANSSI to 80% under NIST.

That gap is the story. A connection does not change when the selected guideline changes. The label does. And if an organization turns that label into an automatic block, a choice about how to interpret a document becomes a decision about which connections its users are allowed to make.

This is not an argument that guidelines are useless or that their differences are arbitrary. They are written for different public-sector environments, threat models and transition paths. It is an argument for preserving the distinction between a known weakness, an explicit policy prohibition and a value the policy has not yet assessed. A system that collapses all three into “non-compliant” may be easy to automate and hard to explain.

What the researchers actually measured

The capture ran from 13 to 26 October 2025 on traffic crossing Fondazione Bruno Kessler’s institutional network edge, from internal clients to external servers. After cleaning, the authors report 155,066,707 packets, of which 50,744,009 Server Hello packets formed the basis for examining server-selected TLS version, cipher suite and supported group.

Those numbers are large enough to reveal patterns inside that network. They do not turn one institution into a global census. A handshake count is not a count of unique organizations, users or servers. Workstations, services, visitors, remote workers and the institution’s own operating schedule shape the sample. The paper itself describes a single institutional network; the authors call it diverse, but that is not a substitute for geographic or industry-wide sampling.

The boundary matters because the headlines can invite a bigger claim than the design supports. The paper does not audit each server’s full configuration, certificates, software, deployment context or behavior after the handshake. Its “compliance” calculation covers three selected server-side values, in a sequential test: version, then cipher suite, then supported group. Once an earlier field failed the selected guideline, later fields were not counted as the reason for that record’s non-compliance. The result is a useful comparison of observed handshake values with specific rules, not a complete security certification of endpoints.

That is already enough to expose an operational problem: the rules do not describe one universal vocabulary of acceptable values.

“Unlisted” is a fourth state, not a verdict

The most consequential example is X25519MLKEM768. The dataset records 6,845,778 Server Hello packets selecting the group—about 13.5% of the sample. In the paper’s table, it appears among values that caused a handshake to fail a guideline comparison but were not mentioned in any of the four evaluated documents.

The name combines X25519, a widely deployed classical elliptic-curve group, with ML-KEM, the post-quantum key-encapsulation mechanism standardized by NIST in FIPS 203. That does not make every handshake “quantum-safe.” The observed value is evidence that the server selected a hybrid group in this sample. It does not establish the whole connection’s security properties, client implementation, application behavior or end-to-end migration status. Nor should it be confused with X25519Kyber768_Draft00, an older draft value that the paper treats separately.

But the measurement has a sharper implication than a generic “PQC is coming” forecast. A compatibility list that has not yet named a new value can classify real use as non-compliant even when the research authors do not identify a known vulnerability in that value. The list has encountered something outside its vocabulary. That is a reason to review the rule—not proof that the implementation should be blocked.

The same tension appears in the other direction. The paper notes that Curve25519 is widely used and accepted by major browsers but not approved in the evaluated NIST guideline. It also notes that ChaCha20-Poly1305 is a modern cipher that NIST discourages. Neither observation means a public authority’s requirements should be ignored. It means that “fails one baseline” and “is cryptographically broken” are different assertions, with different evidence and consequences.

The system needs more than a binary flag. At minimum, operators need to distinguish:

  • explicitly prohibited by a named, dated policy;
  • permitted under that policy;
  • not assessed or not yet listed;
  • known vulnerable under an identified technical basis.

The last category should not be inferred from the first or third. A policy may deliberately reject a value for reasons beyond a demonstrated break. That decision can still be valid within its scope. The telemetry should tell the operator which reason applied.

From observation to enforcement

The authors built TLSGatekeeper to move from measurement to control. It is an XDP/eBPF network middlebox that inspects selected fields from server handshake messages, compares them with a chosen policy, logs the result and can optionally block a connection. It does not decrypt application content. Because it reads server-selected handshake values, Encrypted Client Hello’s concealment of client-side SNI does not hide the specific fields it analyzes.

That design changes where responsibility sits. Rather than updating each browser or application, an organization can put a policy point on the egress path for many clients. That can help where devices are numerous, temporary or outside direct endpoint-management control. It can also create a shared failure surface: a mistaken rule, parser limitation or unreviewed update can affect every client whose traffic passes through the middlebox.

The engineering demonstration is notable, but its scope must stay attached to the number. The evaluation used two BlueField-2 data-processing units connected at 100 Gbps inside one server. With sixteen background traffic streams, the link approached the DPUs’ throughput limit. The paper reports average inspection delays of 671 nanoseconds for TLS 1.3 and 795 nanoseconds for TLS 1.2 per handshake packet.

Those are lab measurements of packet processing, not a guarantee that every deployed network will sustain line rate under every traffic mix. More importantly, the performance experiment configured the tool not to block: packets passed to the host stack with XDP_PASS. The reported result therefore shows that the tested parser could inspect traffic under that setup with very low measured overhead. It does not establish the operational reliability of active blocking, the quality of a chosen policy, a customer rollout or a failure-recovery record.

The implementation also has a defined boundary. It handles traditional TLS over TCP, not QUIC or DTLS. A network adopting it would need to know which traffic bypasses that inspection and how those paths are governed. “No decryption” is a meaningful privacy property, but it does not mean “no policy power”: a middlebox that can replace a handshake packet with an alert can still prevent a connection from forming.

The APNIC connection—and its limit

The venue matters because APNIC’s blog is a public technical forum for research and operational discussion across the Asia Pacific. It is not evidence that APNIC built, tested or deployed TLSGatekeeper. The authors’ own affiliations and the blog’s guest-post disclaimer make that distinction explicit.

For regional operators, the useful question is not whether one national guideline should win. It is how a local policy becomes an operational decision. A regulator may define a mandatory profile for a specific class of public service. A university may choose a different baseline for managed devices. A network team may need to permit an emerging key exchange while it completes a security review. Those decisions can coexist if the system records which authority applies, to whom, for which protocol and from which document version.

An allowlist without that context travels badly. A value acceptable for one profile can be rejected by another. A policy update can make a previously observed connection appear newly non-compliant even when the endpoint did not change. An algorithm can move from experimental to standardized faster than an agency revises its guidance. If logs retain only “blocked: non-compliant,” an incident responder may not be able to reconstruct which rule made the decision or whether the value was prohibited, unassessed or merely absent from a list.

That is a provenance problem as much as a cryptography problem. A reliable security decision should carry the field tested, the observed value, the policy identifier and edition, the reason for rejection, the time of the decision and the route to an exception or correction. Without those, an automated control can be deterministic in code and opaque in governance.

A safer translation from guideline to packet

The study does not prescribe a control model for every operator. One defensible approach is to store policy state in three explicit classes: allowed, prohibited and not assessed. Known vulnerable values can be marked separately with a technical rationale. “Not assessed” should generate visibility and review, not silently inherit the blocking behavior of “prohibited.”

Where blocking is required, operators can stage a new rule in observation mode, measure which real connections it would affect, identify affected services, then roll it out to a limited segment before wider enforcement. The rule should carry its source document, date, owner and expiration or review trigger. Exceptions need an accountable approver and end date. The rollback path should be tested before the policy is made network-wide.

These are editorial recommendations, not capabilities the paper claims TLSGatekeeper already provides. They follow from the gap between a document-level comparison and a packet-level action. Policy authors control the language; network operators control local adoption; software maintainers control parser behavior; users bear failed connections. A compact receipt should preserve those boundaries rather than make the middlebox appear to discover a universal truth called compliance.

Heng Lu’s Note 64 offers a useful design lens: a common technical baseline should not make every future choice a central permission decision. Here that does not mean ignoring public-sector rules. It means being precise about the scope of a rule and local about how an operator evaluates its consequences. The distinction is especially important when the most visible “failure” is a cryptographic option that the guidance has not caught up with.

What this evidence can—and cannot—settle

The researchers show that a large institutional sample contained modern and legacy TLS values, that guideline outcomes diverged, and that a network middlebox can inspect selected handshake fields at high measured throughput in a lab. They do not show how often organizations block these values in production, how often a block harms users, whether the sample represents the wider Internet or what adoption of hybrid key exchange means for end-to-end security.

Those gaps are not reasons to discard the research. They are the boundary between a useful measurement and an unsupported deployment claim. The strongest result is not “80% of TLS is insecure.” It is that the same observed traffic can score very differently under four authoritative rule sets—and that an operator can turn those differences into network-level decisions.

When the rulebook says “not listed,” the packet processor should not invent the missing rationale. Someone must decide whether the value is forbidden, merely unassessed or allowed under a more current local policy. That decision should be visible, reviewable and reversible. Otherwise the allowlist does more than enforce security guidance: it silently becomes the security policy itself.

Sources