pith. sign in

arxiv: 2605.17955 · v1 · pith:COUWWSF4new · submitted 2026-05-18 · 💻 cs.CR

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
show 1 more author
Anupam Chattopadhyay
This is my paper

Pith reviewed 2026-05-20 09:57 UTC · model grok-4.3

classification 💻 cs.CR
keywords post-quantum cryptographyTLS configuration parsinghybrid key exchangequantum-safe migrationfinancial infrastructureNginx configuration analysisautomated cryptographic inventory
0
0 comments X

The pith

A parsing methodology automatically extracts and normalizes TLS cryptographic settings from enterprise web servers to support post-quantum migration.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces an automated configuration parsing method that pulls TLS cryptographic details from dominant web server stacks and turns them into a single, traceable inventory. This inventory serves as the starting point for organizations to plan and execute upgrades to post-quantum cryptography in complex environments like banking. The method was applied to 8,443 real-world Nginx configuration files and tested in a financial institution proof-of-concept where hybrid post-quantum key exchanges were enabled at TLS termination points. The deployment required no changes to application code and showed manageable performance impact. The core problem addressed is the lack of precise visibility into existing TLS setups that blocks practical adoption of available post-quantum and hybrid algorithms.

Core claim

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, demonstrated on 8,443 real world Nginx configurations and in a proof of concept deployment at a financial institution where MLKEM and hybrid MLKEM key exchanges were enabled at TLS termination points with zero application layer changes.

What carries the argument

The automated configuration parsing and normalisation logic that extracts TLS directives from server config files and produces a unified, provenance-traced cryptographic inventory.

If this is right

  • Security teams obtain a repeatable, auditable view of current TLS posture without manual review of thousands of files.
  • Hybrid post-quantum key exchanges can be introduced at TLS endpoints while leaving application code untouched.
  • Migration planning and compliance reporting gain a single source of truth with traceable origins for each setting.
  • Performance overhead from hybrid algorithms remains practical in real financial-infrastructure workloads.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same parsing approach could be extended to other server types such as Apache, IIS, or cloud load balancers to cover a broader estate.
  • Provenance tracing opens the door to automated change recommendation tools that suggest minimal edits to enable hybrid PQC.
  • The inventory format might serve as input for continuous compliance monitoring systems that flag quantum-vulnerable configurations over time.

Load-bearing premise

The parsing rules and normalisation logic correctly interpret every custom and legacy TLS directive in heterogeneous production environments without systematic omissions or misclassifications.

What would settle it

Run the parser against a curated collection of production-style Nginx and other server configurations that deliberately include obscure legacy directives, custom cipher lists, and conditional statements, then measure the rate of missed or incorrectly classified settings against manual expert review.

Figures

Figures reproduced from arXiv: 2605.17955 by Aarav Varshney, Anupam Chattopadhyay, Harish Balaji, Huaxiong Wang, Jorden Seet, Kwok-Yan Lam, Prasanna Ravi, Robin Foe, Sripal Jain.

