PaperlayerView exact revision on arXiv

Source-linked AI summary

Operationalising Post Quantum TLS Automated Configuration Profiling and Hybrid PQC Deployment in Financial Infrastructure

Harish Balaji, Aarav Varshney, Prasanna Ravi, Sripal Jain, Robin Foe, Jorden Seet, Huaxiong Wang, Kwok-Yan Lam, Anupam Chattopadhyay

arXiv:2605.17955v1cs.CR

TL;DR

Financial TLS migration is operationally difficult because teams lack precise visibility into declared configurations across distributed endpoints. The paper proposes configuration-level inventory and migration methods; its Nginx study finds no hybrid key-exchange adoption, alongside substantial legacy exposure. It concludes that migration can begin at outer TLS termination layers and proceed inward.

  • Problem

    Financial TLS endpoints are heterogeneous, and configuration-level visibility is needed to identify permitted settings beyond those seen in negotiated handshakes.

    Source: The Operational Challenge in Financial… · p. 2

  • Method

    The paper presents a deterministic framework that extracts and normalizes TLS settings into a provenance-traced inventory for policy comparison.

    Source: A. Motivation and Design Goals · p. 4, §VI · p. 14

  • Results

    Across 8,443 Nginx configurations, hybrid key-exchange adoption was zero, 28.9% relied on RSA key exchange without forward secrecy, and 21.8% permitted TLS 1.0 or 1.1.

    Source: §VI · p. 14

  • Takeaways & Limitations

    The authors' migration strategy starts at the outermost TLS termination layer and works inward across the distributed cryptographic perimeter.

    Source: §VI · p. 14

    The public GitHub corpus overrepresents development and template configurations: 42.6% of TLS-enabled contexts use non-production hostnames, and production financial configurations are unavailable.

    Source: D. Limitations · p. 12

Abstract

from arXiv · show

Organisations are upgrading their cryptographic infrastructure to become quantum safe before large scale quantum computers materialise. Post quantum cryptography (PQC) standards now exist for key exchange and digital signatures, but the urgent question for adopters is how to operationalise PQC in complex environments with confidence. In banking, Transport Layer Security (TLS), for example, protects data in transit across public facing channels and internal services, and is terminated at many heterogeneous endpoints (web servers, API gateways, load balancers, reverse proxies), each a potential quantum vulnerable component and migration target. We argue that the bottleneck is operational rather than algorithmic, hybrid key exchanges such as MLKEM and hybrid MLKEM key exchanges are already available in mainstream libraries, but security teams lack precise visibility into TLS configurations and repeatable methods for enabling PQC compatible settings across a heterogeneous estate. This paper presents a configuration parsing methodology that automatically extracts and normalises TLS cryptographic posture across dominant enterprise web server stacks, producing a unified, provenance traced cryptographic inventory as a foundation for migration and compliance. We demonstrate the approach on 8,443 real world Nginx configurations from public repositories and in a proof of concept deployment at a financial institution, where MLKEM and hybrid MLKEM key exchanges at TLS termination points (web server and API gateway) securing an internal application, with zero application layer changes and manageable performance overhead.

I. INTRODUCTION

The quantum threat makes PQC migration urgent, but financial organisations face an operational challenge: establishing what heterogeneous TLS endpoints permit and how to change them repeatably. This paper presents configuration-level discovery and normalization, measurements of public Nginx configurations, and a financial-institution deployment.

I. INTRODUCTION

  • Quantum computers threaten RSA and elliptic-curve cryptography, while harvest-now, decrypt-later attacks make migration urgent for data requiring long-term confidentiality.NIST's 2024 PQC standards address the algorithmic dimension, leaving adopters with the operational question of how to migrate confidently.Source: §I · pp. 1–2

The Operational Challenge in Financial Infrastructure

  • Banks must identify permitted cryptography across distributed TLS termination points; the challenge is operational visibility and repeatable configuration, not hybrid key-exchange availability.Scanners observe negotiated handshakes, not all permitted settings and declared fallbacks.Source: The Operational Challenge in Financial… · p. 2

