arXiv CSopen access

Measurement Study of Post-Quantum Readiness of Internet: 2026

arXiv:2606.16473v1 [cs.CR] 15 Jun 2026

Measurement Study of Post-Quantum Readiness of Internet: 2026 Vanishka Mohan Dubey

Gaurav Varshney

Independent Researcher Jammu, India [email protected]

Department of CSE IIT Jammu Jammu, India [email protected]

Abstract—The emergence of quantum computing presents a fundamental challenge to the security of current Internet communication systems. Transport Layer Security (TLS), which forms the backbone of secure web communication, predominantly relies on classical public-key cryptographic algorithms such as RSA and elliptic curve cryptography (ECC), both of which are susceptible to quantum attacks. This paper conducts a large-scale empirical evaluation of post-quantum readiness across 32,011 domains, with a primary focus on real-world TLS deployments across diverse sectors by analyzing negotiated TLS parameters, including protocol versions, cipher suites, key exchange mechanisms, and certificates. The results indicate that while modern protocols like TLS 1.3 and QUIC are gaining adoption, 15.70% of domains especially in critical sectors such as banking and government still rely on TLS 1.2. Furthermore, 49.3% of domains support hybrid post-quantum key exchange mechanisms (e.g., ML-KEM-768 with X25519), whereas 50.7% continue to use classical key exchange, reflecting partial transition. Notably, 0% adoption of hybrid post-quantum certificates was observed, leaving the authentication layer vulnerable to quantum-enabled attacks such as certificate forgery. The findings reveal uneven adoption of post-quantum mechanisms across sectors, where technology-driven platforms are advancing more rapidly than legacy-dependent infrastructures. Overall, the study highlights that achieving complete quantum resilience requires a coordinated transition not only in key exchange mechanisms but also in certificate infrastructures. Without such comprehensive migration, Internet communication systems remain vulnerable to long-term threats, including Harvest-NowDecrypt-Later (HNDL) attacks. Index Terms—Quantum Security, Post-Quantum Cryptography, TLS, Internet Measurement, Hybrid Cryptography, key exchanges,TLS certificates.

I. I NTRODUCTION Transport Layer Security (TLS) is the primary protocol used to secure communication across the modern Internet. It protects sensitive information such as financial transactions, personal data, login credentials, and government records by providing confidentiality, authentication, and integrity [1]. The emergence of quantum computing, however, introduces a longterm challenge to the cryptographic foundations of TLS. Many widely deployed public-key mechanisms, including RSA and Elliptic Curve Cryptography (ECC), derive their security from mathematical problems that are considered computationally infeasible for classical computers [1]. RSA security relies on the hardness of integer factorization, while ECC relies on the elliptic curve discrete logarithm problem. These

assumptions may no longer hold in the presence of largescale quantum computers. In particular, Shor’s algorithm [2], [3] can efficiently solve both integer factorization and discrete logarithm problems in polynomial time, enabling a quantum adversary to recover private keys used in TLS handshakes. In addition, symmetric cryptographic primitives such as AES, used within TLS, may experience reduced security under quantum computation. Grover’s algorithm provides a quadratic speedup for brute-force search, effectively reducing the security strength of symmetric ciphers and hash functions. For example, a symmetric key with 128-bit security provides approximately 64 bits of effective security against a quantum attacker [3]. TLS forms the foundation of secure communication on the Internet and is widely deployed across web applications, cloud platforms, and content delivery infrastructures. As a result, any weakness in its cryptographic design or implementation can have large-scale implications for Internet security. In this context, it becomes essential to evaluate TLS under a quantum threat model. This study aims to identify quantumvulnerable cryptographic primitives, detect the presence of post-quantum or hybrid algorithms, and analyze the real-world deployment of TLS across different sectors. Furthermore, the study evaluates TLS configurations in web servers and Content Delivery Networks (CDNs), which play a critical role in TLS termination, traffic distribution, and security enforcement. The analysis also considers the impact of quantum threats on the fundamental principles of information security, namely confidentiality, integrity, and authenticity (CIA triad), within modern Internet communication systems. This approach enables a focused and comprehensive assessment of TLS-based quantum security readiness across Internet infrastructure, particularly at the web and CDN layers. A. Need of Post-Quantum cryptography Post-quantum cryptography (PQC) refers to cryptographic algorithms designed to protect digital systems against potential attacks from quantum computers. [1], [2], [4] . According to NIST, PQC provides a defense mechanism against future quantum-enabled adversaries by replacing classical publickey cryptographic schemes with quantum-resistant alternatives. Unlike quantum cryptography, PQC can be implemented on existing classical systems without requiring specialized

quantum hardware. NIST has initiated a global standardization effort and released initial PQC standards to support secure communication in the post-quantum era. The transition to PQC is essential as current cryptographic systems are not secure against large-scale quantum attacks, and migration to new standards requires significant time and effort. II. R ELATED W ORK Several prior studies have conducted large-scale measurement analysis of Internet security protocols, particularly focusing on TLS deployments. Holz et al. [5] performed one of the earliest comprehensive analyses of TLS usage on the web, examining certificate validity, cipher suite configurations, and protocol versions across millions of domains. Their study highlighted widespread use of outdated cryptographic mechanisms and misconfigurations in TLS deployments. However, the analysis was limited to classical security considerations and did not evaluate the implications of emerging quantum threats. Durumeric et al. [6] conducted large-scale Internet-wide TLS scanning analyzing certificate chains, protocol versions, and cryptographic configurations. However, their work focuses on classical security properties and does not evaluate quantum vulnerabilities or post-quantum readiness. Benitez [7] presents an engineering inventory of cryptographic dependencies across real-world systems, identifying protocols such as TLS, SSH, IPsec, and DNSSEC that rely on quantum-vulnerable primitives like RSA, ECC, and Diffie–Hellman. The study systematically maps quantum threat vectors, including Harvest-Now-Decrypt-Later (HNDL) and signature forgery, across multiple technology domains and operational environments. However, the work is primarily taxonomy-based and does not include large-scale empirical measurement or real-world Internet scanning of cryptographic deployments. Raavi et al. [8] analyze the security and performance of post-quantum digital signature algorithms (Dilithium, Falcon, and SPHINCS+) and their integration with TLS and PKI, focusing on computational cost and handshake overhead. However, their work is limited to controlled environments and does not consider large-scale Internet measurements or real-world deployment. Alnahawi et al. [1] provide a systematic study of postquantum TLS handshake mechanisms, classifying existing approaches into post-quantum authentication, key exchange, and hybrid models, along with performance evaluations of PQC algorithms. The study highlights that classical TLS primitives such as RSA, ECDSA, and Diffie–Hellman are vulnerable to quantum attacks, enabling decryption of past sessions and signature forgery. However, the work is primarily survey- and evaluation-based and does not include large-scale Internet measurement or real-world deployment analysis. Holz et al. [9] conducted a large-scale measurement study of TLS 1.3 deployment using active scanning across more than 275 million domains and passive monitoring of real-world traffic. Their work analyzes protocol adoption, usage patterns,

and the role of major cloud providers in accelerating TLS 1.3 deployment. However, the study focuses on protocol evolution and deployment trends and does not evaluate quantum security, post-quantum cryptographic mechanisms, or multi-protocol environments. Sowa et al. [11] presented the first large-scale network instrument for monitoring post-quantum cryptography (PQC) adoption across multiple network protocols including SSH, TLS, RDP, and DNS. Their study analyzed real-world traffic at a national-scale supercomputing center using Zeekbased monitoring and identified early adoption of hybrid PQC mechanisms such as sntrup761x25519-sha512 in OpenSSH. The work also highlighted migration challenges, protocol readiness, and the risks of weak cryptographic configurations under emerging quantum threats. However, the study primarily focuses on scientific and HPC environments and does not provide real world sector-wise large-scale Internet analysis across domains such as banking, government, defence, and commercial web infrastructure etc. Shahwar et al. [12] conducted a systematic literature review on quantum cryptography, analyzing 134 studies to identify key challenges, applications, and advancements in QKD and quantum-secured communication. The study highlights the limitations of classical cryptographic schemes against quantum attacks and emphasizes the need for secure future network protocols. However, the work is survey-based and does not include empirical measurement or large-scale analysis of realworld cryptographic deployments. Chhetri et al. [13] present a comprehensive survey of postquantum cryptography, covering major algorithmic families such as lattice-, code-, hash-, multivariate-, and isogeny-based schemes, along with their security assumptions, performance trade-offs, and standardization status. The study also discusses practical aspects including protocol integration (e.g., TLS, DNSSEC), hybrid migration strategies, and deployment challenges across domains such as cloud and IoT. However, the work is survey-oriented and does not perform empirical measurement or large-scale analysis of real-world cryptographic deployments. Chung and Vlajic et al [10] examined the real-world deployment and vulnerabilities of TLS in critical sectors. conducted a comprehensive analysis of TLS security in the world’s 50 largest banking websites using remote scanning techniques. Their findings reveal that less than 50% of the analyzed banks support TLS 1.3, while 94% still rely on TLS 1.2, exposing them to multiple known vulnerabilities. Furthermore, a significant portion of these systems were found to support insecure cryptographic configurations such as CBC-based cipher modes, making them vulnerable to attacks including BEAST, SWEET32, and Lucky13. Notably, approximately 78% of the surveyed banking websites were specifically vulnerable to the Lucky13 attack, highlighting the persistent security risks in real-world TLS deployments.While the study by Chung and Vlajic provides important insights into real-world TLS vulnerabilities in the banking sector, it is limited to classical security analysis and focuses on a relatively small