Figure 1
Figure 1. Figure 1: The three-stage pipeline: PARSE, NORMALIZE, and COMPARE. b) apache HTTP Server.: The configuration of apache is governed by a set of directives with defined scoping rules across <VirtualHost> and <Directory> containers. The parser uses the apacheconfig library and applies Apache’s precedence rules to determine the effective value of each TLS directive per virtual host. c) Spring Boot.: Spring Boot exposes … view at source ↗
Figure 2
Figure 2. Figure 2: Protocol Adoption 2) RQ2: Cipher Suite Hygiene: Of the 3,603 TLS￾enabled contexts with explicit cipher configurations, 37.6% include at least one weak cipher token (RC4, DES, 3DES, EXPORT, NULL, or MD5, excluding properly negated entries). The most frequently co-occurring ci￾pher pair is ECDHE-RSA-AES128-GCM-SHA256 and ECDHE-RSA-AES256-GCM-SHA384, appearing together in 1,737 contexts, indicating strong AEA… view at source ↗
Figure 3
Figure 3. Figure 3: Cipher Suite Hygiene [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Cipher Suite Hygiene TABLE II KEY EXCHANGE CATEGORIES BY QUANTUM VULNERABILITY Key Exchange Category Share ECDHE/DHE (forward secrecy, quantum-vulnerable) 71.1% RSA KE (no forward secrecy, quantum-vulnerable) 28.9% PQC hybrid (quantum-resistant) 0.0% it provides no forward secrecy, meaning compromise of the server’s private key, whether by a classical adversary today or a quantum adversary in the future, r… view at source ↗
Figure 5
Figure 5. Figure 5: Quantum Vulnerability Surface 4) RQ4: Certificate and Key Management: Certificate and key paths are present in 95.0% and 96.1% of contexts respectively. DH parameters are configured in only 20.6% of contexts. HSM/PKCS#11 references are absent from the entire dataset, consistent with the expectation that hardware￾backed key protection is not represented in public repositories. Environment-variable certifica… view at source ↗
Figure 7
Figure 7. Figure 7: HSTS Adoption [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Mutual TLS (mTLS) [PITH_FULL_IMAGE:figures/full_fig_p008_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Mixed-Strength Configurations means the operator manages security policy at the vhost level rather than the server level — increasing the chance that one vhost falls behind during hardening updates. Nearly a third of multi-context config files have inconsistent TLS policies across their server blocks. Cipher drift (19.1%) is the most common — different vhosts within the same file negotiating different ciph… view at source ↗
Figure 10
Figure 10. Figure 10: Config Decay [PITH_FULL_IMAGE:figures/full_fig_p009_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Configuration Decay The industry has largely moved to AEAD, but the 6.1% CBC tail represents configs that haven’t been updated since at least 2014 — when POODLE should have prompted immediate CBC removal [PITH_FULL_IMAGE:figures/full_fig_p009_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: AEAD vs CBC Cipher Distribution [PITH_FULL_IMAGE:figures/full_fig_p010_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Cipher Order Hygiene [PITH_FULL_IMAGE:figures/full_fig_p010_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: ECDHE Named Curve Preferences TABLE VI DISTRIBUTION OF TLS SESSION CACHE TYPES Cache Type Share Not set (default) 50.9% Shared 47.6% Builtin 1.3% Off 0.2% mulated over years of incremental changes [PITH_FULL_IMAGE:figures/full_fig_p010_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Cipher String Length TABLE VIII ANALYSIS OF CERTIFICATE CHAIN CONFIGURATIONS Type Count Share Leaf-only 3,028 53.3% Fullchain bundle 2,656 46.7% 16) RQ16: Let’s Encrypt Adoption: Let’s Encrypt powers over a third of TLS-enabled Nginx contexts in public repos — a remarkable achievement for a service that didn’t exist before 2016. The 4.5% self-signed rate is relatively low, suggesting that free CA certific… view at source ↗
Figure 16
Figure 16. Figure 16: Session Management [PITH_FULL_IMAGE:figures/full_fig_p012_16.png] view at source ↗
Figure 19
Figure 19. Figure 19: Certificate Storage Patterns [PITH_FULL_IMAGE:figures/full_fig_p012_19.png] view at source ↗
Figure 20
Figure 20. Figure 20: Plaintext Listener Coexistence c) Key exchange only.: Both the measurement study and the deployment focus on TLS key exchange. Certificate migration (RSA/ECDSA to ML-DSA) is not addressed and war￾rants separate study once IETF LAMPS composite certificate standards stabilize. d) Single institution deployment.: The OCBC case study represents a single institution’s deployment. Generalizability to other insti… view at source ↗
Figure 18
Figure 18. Figure 18: Certificate Bundle vs Leaf-Only D. Limitations a) Dataset representativeness.: The measurement corpus consists of public GitHub repositories, which overrepresent development and template configurations: 42.6% of TLS￾enabled contexts use non-production hostnames. Production financial services configurations are not publicly available. b) Technology coverage.: The framework covers Nginx, Apache, and Spring … view at source ↗
Figure 21
Figure 21. Figure 21: Default and Wildcard Server Names data carries long-term confidentiality requirements, making it a priority target for HNDL-style quantum attacks. The threat model has two components. The future threat is a CRQC running Shor’s algorithm [1], capable of breaking the ECDH key exchange in the system’s existing TLS connections. The present threat is an adversary archiving encrypted TLS sessions today with the… view at source ↗
Figure 22
Figure 22. Figure 22: The Three Tier Architecture 1) Public-facing web server (Apache). Terminates TLS connections from internet-facing clients; acts as a reverse proxy routing requests to the API gateway. Primary TLS termination point for external traffic and first migration target. 2) API gateway (Java / Spring Boot). Manages authentica￾tion, authorization, rate limiting, and routing. Terminates TLS from the web server and e… view at source ↗
Figure 23
Figure 23. Figure 23: Time For Request [PITH_FULL_IMAGE:figures/full_fig_p015_23.png] view at source ↗
Figure 24
Figure 24. Figure 24: Time to Connect [PITH_FULL_IMAGE:figures/full_fig_p015_24.png] view at source ↗
Figure 25
Figure 25. Figure 25: Time to 1st Byte configurations identified in this corpus represent the leading edge of what will become a measurable trend. The certificate migration phase, and deploying ML-DSA certificates alongside hybrid key exchange, warrants a dedicated study once standards [PITH_FULL_IMAGE:figures/full_fig_p015_25.png] view at source ↗
read the original abstract

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.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The paper claims to introduce 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. This is positioned as a foundation for post-quantum migration and compliance, with demonstrations on 8,443 real-world Nginx configurations from public repositories and a proof-of-concept hybrid MLKEM deployment at a financial institution achieving zero application-layer changes.