Our Contributions

  • The paper contributes a deterministic, provenance-traced TLS inventory framework, a proof-of-concept hybrid PQC deployment at web servers and API gateways, and a large-scale Nginx configuration study.The deployment served an internal banking application without application changes and reported manageable overhead and zero errors across test runs.Source: Our Contributions · p. 2
  • The study analyzes 8,443 real-world Nginx configurations from public repositories to characterize TLS practices and quantum-vulnerability exposure.Its measurements cover protocol adoption, cipher-suite hygiene, key-exchange vulnerability, certificate management, and configuration drift across active and archived repositories.Source: Our Contributions · p. 2

II. BACKGROUND AND RELATED WORK

Quantum algorithms threaten public-key cryptography, and harvest-now, decrypt-later attacks make migration relevant before a cryptographically relevant quantum computer arrives. PQC standards and hybrid TLS key exchange provide a migration path, while distributed, heterogeneous TLS termination complicates deployment and motivates configuration-level discovery.

A. The Quantum Threat to Public-Key Cryptography

  • Shor's algorithm threatens RSA and elliptic-curve cryptography, while harvest-now, decrypt-later attacks put long-confidentiality data at risk before quantum computers arrive.Grover's algorithm reduces the effective security of symmetric primitives, making key-size increases the stated response for private-key cryptography.Source: A. The Quantum Threat to Public-Key… · p. 3

B. NIST Post-Quantum Cryptography Standardization

  • NIST finalized ML-KEM, ML-DSA, and SLH-DSA in 2024; TLS hybrid key exchange combines classical ECDH with ML-KEM for security against classical and quantum adversaries.Hybrid deployment is recommended during the transition period to guard against unforeseen weaknesses in new algorithms.Source: B. NIST Post-Quantum Cryptography… · p. 3

C. TLS as the Primary Migration Surface

  • TLS termination is distributed across many independent endpoints, and heterogeneous configurations can permit vulnerable fallback protocols or cipher suites invisible to handshake scanners.TLS 1.0 and 1.1 are deprecated and banned under PCI-DSS v4.0, yet persist in real-world configurations.Source: C. TLS as the Primary Migration Surface · p. 3

D. Related Work

  • Prior TLS studies measured handshakes or particular cryptographic practices; this work instead examines configuration files and quantum-vulnerability exposure, complementing PQC protocol research and prescriptive migration guidance.It also measures current practice and reports a financial-environment deployment case.Source: D. Related Work · p. 4

A. Motivation and Design Goals

Heterogeneous TLS configuration models make it difficult to inventory an enterprise's permitted cryptography consistently, while network scanners cannot reveal all declared settings. The framework parses technology-specific configurations, normalizes them into a common model, and preserves provenance for comparison and remediation.

A. Motivation and Design Goals

  • Heterogeneous infrastructure exposes TLS through different syntax, directive names, inheritance rules, and vendor defaults, and scanners miss permitted fallbacks and declared key references.The framework's goals are deterministic extraction, cross-stack normalization, source provenance, and declarative extensibility.Source: A. Motivation and Design Goals · p. 4

B. System Architecture

1) Stage 1: Technology-Specific Parsing:

  • Technology-specific parsers resolve configuration inheritance and extract allowlisted TLS directives from Nginx, Apache, and Spring Boot configurations.The allowlist covers ten categories, including protocols, cipher suites, certificates and keys, client authentication, session management, HSTS, and ECDH curves.Source: 1) Stage 1: Technology-Specific Parsing · pp. 4–5

2) Stage 2: Normalization into the Unified TLS Model:

  • The Unified TLS Model normalizes endpoint, protocol, cipher, certificate, and trust settings into a technology-agnostic schema.The model's eight sections include endpoint details, enabled TLS versions, cipher choices, certificate references, and trust paths.Source: 2) Stage 2: Normalization into the… · p. 5
  • The model also represents verification, session, and security-header settings, with declarative mappings preserving each field's source directive and raw value.The derived_from record traces normalized values back to their configuration source.Source: 2) Stage 2: Normalization into the… · p. 5

