Transport Layer Security (TLS) is the default protocol for securing communication over the Internet. We think that every time we connect to a web page that supports TLS, our data is safely transmitted. But is that always true?
In practice, TLS’s security guarantees are frequently compromised by outdated versions and misconfigurations. Merely having TLS is not enough — a secure deployment requires the proper options and configuration. However, keeping track of known and emerging vulnerabilities and identifying the optimal settings to mitigate all security risks can be a challenging task for system administrators. To establish common configuration standards, national cybersecurity agencies have published different TLS guidelines.
TLS guidelines to the rescue?
Guidelines help administrators by clearly specifying secure configurations and highlighting some options to avoid. Nonetheless, actual guideline adoption remains limited and difficult to assess, as administrators frequently use default settings and legal enforcement is often restricted.
To quantify how closely guideline recommendations align with real-world TLS deployments, we collected over 50 million TLS handshakes during two weeks from our research institution. We anonymously tracked connections from the users of our institution to external servers, and evaluated three critical server-selected parameters — version, cipher suites, and supported groups — against four national TLS guidelines:
- 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)
Our dataset is publicly available to researchers interested in analysing real-world TLS handshakes.
Industry output and guidelines responsiveness
An unexpected finding from this dataset was the presence of many handshakes using options that weren’t recommended by any of the guidelines. This finding was notable not due to the existence of these options, but because of the sheer volume of connections using them. As their name implies, guidelines are not intended to evaluate every possible TLS parameter, but rather to establish a secure configuration baseline.
However, the widespread adoption of Post-Quantum Cryptography (PQC) algorithms, exemplified by the seven million handshakes using the X25519MLKEM768 supported group, calls into question the guidelines’ choice to recommend such a limited set of options.
More importantly, this significant adoption highlights a major limitation of current guidelines: Their inability to provide timely updates to the latest developments and real-world implementations. Although the analysed guidelines were updated in the months following our research, the large-scale deployment of newly introduced options by industry giants such as Cloudflare and Google demands faster responses if these guidelines are to remain relevant.
| Value | Parameter | Category | Handshakes |
| X25519MLKEM768 | Supported group | PQC | 6,845,778 |
| FB’s TLS 1.3 draft 26 | Version | Facebook’s TLS library | 61,899 |
| X25519Kyber768_Draft00 | Supported group | PQC | 45,658 |
| TLS_RSA_WITH_RC4_128_SHA | Cipher suite | Insecure ciphers | 617 |
| TLS_DH_anon_WITH_RC4_128_MD5 | Cipher suite | Insecure ciphers | 234 |
Gatekeeping insecure connections with TLSGatekeeper
Although different tools have been developed to assist system administrators in securing their servers and enforcing specific guidelines, managing clients presents a significantly greater challenge. While configuring a handful of clients is straightforward, doing so at scale within large organizations is a demanding task. Clients are ubiquitous and ephemeral, ranging from workstations to personal smartphones, with a constant influx of new and temporary clients joining the network. Moreover, direct access to these devices can be limited, as personal devices and self-managed workstations are typically outside the IT department’s direct control.
To overcome this challenge, we developed TLSGatekeeper, a network-based tool that provides a flexible and effective way to protect clients from insecure servers. Rather than attempting to individually configure every client, our tool monitors the network for incoming handshakes and verifies server-selected parameters against a chosen security policy. If a server’s parameters violate the chosen policy, TLSGatekeeper can either report the non-compliant outbound connection or outright block it on the spot, potentially preventing an insecure connection from materializing.
Unlike Next-Generation Firewalls (NGFWs), which typically only block legacy TLS versions or a handful of hardcoded ciphers, TLSGatekeeper provides complete flexibility in defining undesired values and directly applying policies established by well-known guidelines. Furthermore, TLSGatekeeper only interacts with handshake packets and never decrypts connections, preserving end-to-end encryption.
Scaling to 100Gbps
Because TLSGatekeeper inspects network traffic in real time, it must process packets at near line-rate without introducing any meaningful latency. To achieve this, we implemented our tool using eXpress Data Path (XDP), attaching it directly to the network interface driver. This architecture allows TLSGatekeeper to rapidly parse target packets with negligible overhead for both TLS and non-TLS traffic.
Our performance evaluation demonstrates that TLSGatekeeper can sustain throughput near 100Gbps while processing thousands of TLS handshakes per second. Specifically, the tool incurs an average inspection delay of only 671ns for TLS 1.3 and 795ns for TLS 1.2 per handshake packet under 100Gbps, confirming that network-wide TLS gatekeeping is feasible at scale.
Where to go from here?
Our work has highlighted a few directions for future work:
- Constant monitoring of TLS deployments: Our dataset provides a comprehensive snapshot of TLS handshake options, but it is limited to the timeframe and location it was collected. We believe that continuous monitoring and reporting of the most common TLS options provides vital visibility into global deployment configurations, making it easier to determine if newly standardized options are actually being followed and the factors driving their adoption.
- Accelerating guideline updates: Cybersecurity agencies must keep pace with emerging developments and standards, providing timely updates when novel technologies are introduced. This is especially critical when adoption is driven by industry giants, as their choices carry broad security implications across the entire Internet.
- Offloading tasks to the network: Technologies like XDP and Programming Protocol-independent Packet Processors (P4) bring programmability directly to the data plane, creating the ideal environment to offload and accelerate networking tasks. As this work demonstrates, isolating and offloading small, targeted tasks can easily be done to yield immediate and significant performance gains.
For a more complete exploration of this research, see our paper.
Henrique Becker Brum is a PhD student at the University of Trento, Italy. His research interests are cybersecurity, computer networks, and programmable data plane tools. His PhD focuses on employing data plane tools to provide efficient and network-wide security for high-speed networks.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.