public inbox for [email protected]help / color / mirror / Atom feed
Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL 4+ messages / 3 participants [nested] [flat]
* Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL @ 2026-03-21 18:44 Javier Gutierrez-Maturana sanchez <[email protected]> 0 siblings, 2 replies; 4+ messages in thread From: Javier Gutierrez-Maturana sanchez @ 2026-03-21 18:44 UTC (permalink / raw) To: [email protected]; Enrique Soriano <[email protected]>; Gorka Guardiola <[email protected]> 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. ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL @ 2026-03-21 20:11 Daniel Gustafsson <[email protected]> parent: Javier Gutierrez-Maturana sanchez <[email protected]> 1 sibling, 1 reply; 4+ messages in thread From: Daniel Gustafsson @ 2026-03-21 20:11 UTC (permalink / raw) To: Javier Gutierrez-Maturana sanchez <[email protected]>; +Cc: PostgreSQL Hackers <[email protected]>; Enrique Soriano <[email protected]>; Gorka Guardiola <[email protected]> > On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez <[email protected]> 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 ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL @ 2026-03-21 20:47 Javier Gutierrez-Maturana sanchez <[email protected]> parent: Daniel Gustafsson <[email protected]> 0 siblings, 0 replies; 4+ messages in thread From: Javier Gutierrez-Maturana sanchez @ 2026-03-21 20:47 UTC (permalink / raw) To: [email protected]; +Cc: PostgreSQL Hackers <[email protected]>; Enrique Soriano <[email protected]>; Gorka Guardiola <[email protected]> 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 <[email protected]> escribió: > > On 21 Mar 2026, at 19:44, Javier Gutierrez-Maturana sanchez < > [email protected]> 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 > > ^ permalink raw reply [nested|flat] 4+ messages in thread
* Re: Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL @ 2026-03-22 10:53 Enrique Soriano <[email protected]> parent: Javier Gutierrez-Maturana sanchez <[email protected]> 1 sibling, 0 replies; 4+ messages in thread From: Enrique Soriano @ 2026-03-22 10:53 UTC (permalink / raw) To: Javier Gutierrez-Maturana sanchez <[email protected]>; +Cc: [email protected]; Gorka Guardiola <[email protected]> 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 < [email protected]> 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: > 👉 [ > 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. > > ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-03-22 10:53 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-03-21 18:44 Proposal: Implementing Botan as an alternative TLS backend for PostgreSQL Javier Gutierrez-Maturana sanchez <[email protected]> 2026-03-21 20:11 ` Daniel Gustafsson <[email protected]> 2026-03-21 20:47 ` Javier Gutierrez-Maturana sanchez <[email protected]> 2026-03-22 10:53 ` Enrique Soriano <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox