Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL
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.
On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez <fj.gutierrezs91@gmail.com> wrote:
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).
You should perhaps start by doing basic level research, since we did that over
a decade ago.
--
Daniel Gustafsson
Hi Daniel,
I appreciate the pointer. You are correct that the abstraction of the SSL
layer is a topic that has surfaced on the mailing list multiple times over
the last decade.
However, my intention is not to disregard the project's history, but
rather to re-evaluate the technical viability under current architectural
conditions. One of the primary historical hurdles for integrating modern
libraries like Botan into a C-based project like PostgreSQL has been
Botan's reliance on Boost.Asio or C++-centric asynchronous I/O models for
communications management.
Technical Complexity: The ASIO Integration Challenge
In analyzing the current integration, I see several critical points that
differentiate the current landscape from the debates of ten years ago:
Impedance Mismatch (ASIO vs. Postgres):
Botan’s TLS architecture often defaults to a data-flow model or relies on
Boost.Asio for event handling. Mapping this to PostgreSQL’s process-based,
synchronous socket model introduces significant complexity. Bridging a
C++-heavy asynchronous event loop into a legacy C codebase without
introducing "callback hell" is a non-trivial engineering task.
Signal and Memory Management:
Integrating a C++ runtime requires careful handling of PostgreSQL's custom
memory management (palloc) and signal handling (Longjmp-based error
recovery), which can conflict with C++ exception handling and ASIO's
internal state.
AI-Assisted Refactoring: A key differentiator today is the advent of
Advanced AI Agents.
These tools significantly lower the overhead of large-scale refactorings.
Tasks that were previously deemed too labor-intensive—such as abstracting
be-secure-openssl.c into a generic provider interface—can now be executed
with much higher precision and consistent boilerplate generation, allowing
developers to focus on the high-level architectural integrity.
Why Reopen the Discussion Now?
My proposal stems from the need to comply with security agency regulations
(such as the CCN in Spain), which are beginning to mandate cryptographic
agility and Post-Quantum Cryptography (PQC) readiness. Botan offers a
native path toward PQC that is currently more complex to maintain solely
through OpenSSL patches or oqs providers.
I have developed a reference model (mentioned in the previous Appendix)
using a proxy to mitigate this coupling, but I believe an internal
abstraction would benefit the core’s long-term resilience.
Is there a specific design document or thread from previous attempts that
you consider "required reading" so I can avoid repeating past architectural
mistakes in a potential patch proposal?
Best regards,
El sáb, 21 mar 2026, 21:11, Daniel Gustafsson <daniel@yesql.se> escribió:
Show quoted text
On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez <
fj.gutierrezs91@gmail.com> wrote:
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).You should perhaps start by doing basic level research, since we did that
over
a decade ago.--
Daniel Gustafsson
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:
Show quoted text
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.