3) Stage 3: Policy Comparison:

The framework compares normalized TLS settings with configurable security policies and supports migration planning that accounts for HSM constraints. Its dataset pipeline yielded 8,443 unique Nginx configuration files, including 5,982 TLS-enabled server contexts for analysis.

3) Stage 3: Policy Comparison:

  • The comparison engine produces pass/fail reports per server context against configurable standards and organizational policies, including quantum-readiness classification of cryptographic risk.Supported profiles include NIST SP 800-52 Rev. 2, PCI-DSS v4.0, CIS Benchmarks, Mozilla profiles, and custom policies.Source: 3) Stage 3: Policy Comparison · p. 5

C. HSM Awareness

  • HSM awareness comes from detecting PKCS#11 URI references and engine directives instead of filesystem key paths, identifying a migration-planning constraint.HSM firmware may require updates for PQC algorithms, and HSM-backed systems have different key-rotation procedures and migration timelines.Source: C. HSM Awareness · p. 5

D. Migration Workflow Integration

  • The migration lifecycle links discovery, risk assessment, prioritization, deployment, and post-migration policy verification in a continuous monitoring loop.The same pipeline used to build the initial inventory also monitors the post-migration environment.Source: D. Migration Workflow Integration · p. 6

A. Dataset Construction

  • The Nginx corpus was collected from public GitHub repositories using directive-based searches, file deduplication, and structural confidence filtering.Repository archive status and last-push date were used to distinguish active from dormant configurations.Source: A. Dataset Construction · p. 6
  • 5,982 of 12,875 parsed server-block contexts had TLS enabled, drawn from 8,443 unique configuration files after deduplication.The files comprised 5,524 from active repositories and 2,919 from archived repositories.Source: A. Dataset Construction · p. 6

B. Research Questions and Findings

The findings show widespread TLS 1.2 and strong TLS 1.3 adoption, alongside deprecated protocol allowances and weak cipher entries. They also identify quantum-vulnerable key exchange and gaps in certificate and key management.

1) RQ1: Protocol Adoption:

  • 21.8% of configurations still permit TLS 1.0 or 1.1, despite TLS 1.2 adoption at 95.8% and TLS 1.3 at 73.5%.TLS 1.0 and 1.1 are formally deprecated by RFC 8996 and prohibited by PCI-DSS v4.0.Source: 1) RQ1: Protocol Adoption · p. 6

2) RQ2: Cipher Suite Hygiene:

  • 37.6% of 3,603 contexts with explicit cipher configurations include at least one weak cipher token.The most frequently co-occurring cipher pair is ECDHE-RSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384, appearing together in 1,737 contexts.Source: 2) RQ2: Cipher Suite Hygiene · p. 6
  • Post-quantum hybrid key exchange adoption is zero in the corpus, while RSA key exchange appears in 28.9% of contexts.Among the 625 contexts explicitly configuring ssl_ecdh_curve, X25519MLKEM768 appears in four (0.8%).Source: 2) RQ2: Cipher Suite Hygiene · pp. 6–7, Table II · p. 7

4) RQ4: Certificate and Key Management:

  • Certificate and key paths are present in 95.0% and 96.1% of contexts, respectively, but DH parameters are configured in only 20.6%.HSM/PKCS#11 references are absent from the dataset.Source: 4) RQ4: Certificate and Key Management · p. 7

5) RQ5: HSTS Adoption:

HSTS is uncommon among TLS-enabled contexts, and mTLS adoption is low. The findings also identify mixed-strength cipher lists, legacy configuration practices, and inconsistent TLS policies across server blocks.

5) RQ5: HSTS Adoption:

  • Only 38.2% of TLS-enabled contexts configure HSTS.The paper states that HSTS prevents SSL stripping at zero performance cost.Source: 5) RQ5: HSTS Adoption · p. 7