TABLE I C OMPREHENSIVE C OMPARISON OF E XISTING S TUDIES AND O UR WORK Study

Measurement

Dataset Size

Real-World Analysis

Sector-wise Analysis

Holz et al. [5]

✓

Millions

✓

✗

Durumeric et al. [6]

✓

7.75 Billion Handshakes

✓

Benitez [7]

✗

N/A

Raavi et al. [8]

✗

Alnahawi et al. [1]

Cryptographic Analysis

HNDL Attack Risk Analysis

TLS versions, cipher suites, key exchange mechanisms, certificate chains, cryptographic configurations

Classical TLS security analysis

✗

✗

HTTPS deployment, TLS versions, cipher suite configurations, PKI ecosystem, certificate validation

Classical Internet-scale TLS security

✗

✗

✗

TLS, SSH, IPsec, DNSSEC, certificate algorithms, cryptographic infrastructures, vulnerable asymmetric primitives

Post-Quantum cryptographic risk assessment

✓

Experimental Setup

✗

✗

PQC-enabled TLS, PQC certificates, hybrid PKI architectures, certificate validation mechanisms

PQC integration and security analysis

✓

✗

Experimental Setup

✗

✗

TLS handshake performance, PQC cipher suites, hybrid key exchange, latency and computational overhead

Post-Quantum TLS performance and security analysis

✓

Holz et al. [9]

✓

275 Million Hosts

✓

✗

TLS 1.3 deployment, handshake behavior, cipher suite adoption, protocol transition analysis

Classical TLS deployment security

✗

Chung and Vlajic [10]

✓

50 Banking Domains

✓

Banking Sector

TLS configurations, certificate properties, protocol versions, banking-sector cryptographic deployment

Classical TLS security evaluation

✗

Sowa et al. [11]

✓

13 TB Metadata, 20.5 Million SSH Connections

✓

✗

PQC adoption rates, SSH/TLS cipher suites, OpenSSH PQC deployment, hybrid key exchange mechanisms, cryptographic metadata analysis

Post-Quantum cryptographic deployment and migration analysis

✓

This Study

✓

32,011 Active Internet Domains

✓

✓

TLS versions, cipher suites, key exchange mechanisms, certificate algorithms, cryptographic configurations, PQC readiness, CDN providers, web-server providers, sector-wise adoption trends, security posture evaluation

Classical + Post-Quantum cryptographic analysis

✓

dataset of 50 domains. Their work primarily evaluates protocol weaknesses, legacy cipher usage, and known attacks such as BEAST and Lucky13, without considering emerging quantum threats. While this work provides valuable insights into TLS vulnerabilities and deployment practices in the banking sector, it does not consider emerging quantum threats or the adoption of post-quantum cryptographic mechanisms in modern Internet infrastructure. Nouioua et al. [14] analyze the impact of quantum computing on information security, but do not perform real-world measurement or deployment analysis. Recent works have explored TLS ecosystem evolution, including the adoption of TLS 1.3 and modern cipher suites. However, these analyses still rely on classical threat models and do not assess vulnerabilities arising from quantum computing, particularly in key exchange and certificate algorithms. In parallel, research on post-quantum cryptography has focused on algorithm design and experimental deployment. Google and Cloudflare [15] demonstrated hybrid key exchange mechanisms combining X25519 with post-quantum algorithms such as Kyber. While prior work has demonstrated the feasibility of integrating post-quantum cryptography (PQC) into TLS, it has largely been conducted in controlled environments and lacks large-scale empirical analysis of real-world adoption across diverse sectors. Moreover, despite extensive research on TLS security and PQC, existing studies often overlook quantum threat models in practical Internet deployments, particularly in terms of large-scale evaluation of post-quantum and hybrid cryptographic mechanisms and their adoption across different sectors as shown in Table I. To address this gap, this study presents a comprehensive, sector-wise empirical analysis of Internet security across 32,011 domains spanning critical sectors such as banking, government, defence, and

Parameters

cloud platforms. Specifically, the work conducts a largescale measurement of TLS deployments and examines their cryptographic configurations under a quantum threat model, providing a structured assessment of post-quantum readiness across sectors. A. Contributions This paper presents a comprehensive empirical study of post-quantum cryptographic (PQC) readiness in real-world Internet infrastructure. The key contributions are as follows: • Large-scale Internet measurement under a quantum threat model: We analyze 32,011 domains across multiple critical sectors, including banking, government, defence, and cloud platforms, to evaluate real-world TLS deployments and their exposure to quantum attacks. • Multi-layer TLS measurement and validation framework: We design an automated framework integrating Selenium-based browser inspection, OpenSSL probing, and Wireshark-based packet validation to extract accurate negotiated TLS parameters. • Quantitative evaluation of hybrid post-quantum key exchange adoption: We measure the deployment of hybrid mechanisms (e.g., X25519 + ML-KEM-768) or or post quantum mechanisms. • Identification of a critical gap in certificate-based authentication: We demonstrate that whether analyzed domains use post-quantum or hybrid certificate signature algorithms,. • Sector-wise quantum risk analysis: We provide a detailed sector-wise assessment highlighting uneven PQC adoption, where cloud and technology platforms show higher readiness compared to critical infrastructure sectors such as BFSI, government, and defence.

•

Analysis of TLS negotiation and fallback behavior: We show that client–server negotiation can lead to fallback from PQC-capable configurations to classical cryptography, resulting in inconsistent security guarantees. III. DATA C OLLECTION , M ETHODOLOGY, AND VALIDATION F RAMEWORK

