Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL - Mailing list pgsql-hackers

From Enrique Soriano
Subject Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
Date
Msg-id CAMPpeEU-TPCFi+psvv6dymb+1K3jNW10w47SKQmMy46fjbwB+g@mail.gmail.com
Whole thread
In response to Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL  (Javier Gutierrez-Maturana sanchez <fj.gutierrezs91@gmail.com>)
List pgsql-hackers
I’m not quite sure why I was included in this thread, I am not interested in this topic. Kindly remove me from any future emails.

Regards,
Enrique

On Sat, 21 Mar 2026 at 19:44, Javier Gutierrez-Maturana sanchez <fj.gutierrezs91@gmail.com> wrote:


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:

**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.

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Remove inner joins based on foreign keys
Next
From: Heikki Linnakangas
Date:
Subject: Re: Bug in MultiXact replay compat logic for older minor version after crash-recovery