Significance. If the parsing and normalisation logic proves accurate and generalisable beyond the demonstrated Nginx cases, the work could address a genuine operational bottleneck in financial TLS estates by enabling repeatable visibility and hybrid PQC configuration. The use of real production configurations and a working PoC with manageable overhead provides practical grounding, though the absence of validation metrics substantially reduces the strength of the contribution as presented.

major comments (2)
  1. [Abstract] The central claim that the methodology 'automatically extracts and normalises TLS cryptographic posture across dominant enterprise web server stacks' is load-bearing yet unsupported by quantitative evidence. The demonstration is limited to 8,443 Nginx configurations plus one PoC; no accuracy metrics, error rates, coverage statistics, or comparison against ground-truth labels for custom, legacy, or heterogeneous directives (e.g., ssl_ciphers, ssl_protocols, OpenSSL options) are reported.
  2. [Demonstration and proof-of-concept deployment] The weakest assumption—that parsing rules correctly interpret the full range of custom and legacy TLS directives without systematic omissions or misclassifications—is not tested. No inter-annotator agreement, manual audit of edge cases, or validation set spanning multiple stacks (Apache, IIS, load balancers, API gateways) is described, leaving open the possibility that normalisation silently drops or mis-maps non-standard configurations common in financial environments.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback highlighting the need for clearer scoping and validation evidence. We respond to each major comment below and indicate the revisions we will make to address the concerns while preserving the paper's core contributions on operational TLS inventory and hybrid PQC deployment.