The data collection process was performed using a combination of automated scripting, browser-based analysis, and packet-level validation to ensure accuracy and reliability of the results. The experiments were conducted using Multiple tools and techniques were used to extract and validate TLS and protocollevel security parameters. A. Dataset Collection The dataset of analyzed domains was collected using two primary sources: A total of 31,884 domains were collected from the Tranco domain ranking dataset (https://tranco-list.eu), which provides a stable and research-oriented list of highly visited Internet domains. • A total of 127 domains, including financial institutions, Regional Rural Banks (RRBs), Public Sector Banks, Payment Banks (PBs), Local Area Banks (LABs), Private Sector Banks, Small Finance Banks (SFBs), and foreign banks with a banking presence in India, were collected from the official Reserve Bank of India (RBI) website (https://www.rbi.org.in/scripts/banklinks.aspx), which lists authorized banking institutions operating in India. •

The collected domains were merged to form a broader dataset representing multiple layers of critical Internet infrastructure. B. Sector-wise Distribution of Collected Domains A presentation sample of sector wise distribution of collected domains is shown in Table II. The dataset includes domains from critical sectors such as banking and finance, government services, defense, and energy infrastructure, as well as user-centric platforms including e-commerce, social media, and digital content services. In addition, technology-driven sectors such as cloud computing and IT services were incorporated to reflect modern Internet ecosystems. This diverse sectoral distribution enables a comprehensive analysis of security configurations and cryptographic deployments across heterogeneous environments, ranging from enterprise-grade systems to large-scale public platforms. The inclusion of both traditional infrastructure and emerging digital services ensures that the dataset captures a realistic and holistic view of current Internet security practices across 32,011 actively analyzed domains.

Algorithm 1 Automated Extraction of TLS Versions, Cipher Suites, Key Exchange Mechanisms, HTTP Protocols, Web Servers, and CDN Providers Require: List of target domains X Ensure: Structured protocol and cryptographic analysis dataset 1. Normalize all domains in X 2. Remove duplicate entries for all domain x ∈ X do if x is invalid then Skip domain continue end if if DNS resolution fails then Mark domain as unreachable continue end if 3. Establish TLS connection in Chrome browser Load target website Collect browser network security logs Extract: Negotiated TLS version Cipher suites Key exchange mechanism 5. Retrieve and parse X.509 certificate chain Extract: Subject Public key algorithm Certificate key size Certificate signature algorithm 4. Perform HTTPS header, CDN, Web server provider analysis from the response header in the network logs Extract : HTTP protocol version Detect CDN provider from response headers Web server information Alt-Svc headers if Alt-Svc contains HTTP/3 advertisement then Mark HTTP/3 support as YES else Mark HTTP/3 support as NO end if if Post-quantum or hybrid cryptography is detected then Assign LOW HNDL risk else if Classical cryptography is detected then Assign HIGH HNDL risk else Assign UNKNOWN HNDL risk end if Aggregate all extracted measurements Store results in structured CSV dataset end for return Final analysis dataset

TABLE II E XAMPLE OF S ECTOR - WISE D ISTRIBUTION OF 32,011 D OMAINS Sector

Domains

Example Domains

Banking & Finance (BFSI)

183

sbi.bank.in, hdfc.bank.in, icici.bank.in, axis.bank.in, kotak.bank.in, unionbankofindia.bank.in, yes.bank.in, rbl.bank.in, idfcfirst.bank.in, pnb.bank.in, jkb.bank.in, citi.com, hsbc.bank.in, airtelpayments.bank.in, paytm.bank.in tbank.ru, sberbank.ru, citizensbank.com, otpbank.ru, halykbank.kz, akbank.com, pochtabank.ru, akbank.com, bankofscotland.co.uk, hellobank.fr, kiwibank.co.nz,sbishinseibank.co.jp,apobank.de, primbank.ru, rabobank.com.au,bankofireland.com, alfabank.ru, southstatebank.com, reisebank.de, bankofcyprus.com, bcs-bank.ru, landbank.com, axosbank.com,privatbankar.hu, bankofamerica.com etc

Government & Public Services

921

india.gov.in, passportindia.gov.in, pmindia.gov.in, mha.gov.in, mea.gov.in, pib.gov.in, gst.gov.in etc

Defence & Military

328

drdo.gov.in, mod.gov.in, joinindianarmy.nic.in, nsg.gov.in, crpf.gov.in etc

IT & Software / Technology Platforms

241

tcs.com, infosys.com, wipro.com, microsoft.com, oracle.com, ibm.com, zoho.com, browserstack.com etc

Cloud / Hosting / Security

468

aws.amazon.com, cloudflare.com, akamai.com, digitalocean.com etc

Education & EdTech

727

iitd.ac.in, iitb.ac.in, iitk.ac.in, vit.ac.in, jnu.ac.in, du.ac.in, bits-pilani.ac.in, byjus.com, unacademy.com, physicswallah.live etc

E-commerce & Retail

351

flipkart.com, ajio.com, meesho.com, nykaa.com, bigbasket.com, pepperfry.com, lenskart.com etc

Logistics & Travel

94

delhivery.com, dtdc.in, xpressbees.com, ecomexpress.in, shadowfax.in, porter.in, shiprocket.in, irctc.co.in, makemytrip.com etc

FinTech & Payments

128

razorpay.com, phonepe.com, paytm.com, bharatpe.com, cashfree.cometc

Insurance & Financial Services Healthcare & Pharma

112 385

Media & Digital Content

722

hdfclife.com, starhealth.in, policybazaar.com, bajajallianz.com etc apollohospitals.com, practo.com, pharmeasy.in, cipla.com, sunpharma.com, drreddys.com, pfizerindia.com etc ndtv.com, thehindu.com, timesofindia.indiatimes.com, news18.com, aajtak.in, hotstar.com, netflix.com etc

Social Media Platforms

42

facebook.com, instagram.com, x.com, linkedin.com, reddit.com, discord.com, snapchat.com, threads.com etc

Search Engines

18

google.com, bing.com, yahoo.com, duckduckgo.com, yandex.com etc

Telecom & Networking

36

airtel.in, jio.com, bsnl.co.in, ericsson.com etc

Energy & Critical Infrastructure

61

ntpc.co.in, iocl.com, adanipower.com, npcil.nic.in etc

Legal / Advisory / Enterprise Services

76

pwc.in, deloitte.com, kpmg.com, trilegal.com etc

Others (Misc)

27118

github.com, stackoverflow.com, medium.com, quora.com etc

C. Automated TLS Parameter and Certificate Extraction using python Custom Python scripts (depicted in the Algorithm 1) were developed to perform large-scale scanning and data extraction across thousands of domains. The implementation utilized multiple libraries and tools, including: Selenium WebDriver for browser-based TLS inspection OpenSSL for handshake-level cryptographic analysis • cURL for HTTP protocol and CDN detection • socket, subprocess, threading for network communication and parallel execution • •

The browser-based component was implemented using Selenium WebDriver with the Chrome DevTools Protocol (CDP). Each domain was accessed using the HTTPS scheme in order

niti.gov.in,

upsc.gov.in,

drdo.gov.in,

to enforce secure communication and initiate a TLS handshake under realistic browser conditions. Chrome performance logs were enabled and collected for every visited domain. From these logs, only Network.responseReceived events were processed. Each response was filtered to ensure that only URLs belonging to the target domain or its subdomains were considered. For each valid network response, the securityDetails field was extracted. This field provides TLS-specific metadata such as the negotiated TLS protocol version, cipher suite, key exchange method, key exchange group and HTTP protocol. To avoid failed scan, before scanning each domain, the browser was reset to a blank page, old performance logs were cleared, Chrome cache was disabled through CDP, and service worker bypass was enabled. This ensured that the collected

TLS parameters reflected fresh network communication rather than cached browser responses. For deeper cryptographic analysis, an OpenSSL-based probing module was implemented. The script used openssl s_client to establish TLS connections with each target server on port 443 using Server Name Indication (SNI). The handshake output was parsed to extract the negotiated TLS version, cipher suite, key exchange mechanism, and handshake signature algorithm. Certificate details were extracted using openssl x509 for detailed parsing. The parsed certificate output was used to extract the certificate signature algorithm. The socket library was used before TLS probing to verify whether a domain resolves successfully. The function socket.getaddrinfo() was used with port 443 and stream socket type. If DNS resolution failed, the domain was skipped. This step prevented unnecessary TLS and HTTP probing against invalid or unreachable domains. The subprocess library was used to execute external tools such as OpenSSL and cURL from within Python. A wrapper function was implemented around subprocess.run() to capture standard output and standard error, enforce execution timeouts, and return structured status information. Timeout handling was included to prevent the scanner from blocking indefinitely on slow or unresponsive domains. A retry mechanism was also implemented so that timed-out commands could be attempted again before being marked as failed. The cURL component was used for HTTP-layer and infrastructure analysis. For each domain, cURL was invoked over HTTPS with header-only mode, redirection support, connection timeout, maximum execution time, and custom output formatting. The final response headers were parsed after following redirects. From these headers, the script extracted the Alt-Svc header, server header, HTTP protocol version, and CDN-related indicators. HTTP/3 support was inferred by checking whether the Alt-Svc header contained an h3 advertisement. If such an entry was present, the domain was marked as supporting HTTP/3/QUIC. Otherwise, the HTTP version reported by cURL or the final HTTP status line was mapped to HTTP/1.0, HTTP/1.1, HTTP/2, or HTTP/3. CDN detection was performed using heuristic matching of known response header patterns associated with providers such as Cloudflare, Akamai, Fastly, AWS CloudFront, Google Cloud CDN, Azure CDN, Imperva, and Sucuri. To support large-scale scanning, the framework used multithreading through Python’s ThreadPoolExecutor. Each domain was submitted as an independent scanning task, allowing multiple TLS and HTTP probes to run concurrently. The maximum number of parallel workers was configured as 50. Since multiple threads write results to the same CSV file, a threading.Lock() object was used to ensure threadsafe file writing. This prevented concurrent write conflicts and preserved the integrity of the output dataset. The complete scanning pipeline follows the sequence: domain normalization, domain validation, DNS resolution,

OpenSSL TLS probing, certificate extraction, cURL-based HTTP and CDN analysis, risk assessment, and CSV storage. Each scanned domain produces a structured row containing the domain name, scan status, TLS version, cipher suite, key exchange mechanism, handshake signature algorithm, certificate signature algorithm, subject public key algorithm, certificate key size, HTTP/3 support, Alt-Svc value, web server, and CDN provider. It is important to note that the extracted TLS parameters represent negotiated values. These values are not solely determined by the server. During the TLS handshake, the client advertises supported cipher suites and key exchange groups, and the server selects one mutually compatible configuration. Therefore, the observed cipher suite and key exchange mechanism depend on both client-side configuration, including browser, operating system, and cryptographic libraries, and server-side TLS policy. By combining Selenium-based browser measurement with OpenSSL and cURL-based active probing, the methodology captures both realistic user-facing TLS behavior and additional cryptographic deployment characteristics required for largescale security analysis. 1) Validation using Wireshark: To ensure correctness of the extracted data, packet-level validation was performed using Wireshark. TLS handshakes were captured and analyzed to verify: • ClientHello and ServerHello messages • Negotiated cipher suites • Supported cipher suites • Key exchange groups • TLS version agreement This validation step ensured that the values extracted through automated scripts accurately matched the actual network-level communication. 2) Verification using Google Chrome Browser Developer Tools: In addition to automated and packet-level analysis, manual verification was performed using Chrome Developer Tools. The security panel was used to inspect: • TLS version and connection security • Negotiated cipher suites • Certificate details and key sizes This helped confirm that the extracted results were consistent with real-world browser behavior and security indicators. IV. R ESULTS AND A NALYSIS This section presents the observed deployment patterns and security posture across the analyzed protocols. A. Quantum Analysis of Protocol Distribution Across Collected Domains The analysis of collected domains reveals that multiple secure communication protocols are actively deployed across the Internet. TLS 1.3 emerges as the most dominant protocol, observed in 16,779 domains, indicating widespread adoption of modern and security-hardened cryptographic standards. In

TABLE III P ERCENTAGE D ISTRIBUTION OF TLS AND QUIC (HTTP/3) P ROTOCOLS Protocol TLS TLS QUIC

Version TLSv1.3 TLSv1.2 TLSv1.3 (HTTP/3)

Percentage (%) 52.41% 15.70% 31.89%