6) RQ6: Mutual TLS:

  • mTLS adoption is 6.2% overall and is nearly identical in active and archived repositories, at 6.1% and 6.2%, respectively.The paper attributes this pattern to architectural choice, such as service mesh or internal APIs, rather than security-trend evolution.Source: 6) RQ6: Mutual TLS · p. 7
  • Some configurations combine strong AEAD ciphers with weak ciphers such as RC4, DES, 3DES, EXPORT, NULL, or MD5.The paper characterizes these mixed lists as potentially more dangerous than purely weak configurations because they create a false sense of security.Source: 6) RQ6: Mutual TLS · p. 7

8) RQ8: Configuration Decay:

  • Archived repositories use legacy OpenSSL presets more often than active repositories, and their higher use of negation tokens reflects an older cipher-listing approach.The paper notes that shorthand macros can change effective cipher lists silently across OpenSSL upgrades; the ‘!eNULL’ gap is 4.3% versus 14.3%.Source: 8) RQ8: Configuration Decay · p. 7

9) RQ9: Internal Configuration Consistency:

  • Nearly a third of multi-context configuration files have inconsistent TLS policies across server blocks, with cipher drift in 19.1%.Cipher drift means different virtual hosts in the same file use different cipher suites.Source: 9) RQ9: Internal Configuration… · p. 8

10) RQ10: Active vs Archived Drift:

Archived repositories show worse TLS hygiene than active ones, while AEAD is common but CBC remains in a smaller tail. The findings also examine cipher-order settings, named curves, and cipher-string length.

10) RQ10: Active vs Archived Drift:

  • 47.3% of archived repositories use legacy cipher presets, compared with 30.8% of active repositories, a 16.5 percentage-point gap.The paper reports that archived repositories exhibit worse TLS hygiene across multiple dimensions.Source: 10) RQ10: Active vs Archived Drift · p. 8
  • 72.3% of configurations with explicit cipher lists are AEAD-only, while 6.1% still include CBC ciphers.The paper says the CBC tail represents configurations not updated since at least 2014.Source: 10) RQ10: Active vs Archived Drift · pp. 8–9

12) RQ12: Cipher Order Hygiene:

  • 37.8% of TLS-enabled contexts set ssl_prefer_server_ciphers; the analysis examines whether this correlates with cipher-list quality.The supplied finding describes the question investigated, not its outcome.Source: 12) RQ12: Cipher Order Hygiene · p. 9

13) RQ13: ECDHE Named Curve Preferences:

  • Only 10.4% of TLS-enabled contexts explicitly set ssl_ecdh_curve, and X25519MLKEM768 appears in four configurations (0.8% of those specifying a curve).The paper calls these four configurations the earliest post-quantum key-exchange adopters in the dataset.Source: 13) RQ13: ECDHE Named Curve Preferences · p. 9

14) RQ14: Cipher String Length:

  • The cipher-string-length analysis examines whether Nginx configurations tend toward minimal security-focused lists or sprawling legacy configurations.The supplied passages describe the question but do not report its result.Source: 14) RQ14: Cipher String Length · pp. 9–10

15) RQ15: Session Management:

The Nginx measurements describe session management, certificate issuance and chain practices, certificate storage, and the coexistence of TLS and plaintext listeners.

15) RQ15: Session Management:

  • Half of configs rely on Nginx’s default session-cache behavior, while 47.6% explicitly configure shared caches, the production-recommended pattern.Source: 15) RQ15: Session Management · p. 10

16) RQ16: Let’s Encrypt Adoption:

  • Let’s Encrypt powers over a third of TLS-enabled contexts in public repositories, while the self-signed rate is 4.5%.The paper suggests free CA certificates have reduced the incentive to self-sign.Source: 16) RQ16: Let’s Encrypt Adoption · p. 11

17) RQ17: Certificate Bundle vs Leaf-Only:

  • 53.3% of configs reference only the leaf certificate, which may cause chain-validation failures on strict clients; Let’s Encrypt paths dominate among fullchain configs.The paper says ACME tooling encourages correct certificate bundling practices.Source: 16) RQ16: Let’s Encrypt Adoption · p. 11

