Hello PostgreSQL community, I would like to start a discussion regarding the feasibility of decoupling our current TLS implementation to allow for alternative cryptographic backends, specifically **Botan** (via its C wrapper).
While OpenSSL is the current standard, the "rules of the game" in software engineering are changing. The advent of advanced AI-assisted development tools now provides the technical viability to undertake significant refactorings—such as abstracting the network security layer—with much higher precision and lower overhead than in the past. The primary motivation for adding Botan support is **compliance and architectural flexibility**: 1. **Regulatory Requirements:** In jurisdictions like Spain, the **CCN (Centro Criptológico Nacional)** sets specific standards for cryptographic modules. Having an alternative like Botan facilitates certification in these restricted environments. 2. **Architectural Robustness:** A provider-agnostic TLS layer makes PostgreSQL more resilient to library-specific vulnerabilities or licensing changes. 3. **Modern Integration:** Using Botan's C wrappers allows the engine to benefit from a modern C++ cryptographic core while maintaining the project's C-based architecture. I am interested in knowing the community's stance on abstracting `be-secure-openssl.c` into a more generic interface. Best regards, [Tu Nombre] --- ### Appendix: Proof of Concept - Proxy Model with Botan To validate the viability of Botan in high-security environments without depending on OpenSSL's native integration, I have developed a reference implementation available at: 👉 [ https://github.com/jgmatu/management-sensors](https://github.com/jgmatu/management-sensors) **Architectural Model:** In this project, I implemented a **Quantum-Safe Proxy** that acts as a bridge between non-PQC clients and the core system. Key features of this model include: * **Decoupled TLS Engine:** Using `QuantumSafeTlsEngine` (based on Botan TLS v1.3) to handle all secure handshakes independently of the application logic. * **Reactive Event Bus:** Utilizing PostgreSQL's `LISTEN/NOTIFY` mechanism to manage state and configurations without direct coupling between the server and the controllers. * **Post-Quantum Ready:** Demonstrating that Botan can provide PQC (Post-Quantum Cryptography) algorithms today, which is a requirement increasingly demanded by national security agencies like the CCN. This proxy model proves that Botan is not only a viable alternative but also provides advanced features that are currently difficult to implement with a hard dependency on OpenSSL.