contrast, TLS 1.2 is still present in 5,024 domains, primarily associated with legacy systems and backward compatibility requirements. Additionally, QUIC, implemented via HTTP/3, is observed in 10,208 domains. Since HTTP/3 operates over QUIC and integrates TLS 1.3 directly within its transport layer, all HTTP/3-enabled services were classified under QUICbased communication in this study. TLS 1.3 introduces several architectural improvements over earlier protocol versions, including the removal of outdated cryptographic options, simplification of the handshake process, and enforcement of ephemeral key exchange mechanisms, thereby enhancing forward secrecy and resistance against classical network attacks [16]. However, despite these advancements, upgrading to TLS 1.3 does not fully address longterm quantum security concerns. Both TLS 1.2 and TLS 1.3 if continue to rely on conventional public-key cryptographic algorithms for certificate authentication and key establishment, then it is computationally vulnerable to quantum algorithms such as Shor’s algorithm, capable of breaking RSA and elliptic curve cryptography [2]. 1) TLS 1.2 vs TLS 1.3 Limitations of TLS 1.2 for QUIC protocol and Post-Quantum Cryptography : TLS 1.2, defined in RFC 5246, was designed for classical cryptographic environments and supports mechanisms such as RSA and Diffie– Hellman (DH), for key exchange, along with RSA or ECDSA for authentication [17]. In practice, legacy configurations such as RSA-based key exchange are still observed, which lack forward secrecy and are vulnerable to quantum attacks. TLS 1.3 introduces a simplified and more secure design by enforcing ephemeral key exchange (e.g., X25519, secp256r1), ensuring forward secrecy by default [16]. It removes legacy algorithms such as static RSA and CBC-based cipher suites, and supports only authenticated encryption schemes like AESGCM and ChaCha20-Poly1305. Additionally, TLS 1.3 reduces handshake latency from 2-RTT (in TLS 1.2) to 1-RTT, significantly improving performance. At the transport layer, both TLS 1.2 and TLS 1.3 are traditionally deployed over TCP, which introduces connection setup delays and suffers from head-of-line (HOL) blocking. QUIC, used in HTTP/3, addresses these limitations by operating over UDP and integrating TLS 1.3 directly into its transport layer [18]–[20]. This enables faster connection establishment, eliminates HOL blocking through independent streams, and improves both performance and privacy. Due to these architectural requirements, TLS 1.2 is not supported in QUIC. Despite these improvements, TLS 1.2 remains fundamentally incompatible with post-quantum cryptographic integra-

tion. It relies on classical key agreement mechanisms tightly coupled within cipher suites, limiting extensibility. In contrast, post-quantum algorithms such as ML-KEM (Kyber) follow a Key Encapsulation Mechanism (KEM) paradigm and introduce significantly larger key sizes. For example, Kyber-based hybrid key shares (832–1,216 bytes) are substantially larger than classical schemes such as X25519 (32 bytes), leading to potential packet fragmentation and increased transmission overhead. Furthermore, the rigid handshake structure and higher latency (2-RTT) of TLS 1.2 make it unsuitable for hybrid post-quantum key exchange integration. In contrast, TLS 1.3 introduces a flexible handshake using the key_share extension, enabling support for hybrid mechanisms such as X25519 combined with ML-KEM [16]. As a result, TLS 1.3 provides the necessary architectural foundation for postquantum cryptography. Recent deployments have begun adopting hybrid postquantum key exchange mechanisms to ensure security against both classical and quantum adversaries [21], [22]. QUIC further facilitates this transition due to its flexible design and faster handshake capabilities, allowing easier integration of evolving cryptographic primitives. However, a significant portion of Internet infrastructure still relies on legacy protocols such as TLS 1.2, highlighting a gap between protocol evolution and real-world deployment. Achieving full quantum resilience will therefore require a gradual but complete transition toward TLS 1.3 and QUICbased architectures with native support for post-quantum cryptography. 2) Device-wise TLS Configuration Analysis Using Chrome Developer Tools: To validate protocol deployment one observation was observed at the client level, the security parameters of selected domains was analyzed using Chrome Developer Tools (Security tab) across multiple devices. Device 1 Observation: Figure 1 illustrates the connection to the banking website (icici.bank.in) was established using QUIC, with modern cryptographic parameters including X25519 for key exchange and AES-256-GCM as the cipher. This configuration reflects a secure and optimized connection leveraging QUIC with integrated TLS 1.3 [19].

Fig. 1. Device 1: QUIC with TLS 1.3 and modern cipher suite observed using Chrome Developer Tools

Device 2 Observation: On a different device, the same domain (icici.bank.in) was observed to use TLS 1.2, with

ECDHE-RSA as the key exchange mechanism and AES-128GCM as the cipher suite. Despite supporting secure communication, this configuration represents a fallback to an earlier TLS version [17].

Fig. 2. Device 2: TLS 1.2 fallback with legacy-compatible cipher suite observed using Chrome Developer Tools

Figure 2 shows the variation in TLS versions across devices indicates that protocol negotiation is influenced by clientside factors such as browser version, operating system, and supported cryptographic capabilities. During the handshake process, the server selects the highest mutually supported protocol version between client and server [16]. This demonstrates that even when servers support modern protocols such as QUIC and TLS 1.3, clients may still operate over TLS 1.2 due to compatibility constraints. This highlights the coexistence of modern and legacy protocol deployments in real-world environments. Although both devices ensure secure communication in practice, TLS 1.3 provides a higher level of security due to enforced modern cryptographic standards, simplified handshake, and resistance to downgrade attacks. Therefore, Device 1 is more secure compared to Device 2. From a quantum security perspective, this variation introduces a critical concern. Even when servers support advanced protocols, client-side limitations may force fallback to TLS 1.2, which relies on classical cryptographic algorithms. These algorithms, including the RSA and elliptic curve cryptography used in ECDHE, are computationally vulnerable to quantum attacks such as the Shor algorithm [2]. This inconsistency implies that achieving quantum resilience is not solely dependent on server-side upgrades, but also requires client-side modernization and widespread adoption of post-quantum cryptographic mechanisms. [23]–[26] Without such end-to-end upgrades, communication systems remain exposed to long-term threats such as Harvest-NowDecrypt-Later (HNDL) attacks, where encrypted data intercepted today may be decrypted in the future using quantum computing capabilities [21]. B. Sector-wise TLS Version Distribution and Quantum Vulnerability Analysis Figure 3 reveals that although TLS 1.3 adoption is dominant across most sectors, a proportion of web servers still operate using TLS 1.2, particularly in critical sectors such as Banking, Government, Defence, Telecom, and Energy. The continued presence of TLS 1.2 in these sectors can be attributed to practical constraints including legacy infras-

tructure, compatibility requirements, regulatory dependencies, and the high cost of upgrading production environments. Many financial and government systems prioritize stability and compliance over rapid technological transition, resulting in gradual migration toward TLS 1.3 rather than immediate replacement. NIST also emphasizes that migration to TLS 1.3 provides significant security improvements and helps mitigate vulnerabilities associated with TLS 1.2 [27]–[29]. From a security perspective, TLS 1.2 supports a wider range of cryptographic mechanisms, including RSA-based key exchange and older Diffie–Hellman configurations, which increase exposure to weak key exchange and downgrade scenarios [17], [30], [31]. These weaknesses have been exploited in several well-documented attacks such as BEAST, POODLE, Lucky13, and Logjam, which target legacy cipher modes, downgrade mechanisms, and lack of forward secrecy [30], [32]–[34]. TLS 1.3 was specifically designed to eliminate these vulnerabilities. As a result, no widely exploited practical attacks comparable to TLS 1.2 vulnerabilities have been observed against TLS 1.3 in real-world deployments [16], [35]. Despite these improvements, both TLS 1.2 and TLS 1.3 remain dependent on classical public-key cryptographic algorithms for authentication, which are vulnerable to quantum attacks. Shor’s algorithm can efficiently break these cryptographic assumptions, enabling future adversaries to decrypt captured encrypted traffic under the Harvest-Now-DecryptLater (HNDL) model [2], [4]. The risk is particularly critical in high-value sectors. ENISA reports that public administration accounted for 19% of observed incidents, while the financial sector represented 8% in recent threat landscape analyses [36], [37]. Additionally, 488 publicly reported incidents were recorded in the financial sector between 2023 and 2024, including multiple large-scale DDoS attacks [38]. In the public administration sector, data breaches accounted for 17.4% of incidents, highlighting the impact of confidentiality failures [39]. In practical terms, compromise of TLS-protected communication in these sectors could expose credentials, financial transactions, operational data, and citizen records, leading to fraud, service disruption, identity theft, and loss of trust. The combination of high attack frequency and continued reliance on classical cryptography significantly increases long-term risk. Overall, while TLS 1.3 improves security and reduces classical attack surfaces, it does not inherently provide quantum resistance. Achieving true quantum resilience requires the integration of post-quantum or hybrid cryptographic mechanisms across both server and client ecosystems. Without such coordinated adoption, critical infrastructure remains exposed to both present-day threats and future quantum-enabled attacks. C. Quantum Security Analysis of Cipher Suites and key exchanges Transport Layer Security establishes secure communication through a handshake process that negotiates cryptographic

Fig. 3. Sector-wise TLS 1.2 and TLS 1.3 Distribution of collected domains

parameters between the client and the server. During the TLS handshake, the client first sends a ClientHello message containing supported protocol versions and cipher suites. The server then responds with a ServerHello message selecting a specific cipher suite. The server subsequently provides its digital certificate for authentication, which is typically based on RSA or ECDSA public-key cryptography. [40]