18) RQ18: Certificate Storage Patterns:

  • Nginx’s own directory is the most common certificate and key storage location, followed closely by Let’s Encrypt’s standard path.Environment-variable paths account for 6.9% and Docker secrets for 0.5%.Source: 18) RQ18: Certificate Storage Patterns · p. 11

19) RQ19: Plaintext Listener Coexistence:

20) RQ20: Default and Wildcard Server Names:

The findings characterize quantum-vulnerable TLS settings and the public-repository deployment context, while identifying limits in dataset representativeness, technology coverage, migration scope, and deployment validation.

20) RQ20: Default and Wildcard Server Names:

  • 42.6% of TLS-enabled contexts use likely non-production hostnames, and 8.3% use environment-variable hostname injection.The paper interprets nearly half the configurations as templates, tutorials, development environments, or placeholders rather than hardened production systems.Source: 20) RQ20: Default and Wildcard Server… · p. 11

C. Key Takeaways

  • 28.9% of configurations additionally lack forward secrecy, while every measured configuration relies on quantum-vulnerable key exchange; 21.8% permit TLS 1.0/1.1 despite likely negotiating TLS 1.2/1.3.Source: C. Key Takeaways · p. 11
  • The 28.9% relying on RSA key exchange without forward secrecy can permit recorded sessions to be decrypted after long-term private-key compromise, even without a quantum computer.The authors recommend treating ephemeral key exchange as an immediate action and hybrid PQC as the next step.Source: C. Key Takeaways · p. 11
  • 29.7% of configurations delegate TLS settings to framework defaults; the authors propose approved hybrid-PQC baseline templates as a route to broad coverage through template governance.Source: C. Key Takeaways · p. 11

D. Limitations

  • The public-GitHub corpus overrepresents development and template configurations, and production financial-services configurations are unavailable.Source: D. Limitations · p. 12
  • The framework covers Nginx, Apache, and Spring Boot, but not HAProxy, Envoy, IIS, Tomcat, or cloud-managed TLS services.Source: D. Limitations · p. 12
  • Both the measurement study and deployment address TLS key exchange, not RSA/ECDSA-to-ML-DSA certificate migration.The authors say certificate migration warrants separate study once IETF LAMPS composite-certificate standards stabilize.Source: D. Limitations · p. 12
  • The OCBC case study is a single-institution deployment; generalizability to other institutions, architectures, or higher-traffic environments needs validation through additional deployments.Source: D. Limitations · p. 12

V. HYBRID PQC DEPLOYMENT IN A PRODUCTION BANKING ENVIRONMENT

The proof of concept targets TLS sessions touching an internal banking application and aims to protect them against quantum threats while preserving client compatibility and avoiding application changes. It places TLS termination at an Apache web server and a Java/Spring Boot API gateway, and enables hybrid key exchange at the web server.

A. Deployment Context and Threat Model

  • The deployment targets sensitive financial transactions with long-term confidentiality needs; its objective is to protect all sessions touching the application while preserving client compatibility and making no application changes.Source: A. Deployment Context and Threat Model · pp. 12–13

B. System Architecture

  • The three tiers are an Apache public-facing web server, a Java/Spring Boot API gateway, and an internal banking application; both server and gateway terminate TLS.The gateway establishes new TLS sessions toward backend services, while the application hosts sensitive financial records.Source: B. System Architecture · p. 13
  • The existing TLS used ECDHE with P-256, which is vulnerable to Shor’s algorithm; certificate authentication was retained unchanged in this phase.Source: B. System Architecture · p. 13

1) Hybrid PQC at the Web Server Layer:

  • At the Apache layer, hybrid TLS 1.3 key exchange required an OpenSSL upgrade with the Open Quantum Safe provider; clients lacking hybrid-group support fall back to X25519.The X25519MLKEM768 group combines classical X25519 with ML-KEM-768.Source: 1) Hybrid PQC at the Web Server Layer · p. 13

