The presence of TLS on a connection does not automatically guarantee secure communication. In reality, outdated protocol versions and incorrect setup frequently undermine the security benefits that TLS is meant to provide. Achieving genuine security demands careful attention to configuration choices and staying current with evolving threats. Yet for many system administrators, tracking the latest vulnerabilities and determining the right settings to address them remains difficult. To help standardize these decisions, major cybersecurity authorities across multiple countries have released their own TLS configuration recommendations.

Guidelines fall short of real-world practice

While guidelines offer clear direction on what configurations to use and what to avoid, their actual uptake in production environments remains inconsistent. Many administrators rely on default settings, and enforcement mechanisms are often weak. To understand how well guideline recommendations match what organizations actually deploy, researchers collected more than 50 million TLS handshakes over a two-week period from their institution. They examined three key parameters that servers select during the handshake—protocol version, cipher suites, and supported groups—and compared them against recommendations from four national authorities.

  • Agenzia per la Cybersicurezza Nazionale (ACN, Italy)
  • Agence nationale de la sécurité des systèmes d'information (ANSSI, France)
  • Bundesamt für Sicherheit in der Informationstechnik (BSI, Germany)
  • National Institute of Standards and Technology (NIST, United States of America)

The research revealed a striking mismatch: many handshakes used options that none of the four guidelines mentioned at all. What made this finding particularly significant was not the existence of these options, but their volume. Guidelines are designed to establish a baseline for secure configurations rather than enumerate every possible parameter. However, the rapid industry adoption of Post-Quantum Cryptography algorithms—with seven million handshakes using the X25519MLKEM768 supported group alone—exposes a critical weakness in current guidelines: they cannot keep pace with real-world innovation. Major providers like Cloudflare and Google have already deployed these newer options at scale, yet the guidelines have not adapted quickly enough to remain authoritative.

A network-based enforcement approach

Securing servers is manageable compared to securing clients at organizational scale. Clients are diverse, temporary, and often beyond IT control—from corporate workstations to personal phones constantly joining and leaving the network. Configuring each device individually is impractical. To address this challenge, researchers developed TLSGatekeeper, a tool that operates at the network level to protect clients from connecting to servers with weak TLS configurations.

TLSGatekeeper monitors outbound TLS handshakes and checks whether the server's selected parameters comply with a chosen security policy. Violations can trigger either logging or immediate blocking. Unlike traditional Next-Generation Firewalls, which block only legacy TLS versions or a fixed set of weak ciphers, TLSGatekeeper offers full flexibility in defining prohibited values and can directly enforce policies from established guidelines. Crucially, the tool never decrypts traffic, preserving end-to-end encryption.

Performance at line rate

Since TLSGatekeeper must inspect packets in real time without adding latency, the team built it using eXpress Data Path (XDP), attaching it directly to the network interface driver. This approach allows rapid packet parsing with minimal overhead for both TLS and non-TLS traffic. Testing showed the tool can sustain throughput near 100Gbps while handling thousands of TLS handshakes per second. The average inspection delay was only 671 nanoseconds for TLS 1.3 and 795 nanoseconds for TLS 1.2 per handshake packet at 100Gbps, demonstrating that network-wide TLS gatekeeping is practical at scale.

Future directions

The research points to several areas for continued work:

  • Continuous monitoring of TLS deployments: The dataset captured a snapshot of TLS options at a specific time and location. Ongoing monitoring and reporting of common TLS configurations would provide visibility into global adoption patterns and help track whether new standards are actually being deployed.
  • Faster guideline updates: Cybersecurity agencies need to respond more quickly to emerging standards and technologies, especially when adoption is driven by major industry players whose choices affect security across the Internet.
  • Network-based task offloading: Technologies like XDP and Programming Protocol-independent Packet Processors (P4) enable programmability in the data plane, making it possible to offload targeted security tasks for immediate performance gains.