through the use of authenticated encryption algorithms such as AES-GCM and ChaCha20, along with forward secrecy mechanisms like ECDHE. However, despite strong symmetric encryption, all cipher suites rely on classical public-key cryptographic mechanisms for key exchange and authentication. These include RSA and elliptic-curve-based algorithms, which are vulnerable to quantum attacks [2].

After authentication, a key exchange mechanism such as Elliptic Curve Diffie–Hellman Ephemeral (ECDHE) or Diffie– Hellman Ephemeral (DHE) is used to establish a shared secret between the client and the server. This shared secret is then processed through a key derivation function to generate symmetric session keys. Once these keys are derived, all subsequent communication is encrypted using symmetric encryption algorithms such as AES-GCM or ChaCha20-Poly1305.

As a result, while the majority of cipher suites are classified as strong in the classical security model, they are not secure in the presence of quantum adversaries. Weak classifications within the classical model are primarily associated with legacy constructions such as CBC-mode encryption and SHA-1-based authentication. This analysis demonstrates that current TLS deployments achieve high levels of security against presentday threats but lack long-term resilience, reinforcing the need for post-quantum cryptographic cipher suites integration. It is important to note that the observed cipher suites are not inherently insecure. They provide strong security against classical adversaries through authenticated encryption and forward

1) TLS Cipher Suite Security Classification : The classification of TLS cipher suites (Table IV) highlights a clear distinction between classical and quantum security properties. Most observed cipher suites provide strong classical security

TABLE IV Q UANTUM S ECURITY A NALYSIS OF O BSERVED TLS C IPHER S UITES Cipher Suite

Domains

Enc.

Quantum Impact

TLS AES 256 GCM SHA384

19837

AES-256

Grover: bit

TLS AES 128 GCM SHA256

6319

AES-128

Grover: 64-bit

TLS CHACHA20 POLY1305 SHA256

127

ChaCha20 Grover: bit

ECDHE-RSA-AES128-GCM-SHA256

2305

ECDHE-RSA-AES256-GCM-SHA384

TABLE V P ERCENTAGE D ISTRIBUTION OF K EY E XCHANGE G ROUPS WITH Q UANTUM S ECURITY I MPACT Percentage (%) 0.09%

Quantum Impact Vulnerable

prime256v1 (P-256)

10.33%

Vulnerable

128-

secp384r1

1.40%

Vulnerable

AES-128

Shor break; Grover: 64-bit

secp521r1

0.71%

Vulnerable

2031

AES-256

Shor break; Grover: 128bit

X25519

38.15%

Vulnerable

ECDHE-ECDSA-AES128-GCM-SHA256

133

AES-128

Shor break; Grover: 64-bit

X25519MLKEM768

49.30%

Hybrid (Quantum Resistant)

ECDHE-ECDSA-AES256-GCM-SHA384

174

AES-256

Shor break; Grover: 128bit

X448

0.01%

Vulnerable

ECDHE-ECDSA-CHACHA20-POLY1305

482

ChaCha20 Shor break; Grover: 128bit

ECDHE-RSA-AES256-SHA

17

128-

AES-256

Shor break Shor break

ECDHE-RSA-AES256-SHA384

60

AES-256

ECDHE-RSA-CHACHA20-POLY1305

311

ChaCha20 Shor break

DHE-RSA-AES128-GCM-SHA256

3

AES-128

Shor break; Grover: 64-bit

DHE-RSA-AES256-GCM-SHA384

12

AES-256

Shor break; Grover: 128bit

AES 256 CBC SHA1

1

AES-256

Weak classical; Grover:128 bit

secrecy. However, they are not resistant to quantum attacks due to their reliance on classical public-key cryptographic mechanisms. 2) TLS Key Exchange Security Classification : The study shows that nearly half of the observed key exchange mechanisms (49.3%) demonstrate quantum-resistant properties through hybrid post-quantum cryptography, while a slightly larger portion (50.7%) remains vulnerable to quantum attacks. This table V highlights that the current Internet ecosystem is in a transitional phase towards quantum security. Hybrid key exchange mechanisms offer a robust and practical approach for mitigating emerging quantum threats; however, they cannot be considered absolutely secure or entirely quantum-proof. In cryptographic systems, absolute security is unattainable due to the continuous evolution of attack methodologies and potential implementation weaknesses. Hybrid key exchange integrates classical cryptographic techniques, such as Elliptic Curve Diffie–Hellman (ECDH), with post-quantum cryptographic (PQC) algorithms [22], [41], such as ML-KEM (Kyber), thereby establishing a dual-layered security framework. This design ensures that even if quantum adversaries compromise the classical component, the PQC component preserves the confidentiality of the communication.

Key Exchange RSA

Despite its advantages, hybrid cryptography presents several limitations. Firstly, PQC algorithms are relatively recent and lack the extensive real-world validation that classical algorithms have undergone, leaving room for potential undiscovered cryptanalytic vulnerabilities [41]. Secondly, the increased complexity of hybrid implementations may introduce software defects and expose systems to side-channel attacks, resulting in unintended information leakage [40]. Thirdly, the “harvest now, decrypt later” threat model remains a concern, wherein adversaries may store encrypted data today and decrypt it in the future as more advanced computational capabilities emerge [2]. Additionally, downgrade attacks may coerce systems into reverting to classical-only cryptographic modes, thereby undermining the intended quantum resistance [16]. Consequently, while hybrid key exchange mechanisms do not provide absolute quantum security, they represent a significant advancement toward quantum-resilient communication by combining classical and post-quantum cryptographic primitives, ensuring robustness even if one component is compromised [22], [41]. 3) Packet-Level Validation Using Wireshark: Packet-level inspection of domain: www.google.com using Wireshark reveals the detailed behavior of the TLS 1.3 handshake process. During the Client Hello phase (Fig: 4), the client advertises a list of supported cipher suites and cryptographic groups (supported groups extension). These include classical ellipticcurve groups such as X25519 and secp256r1, along with hybrid post-quantum groups such as X25519MLKEM768. The Server Hello message in Fig. 5 indicates the final selection of the cipher suite and key exchange group based on the intersection of client-supported and server-supported configurations. In the observed capture, the negotiated cipher suite is TLS AES 128 GCM SHA256, and the selected key exchange group is X25519MLKEM768. 4) Quantum Security Analysis of Certificate Algorithms: The digital certificates of the target domains were analyzed to extract cryptographic properties, specifically the certificate

Fig. 4. TLS 1.3 Client Hello observed (www.google.com) in Wireshark showing supported cipher suites and supported key exchange groups

Fig. 5. TLS 1.3 Server Hello observed (www.google.com) in Wireshark indicating Negotiated cipher suite TLS AES 128 GCM SHA256 and Negotiated Key Exchange

Fig. 6. Supported TLS Signature Algorithms Observed domain: www.google.com in Wireshark Capture

TABLE VI D ISTRIBUTION OF C ERTIFICATE S IGNATURE A LGORITHMS WITH Q UANTUM S ECURITY I MPACT Signature Algorithm

Percentage Quantum Security Status

PKCS #1 SHA-256 with RSA

54.05%

Not Quantum-Safe

PKCS #1 SHA-512 with RSA

2.85%

Not Quantum-Safe

X9.62 ECDSA with SHA-256

42.32%

Not Quantum-Safe

X9.62 ECDSA with SHA-384

0.68%

Not Quantum-Safe

X9.62 ECDSA with SHA-512

0.11%

Not Quantum-Safe

signature algorithm and the public key size. The signature algorithm in Table VI was identified from the X.509 certificate field signatureAlgorithm, which specifies the cryptographic algorithm used by the Certificate Authority (CA) to sign the certificate. Commonly observed algorithms include PKCS #1 RSA with SHA-256 and ECDSA with SHA256/384/512 [42]. These algorithms reflect the integrity and authenticity mechanism of the certificate. The key size was observed from the Subject Public Key Info field of the certificate, which contains the public key and its associated parameters. For RSA-based certificates, key sizes such as 2048-bit, 3072-bit, and 4096-bit were observed, whereas elliptic curve certificates typically used 256-bit and 384-bit keys [16]. Therefore, RSA and ECDSA-based certificate algorithms are not quantum-safe due to their reliance on problems vulnerable to Shor’s algorithm [2]. Larger key sizes improve classical security but do not ensure quantum resistance and also no post-quantum algorithms were observed in the dataset [41]. 5) TLS Handshake Signature Algorithm Analysis using Wireshark: The TLS handshake was analyzed using Wireshark to observe the supported signature algorithms advertised by the client in the signature algorithms extension. The captured data includes multiple RSA and ECDSA-based algorithms such as rsa pkcs1 sha256, rsa pss rsae sha256, and ecdsa secp256r1 sha256. These algorithms represent the set of cryptographic options that can be used during certificate verification in the TLS handshake process. From a quantum security perspective, all observed algorithms are based on RSA and elliptic curve cryptography, which are vulnerable to Shor’s algorithm [2]. Therefore, despite being secure in classical environments, these algorithms are classified as not quantum-safe. The absence of postquantum signature schemes in the TLS handshake highlights the current gap in quantum-resistant deployment in real-world Internet communication. D. Infrastructure Security Components Content delivery networks (CDNs), web application firewalls (WAFs), and managed hosting infrastructures are widely used to improve web security and classical resilience. These technologies help protect services through reverse proxying, traffic filtering, geographic distribution, DDoS mitigation, and application-layer inspection [43], [44].