read point-by-point responses

  1. Referee: [Abstract] The central claim that the methodology 'automatically extracts and normalises TLS cryptographic posture across dominant enterprise web server stacks' is load-bearing yet unsupported by quantitative evidence. The demonstration is limited to 8,443 Nginx configurations plus one PoC; no accuracy metrics, error rates, coverage statistics, or comparison against ground-truth labels for custom, legacy, or heterogeneous directives (e.g., ssl_ciphers, ssl_protocols, OpenSSL options) are reported.

    Authors: We accept that the abstract phrasing overstates the demonstrated breadth. The methodology was engineered for extensibility across stacks, but the reported evaluation and PoC were performed exclusively on Nginx configurations drawn from public repositories and the financial environment. No quantitative accuracy, error-rate, or coverage metrics were generated because the work prioritises end-to-end operational utility over benchmark-style parser validation. We will revise the abstract to state that the approach is demonstrated on Nginx while designed to be extensible, and we will insert a dedicated limitations subsection that explicitly notes the lack of cross-stack quantitative validation and ground-truth comparisons. revision: yes

  2. Referee: [Demonstration and proof-of-concept deployment] The weakest assumption—that parsing rules correctly interpret the full range of custom and legacy TLS directives without systematic omissions or misclassifications—is not tested. No inter-annotator agreement, manual audit of edge cases, or validation set spanning multiple stacks (Apache, IIS, load balancers, API gateways) is described, leaving open the possibility that normalisation silently drops or mis-maps non-standard configurations common in financial environments.

    Authors: The observation is correct. The parser rules were derived from Nginx documentation and patterns observed across the 8,443 configurations; the successful PoC deployment provided practical confirmation but no formal manual audit, inter-annotator agreement, or multi-stack test set was performed. We will revise the manuscript to document the parser's construction assumptions, to discuss the risk of silent omissions for legacy or non-standard directives, and to qualify the generalisability statement. A comprehensive cross-stack validation study lies outside the present scope and will be flagged as future work. revision: partial

Circularity Check

0 steps flagged

No circularity: methodology applies external parsing rules to real configurations

full rationale

The paper presents a configuration parsing methodology that extracts and normalizes TLS cryptographic posture from existing web server files, demonstrated directly on 8,443 real-world Nginx configurations and a PoC deployment. No equations, fitted parameters, self-referential definitions, or load-bearing self-citations appear in the described approach. The central claim reduces to applying explicit parsing logic to independent input data rather than any derivation that loops back to the paper's own outputs or assumptions. This is a standard engineering contribution with external validation points and no reduction of predictions to inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 0 invented entities

The approach relies on standard TLS configuration syntax and existing hybrid PQC library support without introducing new fitted parameters or postulated entities.

axioms (1)
  • domain assumption TLS configuration files from mainstream web servers contain extractable and interpretable cryptographic settings that can be normalised into a unified inventory
    This premise underpins the entire parsing methodology described in the abstract.

pith-pipeline@v0.9.0 · 5812 in / 1195 out tokens · 49045 ms · 2026-05-20T09:57:45.837125+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