2) Hybrid PQC at the API Gateway Layer:

The paper evaluates hybrid PQC at an API gateway and measures its performance against classical X25519. It also identifies deployment conditions and remaining migration constraints.

2) Hybrid PQC at the API Gateway Layer:

  • Registering BouncyCastle’s PQC providers enables the Java JCA/JSSE layer to handle X25519MLKEM768 or MLKEM512 key-exchange groups without gateway application-code changes.The Java frameworks support only classical algorithms by default.Source: 2) Hybrid PQC at the API Gateway Layer · p. 13

1) Methodology:

  • The h2load evaluation compared classical X25519 with ML-KEM-512 hybrid key exchange using 100 concurrent clients over 30 seconds.It measured request time, connection time, time to first byte, and per-client request rate.Source: 1) Methodology · p. 13

2) Results:

  • 24.7 ms to 30.4 ms mean time-for-connect (+23%) was the primary overhead for ML-KEM-512 hybrid key exchange.The comparison used classical X25519 as the baseline.Source: 2) Results · p. 13, Table XI · p. 14
  • End-to-end request latency increased by approximately 1.3%, per-client throughput decreased by approximately 1.6%, and both configurations had zero test errors.The authors describe this as an acceptable trade-off in the financial-institution context, where connection reuse is standard and protected data has decade-long confidentiality requirements.Source: 2) Results · p. 14

E. Lessons Learned

  • Migration at the web-server and API-gateway termination layers secured the internal banking application without changing the application itself.The authors identify this layer-by-layer approach as practical for systems accessed through gateways or load balancers.Source: E. Lessons Learned · p. 14
  • Java PQC support is not enabled by default; operators must register the BouncyCastle provider at JVM startup.The provider architecture permits injection without application-code modification.Source: E. Lessons Learned · p. 14
  • Because the deployment used filesystem-backed private keys, production migration with HSM-backed keys depends on assessing HSM firmware for ML-KEM support.Source: E. Lessons Learned · p. 14
  • The deployment covers key exchange only: certificates still use RSA or ECDSA, leaving ML-DSA certificate migration for a later phase when supporting PKI allows it.Source: E. Lessons Learned · p. 14

F. Discussion: Synthesizing the Three Contributions

The discussion connects the configuration framework, Nginx measurement study, and financial-institution deployment as a path from discovery to migration. It identifies operational visibility as the central barrier and outlines further coverage and measurement work.

F. Discussion: Synthesizing the Three Contributions

  • The three contributions form a progression: a discovery framework for organizational infrastructure, an 8,443-configuration Nginx measurement study, and an OCBC deployment demonstration.The study measures protocol, cipher-suite, key-exchange, and certificate-management practices in the wild.Source: F. Discussion: Synthesizing the Three… · p. 14
  • The authors identify operational visibility—not algorithmic readiness—as the primary migration barrier: organizations lack a precise, machine-readable account of their configured cryptography and needed changes.Source: F. Discussion: Synthesizing the Three… · p. 14, §VI · p. 14

VI. CONCLUSION AND FUTURE WORK

  • In the measured corpus, post-quantum hybrid key-exchange adoption was zero; 28.9% of configurations relied on RSA key exchange without forward secrecy, and 21.8% still permitted deprecated TLS 1.0 or 1.1.The empirical measurement study examined 8,443 real-world Nginx configurations.Source: §VI · p. 14
  • TLS termination is distributed across independently targeted perimeter components, and the proposed strategy begins migration at the outermost termination layer and proceeds inward.Source: §VI · p. 14
  • Future work includes extending discovery to HAProxy, Envoy, and cloud-native TLS services, tracking adoption longitudinally, and studying ML-DSA certificate migration when standards and PKI support are ready.The four X25519MLKEM768 configurations found in the corpus are described as the leading edge of a measurable trend.Source: §VI · pp. 14–16
Loading 2605.17955v1…