TABLE VII I NFRASTRUCTURE S ECURITY D EPLOYMENT Component CDN Web Server WAF

Observed Providers Cloudflare, AWS CloudFront, Google Global Edge, Akamai, Fastly Apache, Nginx, Cloudflare, Hidden / Obfuscated Cloudflare WAF, Akamai WAF, Imperva WAF, Sucuri WAF

Their presence is an important part of modern Internet defense architecture. However, these components do not directly address the cryptographic challenges introduced by future quantum computing. They primarily enhance availability and operational security, whereas the long-term confidentiality and authenticity of TLS communications depend on the underlying cryptographic algorithms deployed within the protocol itself [2], [16], [41]. E. CDN, Webserver Infrastructure and Quantum Security Status The distribution of CDN providers across the analyzed domains is summarized in Table VIII. The analysis of CDN providers VIII reveals varying levels of post-quantum cryptographic (PQC) readiness. Major providers such as Cloudflare and AWS CloudFront have already deployed hybrid post-quantum key exchange mechanisms (x25519 with ML-KEM/Kyber), indicating strong readiness for future quantum threats [24], [45]. however, Cloudflare implements hybrid post-quantum key exchange mechanisms in default mode to strengthen TLS security against future quantum threats. however, hybrid mechanism X25519+MLKEM-768 is widely adopted in default mode across major browsers, including Chrome 131+, Firefox 132+ (desktop) and 145+ (Android), Safari 26+, Edge 131+, as well as Opera, Brave, and Tor Browser 15.0+. It is also supported systemwide in modern Apple operating systems such as iOS 26 and macOS Tahoe 26. In addition to browsers, this hybrid approach is integrated into modern cryptographic libraries and tools, including Go 1.24+, OpenSSL 3.5.0+, Node.js (v24.5.0+ and v22.20.0+), BoringSSL, GnuTLS (with leancrypto or liboqs), rustls 0.23.22+, and Botan 3.7.0+. It is also supported in server and networking software such as NGINX (compiled with OpenSSL 3.5+), Caddy 2.10.0+, Traefik, rpxy 0.9.4+, and implementations from Open Quantum Safe (liboqs and oqs-provider) [25]. Additionally, support is available in Zig 0.14.0+ and Cloudflare’s Go fork. Google Cloud CDN also demonstrates hybrid PQC adoption in controlled or internal key exchange environments [46]. In contrast, providers such as Akamai have also introduced hybrid post-quantum key exchange mechanisms (e.g., X25519MLKEM768) within TLS 1.3 at the edge, enabling optional PQC support for client connections [47]. This reflects an active transition phase, where NIST-standardized PQC mechanisms are being gradually integrated into production en-

TABLE VIII CDN P ROVIDERS WITH PQC READINESS S TATUS Provider Cloudflare AWS CloudFront Google Cloud CDN / GFE Akamai Fastly Azure CDN Imperva Sucuri Hidden / Not Detected

Percentage (%)

Key Exchange

37.97 7.71 1.76 2.39 3.17 0.79 0.67 0.16 45.37

ML-KEM Hybrid (Kyber) ML-KEM & ML-DSA ML-KEM & ML-DSA ML-KEM ML-KEM(Kyber) in TLS 1.3 Depends on Partner CDN Hybrid PQC (X25519MLKEM768) (No Direct PQC Yet found,TLS 1.3) Unknown

vironments, although full-scale deployment is still ongoing [4], [41], [47]. Similarly, Fastly has begun integrating x25519ML-KEM768 into TLS 1.3 handshakes, indicating a transition toward quantum-resistant infrastructure [48]. Imperva also demonstrates partial PQC readiness through hybrid TLS key exchange (X25519+ML-KEM-768), ensuring backward compatibility while enabling quantum-resistant connections when supported by clients [49]. Sucuri actively monitors developments in post-quantum cryptography (PQC) and relies on modern, industry-standard TLS configurations and infrastructure practices through its security stack and upstream providers. While large-scale migration to PQC is still evolving across the industry, Sucuri emphasizes protecting customer traffic and maintaining alignment with current cryptographic best practices as part of its long-term security roadmap. [50]. A significant portion of domains rely on hidden or unidentified CDN configurations, making their quantum readiness difficult to assess. Overall, these observations highlight that while leading CDN providers are actively progressing toward quantum-safe infrastructure, widespread adoption across the Internet remains incomplete and uneven [4], [41]. Table IX shows that a significant portion of the observed infrastructure is either hidden or served through CDN and proxy layers, indicating that modern web architectures increasingly obscure origin server details for security and performance optimization. NGINX does not natively implement post-quantum cryptography; instead, hybrid PQC support is enabled through underlying cryptographic libraries such as OpenSSL (version ≥ 3.5) or the Open Quantum Safe (OQS) provider, highlighting that PQC adoption in web servers is largely dependent on external TLS implementations rather than the server software itself [51]. Microsoft has introduced post-quantum cryptographic (PQC) support in Windows Server 2025, Windows 11, and .NET 10 through the integration of NIST-standardized algorithms such as ML-KEM and ML-DSA. These algorithms enable quantum-resistant key exchange and digital signatures, respectively, and are designed to mitigate emerging threats such as ”harvest now, decrypt later.” However, current deployment follows a hybrid approach, combining classical and post-quantum mechanisms to ensure backward compatibility and gradual ecosystem transition [52].

F. Sector-wise Quantum Risk Heatmap The quantum risk heatmap X highlights significant disparities in post-quantum readiness across different sectors. Technology-driven sectors such as Cloud/CDN, Social Media, and Search Engines demonstrate low quantum risk due to the adoption of hybrid post-quantum key exchange mechanisms (e.g., ML-KEM combined with X25519). These sectors are leading the transition toward quantum-resilient communication. In contrast, sectors such as BFSI, Government, Defence, and Telecom exhibit high quantum risk due to continued reliance on classical public-key cryptographic algorithms such as RSA and ECDSA. These algorithms are vulnerable to future quantum attacks, particularly under the harvest-now-decryptlater (HNDL) threat model. Enterprise and security-related services show a mixed trend, with modern transport protocols but limited adoption of post-quantum cryptography, indicating transitional deployment phases. Overall, the heatmap reveals that quantum readiness is not uniform and is strongly influenced by sector-specific priorities, with performance-driven platforms leading adoption and critical infrastructure lagging behind. V. D ISCUSSIONS AND C ONCLUSIONS One of the key quantitative findings of this study is that 50.7% of the analyzed domains remain fully vulnerable to quantum attacks due to their continued reliance on classical cryptographic mechanisms, while 49.3% demonstrate partial post-quantum readiness through the deployment of hybrid key exchange mechanisms. These results indicate that the Internet ecosystem is currently in a transitional phase of postquantum cryptographic (PQC) adoption. A major driver of this transition is the growing deployment of ML-KEM-768 (Kyber768), standardized by NIST under FIPS 203. Its favorable balance between security and performance, combined with integration into modern TLS implementations, browsers, cloud platforms, and content delivery networks, has enabled practical Internet-scale deployment. Previous studies and large-scale deployments by providers such as Google and Cloudflare [25], [53] have further demonstrated that hybrid key exchange schemes based on X25519 and ML-KEM-768 introduce minimal performance overhead while providing protection against both classical and quantum adversaries. Despite the availability of standardized PQC algorithms, including ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205), large-scale deployment remains incomplete. The primary barriers are no longer the absence of suitable cryptographic standards but the operational and compatibility challenges associated with migration. Many Internetfacing systems continue to rely on legacy hardware, software, and security appliances that require extensive testing, validation, and interoperability assessment before cryptographic upgrades can be deployed. In addition, PQC adoption is closely tied to support within cryptographic libraries, operating systems, browsers, and application frameworks, causing

TABLE IX P ERCENTAGE D ISTRIBUTION OF O BSERVED W EB S ERVER I NFRASTRUCTURE WITH Q UANTUM R EADINESS Category Web Server Web Server Web Server Web Server CDN / Edge CDN / Edge Proxy / Load Balancer Hidden / Unknown

Technology Apache (all variants) Nginx (all variants) Microsoft IIS LiteSpeed, Caddy, Kestrel, Gunicorn Cloudflare CloudFront, Akamai, GFE, Amazon S3 ELB, Envoy, HAProxy Masked or Not Identified

Percentage (%) 16.25% 19.37% 1.09% 1.16% 35.93% 4.69% 1.59% 35.56%

TABLE X S ECTOR - WISE Q UANTUM R ISK H EATMAP Sector BFSI Government Defence IT/Tech Cloud/CDN Social Media E-commerce Enterprise (Microsoft) Security Vendors Media Search Engines Telecom Energy Legal/Advisory

PQC Adoption Low None None Partial High High Medium None None High High None None None

Quantum Risk High High Very High Medium Low Low Medium High High Low Low High High High