18 extracted references · 18 canonical work pages · 1 internal anchor

  1. [1]

    Algorithms for quantum computation: Discrete logarithms and factoring,

    P. W. Shor, “Algorithms for quantum computation: Discrete logarithms and factoring,” inProceedings of the 35th Annual Symposium on Foundations of Computer Science (FOCS), 1994, pp. 124–134

    work page 1994

  2. [2]

    The PQC migration handbook, 2nd edition,

    M. Stevens and TNO, “The PQC migration handbook, 2nd edition,” TNO, Tech. Rep., Dec. 2024. [Online]. Available: https://publications. tno.nl/publication/34643386/fXcPVHsX/TNO-2024-pqc-en.pdf

    work page arXiv 2024

  3. [3]

    Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations

    R. Babbush, A. Zalcman, C. Gidney, M. Broughton, T. Khattar, H. Neven, T. Bergamaschi, J. Drake, and D. Boneh, “Securing elliptic curve cryptocurrencies against quantum vulnerabilities: Resource estimates and mitigations,”arXiv preprint arXiv:2603.28846, 2026

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  4. [4]

    Module-Lattice-Based Digital Signature Standard

    National Institute of Standards and Technology, “FIPS 203: Module- Lattice-Based Key-Encapsulation Mechanism Standard,” NIST, Tech. Rep., Aug. 2024. [Online]. Available: https://doi.org/10.6028/NIST.FIPS. 203

    work page doi:10.6028/nist.fips 2024

  5. [5]

    FIPS 204: Module-Lattice-Based Digital Signature Standard,

    ——, “FIPS 204: Module-Lattice-Based Digital Signature Standard,” NIST, Tech. Rep., Aug. 2024. [Online]. Available: https://doi.org/10. 6028/NIST.FIPS.204

    work page 2024

  6. [6]

    FIPS 205: Stateless Hash-Based Digital Signature Standard,

    ——, “FIPS 205: Stateless Hash-Based Digital Signature Standard,” NIST, Tech. Rep., Aug. 2024. [Online]. Available: https://doi.org/10. 6028/NIST.FIPS.205

    work page 2024

  7. [7]

    OQS-Provider: Post-quantum algorithms for OpenSSL,

    Open Quantum Safe Project, “OQS-Provider: Post-quantum algorithms for OpenSSL,” https://github.com/open-quantum-safe/oqs-provider, 2024

    work page 2024

  8. [8]

    Bouncy castle cryptography APIs for Java,

    The Legion of the Bouncy Castle, “Bouncy castle cryptography APIs for Java,” https://www.bouncycastle.org/, 2024

    work page 2024

  9. [9]

    SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations,

    National Institute of Standards and Technology, “SP 800-52 Rev. 2: Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations,” NIST, Tech. Rep., 2019. [Online]. Available: https://doi.org/10.6028/NIST.SP.800-52r2

    work page doi:10.6028/nist.sp.800-52r2 2019

  10. [10]

    A fast quantum mechanical algorithm for database search,

    L. K. Grover, “A fast quantum mechanical algorithm for database search,” inProceedings of the 28th Annual ACM Symposium on Theory of Computing (STOC), 1996, pp. 212–219

    work page 1996

  11. [11]

    Enterprise PQC migration: New study predicts 5–15+ year timelines,

    Post-Quantum, “Enterprise PQC migration: New study predicts 5–15+ year timelines,” https://postquantum.com/security-pqc/ enterprise-pqc-migration-study/, Dec. 2025

    work page 2025

  12. [12]

    RFC 8446: The transport layer security (TLS) protocol version 1.3,

    E. Rescorla, “RFC 8446: The transport layer security (TLS) protocol version 1.3,” Internet Engineering Task Force, 2018. [Online]. Available: https://www.rfc-editor.org/rfc/rfc8446

    work page 2018

  13. [13]

    NIST CSWP 39: Considerations for Achieving Crypto Agility,

    National Institute of Standards and Technology, “NIST CSWP 39: Considerations for Achieving Crypto Agility,” NIST, Tech. Rep., Dec

    work page

  14. [14]

    Available: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST

    [Online]. Available: https://nvlpubs.nist.gov/nistpubs/CSWP/NIST. CSWP.39.pdf

    work page

  15. [15]

    RFC 8996: Deprecating TLS 1.0 and TLS 1.1,

    K. Moriarty and S. Farrell, “RFC 8996: Deprecating TLS 1.0 and TLS 1.1,” Internet Engineering Task Force, 2021. [Online]. Available: https://www.rfc-editor.org/rfc/rfc8996

    work page 2021

  16. [16]

    We really need to talk about session tickets: A large-scale analysis of cryptographic dangers with TLS session tickets,

    S. Hebrok, S. Nachtigall, M. Maehren, N. Niemann, C. Pöpper, and J. Somorovsky, “We really need to talk about session tickets: A large-scale analysis of cryptographic dangers with TLS session tickets,” inProceedings of the 32nd USENIX Security Symposium. USENIX Association, 2023. [Online]. Available: https: //www.usenix.org/system/files/usenixsecurity23-h...

    work page 2023

  17. [17]

    A large-scale analysis of HTTPS deployments,

    R. van den Berg, J. Vreeken, and T. Holz, “A large-scale analysis of HTTPS deployments,”Journal of Computer Security, vol. 28, no. 6, pp. 631–660, 2020

    work page 2020

  18. [18]

    Looma: A low-latency PQTLS authentication architecture for cloud environments,

    TODO, “Looma: A low-latency PQTLS authentication architecture for cloud environments,” inProceedings of the Network and Distributed System Security Symposium (NDSS), 2026. [Online]. Available: https: //www.ndss-symposium.org/wp-content/uploads/2026-f74-paper.pdf

    work page 2026