deployment to progress at the pace of broader software ecosystem updates. Sector-wise observations reveal that adoption rates vary according to organizational requirements and infrastructure maturity. Highly regulated sectors, including banking, financial services, government, defence, and telecommunications, generally exhibit slower migration due to strict compliance requirements, certification procedures, and long infrastructure life cycles. In contrast, cloud-native organizations and large technology providers have adopted hybrid PQC mechanisms more rapidly through upgrades within cloud and CDN infrastructures. The continued prevalence of TLS 1.2 further highlights the challenges associated with cryptographic modernization. Although TLS 1.3 provides a more suitable framework for integrating hybrid post-quantum key exchange mechanisms, many organizations continue to support TLS 1.2 to maintain compatibility with legacy systems, embedded devices, older operating systems, and long-lived enterprise applications. Consequently, a substantial portion of Internet communications remains dependent on classical cryptographic mechanisms and cannot fully benefit from current hybrid PQC deployments. Collectively, these findings suggest that the primary barriers to PQC adoption are no longer the absence of standardized algorithms but rather the operational, economic, and compatibility challenges associated with large-scale migration. However, a critical limitation identified in this study is that certificate-based authentication remains entirely classical. TLS certificates continue to rely on RSA (56.9%) and ECDSA (43.1%) signature schemes, and no instances of hybrid or post-

PQC Readiness Classical ;(Dependent on underlying TLS libraries such as OpenSSL; PQC possible via hybrid extensions) Classical; ( Hybrid PQC supported when compiled with OpenSSL ≥ 3.5 or OQS provider) Classical; (Hybrid PQC support≥ Windows server 2025 , Windows 11 ; and future updates) (Hybrid PQC support experimental; e.g., Caddy via Go TLS hybrid implementations) (default X25519MLKEM768 in TLS 1.3) (default X25519MLKEM768 in TLS 1.3 ) Indirect (Hybrid PQC support depends on TLS libraries ) Unknown (Insufficient visibility to assess PQC readiness)

quantum digital signature algorithms were observed in X.509 certificates across the dataset. This finding reflects the current state of the public key infrastructure (PKI) ecosystem, where support for post-quantum certificate issuance, certificate transparency logging, certificate authority workflows, and browser trust stores remains under active development. This creates a fundamental security gap. While hybrid key exchange mechanisms improve confidentiality against future quantum adversaries, authentication remains dependent on quantum-vulnerable signature schemes. Under a quantum threat model, an adversary capable of breaking classical signature algorithms could forge certificates, impersonate legitimate servers, and conduct man-in-the-middle attacks. Consequently, hybrid key exchange alone is insufficient to provide end-to-end quantum security. At the infrastructure level, a clear divide exists between early adopters and traditional systems. This trend is currently concentrated among major cloud, CDN, and edge-service providers, whereas conventional web infrastructures continue to rely predominantly on classical TLS deployments. In most cases, PQC support is not implemented directly at the application layer but is inherited from underlying cryptographic libraries such as OpenSSL or BoringSSL, which significantly influences the pace of adoption. Another important observation is the dynamic nature of TLS configuration negotiation. Cryptographic parameters are selected during the handshake based on both client-side and server-side capabilities. As a result, even when servers support hybrid PQC, clients without such support may fall back to classical cryptographic algorithms. This fallback behavior is further validated through devicelevel observations and sector-wise analysis. For example, one device successfully established a QUIC connection using TLS 1.3 with modern cryptographic primitives, while another device connected to the same server using TLS 1.2 with classical cipher suites. Sector-wise data further shows that critical domains such as Government, Defence, and Telecom exhibit higher reliance on TLS 1.2 compared to cloud-centric sectors. From a quantum security perspective, this fallback has significant implications. TLS 1.2 configurations predominantly rely on classical key exchange mechanisms such as ECDHERSA, which are vulnerable to Shor’s algorithm, whereas TLS 1.3 enables hybrid PQC integration. Consequently, fallback scenarios can negate quantum-resistant benefits and lead to inconsistent security guarantees across connections.

If these implications are not addressed, the Internet’s trust model faces substantial systemic risk under a quantum threat. First, the continued use of RSA and ECDSA in certificates, combined with the absence of PQC-based certificate deployment, may enable certificate forgery once largescale quantum computing becomes practical. Such capabilities would allow adversaries to impersonate legitimate services and perform undetectable man-in-the-middle attacks. Second, the prevalence of classical key exchange mechanisms and TLS 1.2 fallback paths facilitates retrospective decryption under the Harvest-Now-Decrypt-Later (HNDL) threat model, exposing previously captured sensitive data, including financial transactions, authentication credentials, and government records. Third, inconsistent client–server negotiation leads to downgrade-driven security fragmentation, where even PQCcapable servers fall back to classical sessions for legacy clients, nullifying quantum-resistant benefits in practice. Finally, critical sectors such as BFSI, government, and defence accumulate concentrated risk due to slower upgrade cycles, increasing the likelihood of large-scale data breaches, identity fraud, and loss of service integrity. Without coordinated migration of both key exchange mechanisms and certificate-based authentication to post-quantum primitives, these risks will persist even as partial PQC adoption continues to grow. Overall, the coexistence of classical and hybrid cryptographic mechanisms reflects a gradual migration rather than a complete transition. Although the foundation for PQC adoption has been established through hybrid key exchange deployment, large-scale implementation remains incomplete, and systems continue to face long-term risks associated with Harvest-Now-Decrypt-Later (HNDL) attacks. In conclusion, hybrid key exchange mechanisms represent a significant step toward partial quantum resilience but do not provide complete security due to the continued reliance on classical certificate-based authentication. Achieving full end-to-end quantum security requires the migration of both key exchange mechanisms and certificate infrastructures to standardized post-quantum cryptographic algorithms. Future work should focus on the integration of PQC-based certificates, evaluation of fully post-quantum TLS handshakes, performance and interoperability assessment of post-quantum authentication mechanisms, and large-scale deployment strategies. Without such coordinated efforts, critical Internet infrastructure will remain vulnerable to quantum-enabled adversaries. R EFERENCES [1] N. Alnahawi, J. Müller, J. Oupický, and A. Wiesmaier, “SoK: Post-quantum TLS handshake,” Cryptology ePrint Archive, Paper 2023/1873, 2023. [Online]. Available: https://eprint.iacr.org/2023/1873 [2] P. W. Shor, “Algorithms for quantum computation: discrete logarithms and factoring,” in Proceedings 35th annual symposium on foundations of computer science. Ieee, 1994, pp. 124–134. [3] R. Vadisetty and A. Polamarasetti, “Quantum computing for cryptographic security with artificial intelligence,” in 2024 12th International Conference on Control, Mechatronics and Automation (ICCMA), 2024, pp. 252–260.

[4] National Institute of Standards and Technology (NIST), “What is post-quantum cryptography?” https://www.nist.gov/ cybersecurity-and-privacy/what-post-quantum-cryptography, 2026, accessed: Apr. 8, 2026. [5] R. Holz, L. Braun, N. Kammenhuber, and G. Carle, “The ssl landscape: a thorough analysis of the x. 509 pki using active and passive measurements,” in Proceedings of the 2011 ACM SIGCOMM conference on Internet measurement conference, 2011, pp. 427–444. [6] Z. Durumeric, Z. Ma, D. Springall, R. Barnes, N. Sullivan, E. Bursztein, M. D. Bailey, J. A. Halderman, and V. Paxson, “The security impact of https interception.” in NDSS, 2017. [7] C. Benitez, “Mapping quantum threats: An engineering inventory of cryptographic dependencies,” 2026. [Online]. Available: https: //arxiv.org/abs/2509.24623 [8] M. Raavi, Q. Khan, S. Wuthier, P. Chandramouli, Y. Balytskyi, and S.Y. Chang, “Security and performance analyses of post-quantum digital signature algorithms and their tls and pki integrations,” Cryptography, vol. 9, no. 2, p. 38, 2025. [9] R. Holz, J. Amann, A. Razaghpanah, and N. Vallina-Rodriguez, “The era of tls 1.3: Measuring deployment and use with active and passive methods,” 2019. [Online]. Available: https://arxiv.org/abs/1907.12762 [10] J. Chung and N. Vlajic, “Survey of remote tls vulnerability scanning tools and snapshot of tls use in banking sector,” in 2022 IEEE Conference on Communications and Network Security (CNS). IEEE, 2022, pp. 1–2. [11] J. Sowa, B. Hoang, A. Yeluru, S. Qie, A. Nikolich, R. Iyer, and P. Cao, “Post-quantum cryptography (pqc) network instrument: Measuring pqc adoption rates and identifying migration pathways,” in 2024 IEEE International Conference on Quantum Computing and Engineering (QCE), vol. 1. IEEE, 2024, pp. 1835–1846. [12] Durr-E-Shahwar, M. Imran, A. B. Altamimi, W. Khan, S. Hussain, and M. Alsaffar, “Quantum cryptography for future networks security: A systematic review,” IEEE Access, vol. 12, pp. 180 048–180 078, 2024. [13] G. Chhetri, S. Somvanshi, P. Hebli, S. Brotee, and S. Das, “PostQuantum Cryptography and Quantum-Safe Security: A Comprehensive Survey,” arXiv e-prints, p. arXiv:2510.10436, Oct. 2025. [14] N. Tarek and B. A. Hafid, “The quantum computer and the security of information systems,” in 2021 International Conference on Recent Advances in Mathematics and Informatics (ICRAMI), 2021, pp. 1–9. [15] Google and Cloudflare, “Experimenting with post-quantum cryptography in tls,” https://blog.cloudflare.com/post-quantum-for-all/, 2019, accessed: 2026-04-11. [16] E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.3,” RFC 8446, Aug. 2018. [Online]. Available: https://www.rfc-editor. org/info/rfc8446 [17] E. Rescorla and T. Dierks, “The Transport Layer Security (TLS) Protocol Version 1.2,” RFC 5246, Aug. 2008. [Online]. Available: https://www.rfc-editor.org/info/rfc5246 [18] J. Iyengar and M. Thomson, “QUIC: A UDP-Based Multiplexed and Secure Transport,” RFC 9000, May 2021. [Online]. Available: https://www.rfc-editor.org/info/rfc9000 [19] M. Thomson and S. Turner, “Rfc 9001: Using tls to secure quic,” 2021. [20] M. Bishop, “HTTP/3,” RFC 9114, Jun. 2022. [Online]. Available: https://www.rfc-editor.org/info/rfc9114 [21] M. C. andBrian LaMacchia and D. Ott, “Post quantum cryptography: Readiness challenges and the approaching storm,” Computing Community Consortium, Washington, D.C., Tech. Rep. White Paper 14, 10 2020. [Online]. Available: https://cra.org/ ccc/wp-content/uploads/sites/2/2020/10/Post-Quantum-Cryptography -Readiness-Challenges-and-the-Approaching-Storm-1.pdf [22] D. Stebila, S. Fluhrer, and S. Gueron, “Hybrid key exchange in TLS 1.3,” Internet Engineering Task Force, Internet-Draft draft-ietftls-hybrid-design-16, Sep. 2025, work in Progress. [Online]. Available: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/16/ [23] Cloudflare, “Post-quantum cryptography (pqc),” 2026, accessed: Apr. 10, 2026. [Online]. Available: https://developers.cloudflare.com/ssl/ post-quantum-cryptography/ [24] ——, “Post-quantum cryptography at cloudflare,” https://blog.cloudflare. com/, n.d., accessed: 2026-04-11. [25] ——, “Post-quantum cryptography support,” 2026, accessed: Apr. 10, 2026. [Online]. Available: https://developers.cloudflare.com/ssl/ post-quantum-cryptography/pqc-support/ [26] Cloudflare Research, “Post-quantum key agreement test,” 2026, accessed: 2026. [Online]. Available: https://pq.cloudflareresearch.com/

[27] National Institute of Standards and Technology (NIST), “Addressing [46] Google, “Experimenting with post-quantum cryptography,” n.d., visibility challenges with tls 1.3 within the enterprise,” NIST, Tech. Rep. accessed: 2026-04-11. [Online]. Available: https://security.googleblog. SP 1800-37, 2025. com/ [47] J. Schaumann, “Akamai enables post-quantum cryptography on [28] ——, “Addressing visibility challenges with tls 1.3 within the the edge,” Akamai Blog, Sep. 2025, accessed: Apr. 10, enterprise,” NIST, Tech. Rep. SP 1800-37, 2020, accessed: 2026. [Online]. Available: https://www.akamai.com/blog/security/ Apr. 10, 2026. [Online]. Available: https://nvlpubs.nist.gov/nistpubs/ akamai-enables-post-quantum-cryptography-edge/ SpecialPublications/NIST.SP.1800-37.pdf [48] Fastly, “Post-quantum cryptography roadmap,” n.d., accessed: 2026-04[29] National Cybersecurity Center of Excellence (NCCoE), “Addressing 11. [Online]. Available: https://www.fastly.com/ visibility challenges with tls 1.3 within enterprise faqs,” 2026, [49] Imperva (Thales), “Post-quantum cryptography (pqc) support,” accessed: Apr. 10, 2026. [Online]. Available: https://www.nccoe.nist. n.d., accessed: 2026-04-11. [Online]. Available: https: gov/addressing-visibility-challenges-tls-13-within-enterprise-faqs //docs-cybersec.thalesgroup.com/bundle/cloud-application-security/ [30] National Vulnerability Database (NVD), “Cve-2015-4000: Logjam page/pqc-support.htm attack,” 2015, accessed: Apr. 10, 2026. [Online]. Available: https: [50] Sucuri, “Website security platform,” n.d., accessed: 2026-04-11. //nvd.nist.gov/vuln/detail/CVE-2015-4000 [Online]. Available: https://sucuri.net/website-security-platform/ [31] Cybersecurity and Infrastructure Security Agency (CISA), “Siemens [51] C. van de Sande, “Post-quantum cryptography (pqc) support in nginx,” scalance x-200rna switch devices,” 2022, accessed: Apr. 10, 2026. NGINX Blog, Dec. 2025, accessed: 2026-04-11. [Online]. Available: [Online]. Available: https://www.cisa.gov/news-events/ics-advisories/ https://blog.nginx.org/blog/pqc-nginx icsa-22-349-21 [52] A. Thipsay, “Post-quantum cryptography apis now generally [32] Y. Sheffer, R. Holz, and P. Saint-Andre, “Summarizing Known Attacks available on microsoft platforms,” Microsoft Security Blog, on Transport Layer Security (TLS) and Datagram TLS (DTLS),” RFC Nov. 2025, accessed: 2026-04-11. [Online]. Available: 7457, Feb. 2015. [Online]. Available: https://www.rfc-editor.org/info/ https://techcommunity.microsoft.com/blog/microsoft-security-blog/ rfc7457 post-quantum-cryptography-apis-now-generally-available-on-microsoft-platforms/ [33] B. Moeller and A. Langley, “TLS Fallback Signaling Cipher 4469093 Suite Value (SCSV) for Preventing Protocol Downgrade Attacks,” [53] Google Security Blog, “Post-quantum cryptography: Standards and Internet Engineering Task Force, Internet-Draft draft-ietf-tls-downgradeprogress,” Aug. 2024, published: Aug. 13, 2024; Accessed: Apr. scsv-00, Jul. 2014, work in Progress. [Online]. Available: https: 11, 2026. [Online]. Available: https://security.googleblog.com/2024/08/ //datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/00/ post-quantum-cryptography-standards.html [34] N. J. Al Fardan and K. G. Paterson, “Lucky thirteen: Breaking the tls and dtls record protocols,” in 2013 IEEE symposium on security and privacy. IEEE, 2013, pp. 526–540. [35] National Cybersecurity Center of Excellence (NCCoE), “Nist final sp 1800-37: Addressing visibility challenges with tls 1.3,” 2026, accessed: Apr. 10, 2026. [Online]. Available: https://www.nccoe.nist.gov/news-insights/ now-available-nist-final-sp-1800-37-addressing-visibility-challenges-tls-13 [36] Marnix Dekker, Jurgita Skritaite, Eleni Philippou, Rossen Naydenov, ENISA , “Nis360 2024,” ENISA, Tech. Rep., 2025, accessed: Apr. 10, 2026. [Online]. Available: https://www.enisa.europa.eu/sites/default/ files/2025-03/ENISA%20-%20NIS360%20-%202024 0.pdf [37] European Union Agency for Cybersecurity (ENISA), “2024 report on the state of cybersecurity in the union panel – expert perspectives,” ENISA, Tech. Rep., 2025, accessed: Apr. 10, 2026. [Online]. Available: https://www.enisa.europa.eu/sites/default/files/2025-10/ NIS2%20Critical%20Sector%20Resilience%20Panel%20-%20Expert% 20Perspectives 0.pdf [38] Marianthi Theocharidou, Ifigeneia Lella, Rossen Naydenov, Apostolos Malatras, European Union Agency for Cybersecurity (ENISA), “Enisa threat landscape: Finance sector,” ENISA, Tech. Rep., Feb. 2025, accessed: Apr. 10, 2026. [Online]. Available: https://www.enisa.europa. eu/sites/default/files/2025-02/Finance%20TL%202024 Final.pdf [39] European Union Agency for Cybersecurity (ENISA), “Enisa sectorial threat landscape – public administration,” ENISA, Tech. Rep., Nov. 2025, accessed: Apr. 10, 2026. [Online]. Available: https://www.enisa.europa.eu/publications/ enisa-sectorial-threat-landscape-public-administration [40] B. Dowling, M. Fischlin, F. Günther, and D. Stebila, “A cryptographic analysis of the tls 1.3 handshake protocol,” Journal of Cryptology, vol. 34, no. 4, p. 37, 2021. [41] National Institute of Standards and Technology (NIST), “Post-quantum cryptography standardization,” https://csrc.nist.gov/projects/post-quantum-cryptography/ post-quantum-cryptography-standardization, 2016, accessed: 202604-11. [42] S. Boeyen, S. Santesson, T. Polk, R. Housley, S. Farrell, and D. Cooper, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile,” RFC 5280, May 2008. [Online]. Available: https://www.rfc-editor.org/info/rfc5280 [43] Cloudflare, “What is a cdn (content delivery network)?” https://www. cloudflare.com/learning/cdn/what-is-a-cdn/, n.d., accessed: 2026-04-11. [44] Akamai Technologies, “Content delivery network (cdn) overview,” https: //www.akamai.com/, n.d., accessed: 2026-04-11. [45] Amazon Web Services, “Post-quantum cryptography in aws,” n.d., accessed: 2026-04-11. [Online]. Available: https://aws.amazon.com/ security/post-quantum-cryptography/