Rethinking SSL and protocol transforms in lori

[SeanTAllen]

Context

This discussion captures research and design exploration for rethinking how lori handles SSL/TLS and protocol-level data transforms. The goal is to explore whether better APIs exist that avoid the footguns inherent in interceptor composition, potentially requiring changes to the ponylang/ssl library.

Related:

• Discussion Separate Data Interception from Lifecycle Events #149 — Separate Data Interception from Lifecycle Events (the current DataInterceptor design)
• PR Redesign send system for fallible sends and completion tracking #154 — Implementation of the DataInterceptor design
• Discussion Redesigning Lori's Send System #150 — Send system redesign

Why lori exists: the mixin pattern advantage

Lori uses the mixin pattern rather than the notifier pattern used by the stdlib net package. The key limitation of the notifier pattern (from the pattern documentation):

Notifiers cannot receive messages. They can send messages to actors they hold references to, but they have no way to receive arbitrary messages. Access to the notifier is completely controlled by the encompassing actor.

In lori, the user's actor implements traits (TCPConnectionActor, ServerLifecycleEventReceiver/ClientLifecycleEventReceiver) directly — the actor IS the connection handler. This means:

• The actor can receive both external messages AND connection lifecycle callbacks
• Lifecycle callbacks run as actor methods with full access to the actor's state
• Trait composition can enforce compile-time safety for state transitions

The ponylang/postgres library demonstrates why this matters. Its Session actor simultaneously manages TCP connection lifecycle, PostgreSQL authentication state, query dispatch, wire protocol parsing, and result delivery — all in one actor with a trait-based state machine that makes illegal state transitions unreachable at compile time. None of this is possible with the notifier pattern.

The problem: interceptors reintroduce notifier-pattern problems

The DataInterceptor trait (from Discussion #149) solves the data ordering problem — read and write paths need opposite orderings for protocol layering. But it introduces a separate object into the mixin pattern's data path, and that object is essentially a notifier:

• It can't receive messages
• It can't participate in the actor's state machine
• It sits outside the compile-time safety the mixin pattern provides

For a single interceptor (just SSL), this is manageable. But composition of multiple interceptors (SSL + compression, SSL + custom framing) introduces serious footguns:

1. Ordering mistakes — ChainedInterceptor(ssl, compression) vs ChainedInterceptor(compression, ssl) silently corrupts data. The user must get this right manually.

2. Setup/ready signaling with multiple handshaking interceptors — If two interceptors both need handshakes, who calls signal_ready() when? The ChainedInterceptor proposal hand-waved this as "harmless double-signal."

3. Error propagation across chains — If an inner interceptor fails during incoming(), how does that flow back through the chain? The push model doesn't have a natural error return path.

4. The interceptor is a notifier-like object inside a mixin architecture — It reintroduces the fundamental limitation that lori was created to avoid. The interceptor can't receive messages, can't be part of the actor's type-safe state machine, and composition creates a chain of objects with the same problems as notifier wrapping.

Current SSL architecture

How lori uses the ssl library today

Lori's SSLClientInterceptor and SSLServerInterceptor implement DataInterceptor, wrapping the ponylang/ssl library's SSL class. The SSL class uses OpenSSL's memory BIO abstraction — it's a state machine where the caller feeds in encrypted bytes and reads out decrypted bytes:

• SSL.receive(data) — feed encrypted bytes from the wire
• SSL.read(expect) — extract decrypted plaintext
• SSL.write(data) — encrypt plaintext for sending
• SSL.can_send() / SSL.send() — extract encrypted bytes for the wire
• SSL.state() — check handshake state (SSLReady | SSLAuthFail | SSLError)

The interceptors bridge between this API and lori's DataInterceptor interface, managing handshake signaling, pending write buffering, and error handling.

Pain points with ponylang/ssl

The ponylang/ssl library wraps OpenSSL via FFI with approximately 75-80 distinct FFI calls. Key pain points:

Version complexity. Three OpenSSL version families (0.9.0, 1.1.x, 3.0.x) with three-way ifdef branches in 10+ locations. The openssl_0.9.0 flag is actually used for LibreSSL compatibility (see below), not ancient OpenSSL.

LibreSSL misidentification. LibreSSL users build with -Dopenssl_0.9.0, which forces them through a code path that disables ALPN (which LibreSSL supports), runs unnecessary locking ceremony (which is a no-op in LibreSSL), and uses legacy API names (which LibreSSL has modern equivalents for). LibreSSL's actual API is mostly OpenSSL 1.1.x compatible with a few holdovers. This is tracked as a separate issue.

Global initialization. _SSLInit._init() runs at program startup. For the 0.9.0/LibreSSL path, this involves CRYPTO_set_locking_callback reaching into the Pony runtime — fragile coupling.

Memory management. Finalizers coordinate between Pony's GC and OpenSSL's C memory. BIO buffers are OpenSSL-allocated and freed by SSL_free. The Digest class can leak its EVP context.

Large FFI surface. ~55 OpenSSL FFI calls in the networking layer alone.

Alternative TLS libraries evaluated

Nine TLS libraries were evaluated as potential replacements. Key findings:

rustls-ffi — Best I/O model fit (no socket ownership, maps directly to DataInterceptor). Memory-safe TLS in Rust. Rejected: requires a Rust toolchain to build, which is not acceptable as a dependency for the Pony ecosystem.

mbedTLS — Self-contained C library, no external deps, clean API. Uses I/O callbacks where the callee performs data transfer — actually harder to integrate than OpenSSL's memory BIOs since it requires FFI callbacks from C into Pony. No FIPS certification.

s2n-tls — Battle-tested (Amazon S3), FIPS-capable. But requires a libcrypto dependency (doesn't eliminate OpenSSL), has global init (s2n_init()), and per-thread state that's awkward for Pony's scheduler.

wolfSSL — Comprehensive features, FIPS certified. GPLv2 license is problematic for ponylang projects.

BearSSL — Ideal I/O model (pure state machine, zero allocation). Disqualified: unmaintained since 2018, no TLS 1.3.

picotls — Clean buffer-oriented API. TLS 1.3 only — can't connect to older servers.

BoringSSL, LibreSSL — Same memory BIO model as OpenSSL, no meaningful improvement for lori's use case. BoringSSL has no stable API/ABI.

GnuTLS — Heavy dependency chain (libnettle, GMP), global init requirements.

Conclusion: No alternative C TLS library is clearly better than a cleaned-up OpenSSL wrapper for lori's architecture. The callback-based libraries (mbedTLS, s2n-tls) are actually harder to integrate than OpenSSL's memory BIOs.

Cross-language patterns for TLS in actor-model languages

Research into how other actor-model and GC'd languages handle TLS revealed a strong pattern:

Language	Approach	Protocol Logic	Crypto Primitives
Erlang/OTP	Pure language protocol + C crypto	Erlang (gen_statem)	OpenSSL via NIFs
Go	Fully pure language	Go	Go + asm
Haskell	Pure language protocol + C crypto	Haskell (tls package)	C via crypton FFI
OCaml	Pure language protocol + C crypto	OCaml (ocaml-tls)	C via nocrypto
Rust (rustls)	Pure language protocol + C crypto	Rust	C via aws-lc-rs
Zig	Fully pure language	Zig	Zig

The consensus approach for languages with GC and/or actor models is: implement TLS protocol logic in the host language, use C only for crypto primitives. This eliminates the impedance mismatch between C TLS state machines and the host language's concurrency/memory model.

Key lessons:

• Erlang discovered that a single actor handling both TLS read and write can deadlock under backpressure, leading to a two-process model (tls_sender split in OTP 21).
• Haskell's tls library was motivated by exactly lori's problem: C TLS libraries are "extremely stateful" and wrapping them creates "IO mess to do essentially pure things."
• Go's crypto/tls requires at least 5 named core maintainers — the maintenance burden is significant.
• OCaml's nqsb-TLS achieved a trusted code base 25x smaller than OpenSSL with matching handshake performance.

Design directions being explored

The fundamental tension: lori's mixin pattern gives the actor compile-time safety and message-receiving ability, but protocol transforms need to sit between the wire and the actor. How do you get protocol transforms without reintroducing notifier-pattern problems?

Direction A: SSL as a first-class connection concern

TCPConnection has built-in SSL support. The actor never sees encrypted data, never deals with handshake signaling:

_tcp_connection = TCPConnection.ssl_client(auth, ssl_ctx, host, port, "", this, this)

The connection manages the SSL session internally. _on_connected fires only after handshake completes. _on_received delivers decrypted data. send() encrypts automatically.

For simpler transforms (compression, framing), the actor handles them in its callback implementations — no separate object needed, no composition headaches.

Implication for ssl library: The SSL class's memory BIO API (receive/read/write/send/state) would be used internally by TCPConnection. The ssl library might need minimal changes — the SSL class is already transport-independent.

Direction B: Two-level architecture

At most one "protocol adapter" (SSL) that lives inside the connection and handles complex lifecycle concerns (handshake, ready signaling, errors). Plus simple data transforms expressed as trait methods on the actor — no separate objects, no composition.

Ordering is fixed by architecture: wire → protocol adapter → actor transforms. No user-controlled ordering to get wrong.

Direction C: Transform as mixin traits

Protocol transforms expressed as traits the actor mixes in, keeping everything on the actor and preserving compile-time safety. But this has Pony trait composition challenges when multiple transforms want to override the same callback.

Open questions

1. Which direction (A, B, C, or something else) best preserves lori's mixin pattern benefits while enabling protocol transforms?
2. What does this mean for the ponylang/ssl library — does it need to change, or is its current SSL class API sufficient for whatever lori does internally?
3. Is TLS 1.3-only sufficient for lori's needs, or is TLS 1.2 support required? (Affects scope if a Pony TLS implementation is ever considered.)
4. Should the LibreSSL define fix (separate issue) proceed immediately regardless of this design work?

[SeanTAllen]

Directions A and B are complementary, not alternatives

After discussion, directions A (SSL as first-class connection concern) and B (two-level architecture with protocol adapters) are complementary rather than competing options. The combined model has three fixed layers:

1. SSL (built into the connection) — always there if configured, invisible to everything above it. Not an interceptor, not composable, just part of the connection. The actor never sees encrypted data or handshake signaling.

2. Protocol adapter (at most one) — sits above the decrypted stream inside the connection. Handles protocol-level framing concerns (e.g., HTTP framing, WebSocket framing). Always sees decrypted data.

3. Actor trait methods — the actor handles application-level concerns in its callback implementations. Simple transforms happen here. Always sees protocol-parsed data.

Ordering is fixed by architecture — no user composition, no ordering footguns. SSL can never be put in the wrong place. Protocol adapters always operate on decrypted data. The actor always operates on protocol-parsed data.

This is the direction to explore further.

[SeanTAllen]

Discussion #157 explores making SSL a first-class TCPConnection concern (Direction A). Four explicit constructors (client, server, ssl_client, ssl_server), SSLContext as the dependency injection point, SSL session managed entirely inside the connection. The ssl library does not need to change — its existing SSL class API is used internally by TCPConnection. This serves as the foundation that Direction B (protocol adapters) will build on top of.

[SeanTAllen]

TLS Alternatives Research

Full research document exploring alternative TLS approaches for lori, evaluating five options along a spectrum from least to most ambitious.

---

Alternative TLS Approaches for Lori

Current State

Lori uses the ponylang/ssl library, which wraps OpenSSL via FFI. The ssl library exposes two main types to lori: SSLContext (configuration, certificate loading, session creation) and SSL (per-connection state machine using OpenSSL's memory BIO abstraction). Lori's SSLClientInterceptor and SSLServerInterceptor implement the DataInterceptor trait, bridging between SSL and lori's transport-owning TCPConnection. The interceptors feed encrypted bytes from the wire into SSL.receive(), read decrypted plaintext via SSL.read(), encrypt outgoing data via SSL.write(), and extract ciphertext via SSL.send() / SSL.can_send(). The DataInterceptor pattern cleanly separates TLS from transport: TCPConnection owns the socket, and the interceptor is a pure data transformer called by the connection-owning actor.

Key pain points with the current approach:

Version ifdef complexity. The ponylang/ssl library supports three OpenSSL version families (0.9.0, 1.1.x, 3.0.x), resulting in three-way ifdef branches throughout the codebase. The compile_error "You must select an SSL version to use." sentinel appears in 10 separate locations. OpenSSL 0.9.0 support is the largest burden: it requires manual thread-safety setup via CRYPTO_set_locking_callback reaching into the Pony runtime, cannot support ALPN, and uses legacy API names (SSLv23_method, EVP_MD_CTX_create, sk_pop). Even between 1.1.x and 3.0.x there are API renames (SSL_get_peer_certificate to SSL_get1_peer_certificate) and feature differences (XOF digest finalization). OpenSSL 3.4 changed behavior around XOF digests, requiring another version-specific fix.

FFI surface area. The ssl library declares approximately 75-80 distinct FFI calls across its networking and crypto modules, with around 55 in the networking layer alone. This is a large surface of unsafe C interop to maintain.

Global initialization. The _SSLInit primitive uses Pony's _init() mechanism to call OpenSSL initialization at program startup. For 0.9.0, this involves setting up mutexes and a global locking callback -- fragile coupling between the Pony runtime and OpenSSL internals. Even for 1.1.x/3.0.x, OPENSSL_init_ssl() is required before any other call.

Memory management. Two classes use finalizers (SSLContext._final(), SSL._final()) to call SSL_CTX_free and SSL_free. BIO memory buffers are allocated by OpenSSL and freed by OpenSSL when SSL_free is called. The Digest class has no finalizer -- if final() is never called, the EVP context leaks. Pony-allocated buffers are passed to OpenSSL for writing hash output, which works but requires careful coordination between Pony's GC and C memory ownership.

Unused API surface. Lori uses a small fraction of the ssl library: context creation, cert/key/CA loading, verification toggles, client/server session creation, and the core read/write/receive/send cycle plus state checking and ALPN result reading. The library also contains cipher configuration, protocol version pinning, an SSLConnection wrapper for the stdlib net pattern (unused by lori), X509 inspection, and the entire ssl/crypto package (Digest, HashFn) -- none of which lori needs.

Approaches

Approach 1: Stay with OpenSSL, Drop 0.9.0 Support

What it is. Keep OpenSSL as the underlying TLS library but drop support for OpenSSL 0.9.0 in the ponylang/ssl library. Simplify the remaining code to support only 1.1.x and 3.0.x (or potentially only 3.0.x). No changes to lori itself.

How it would work with lori. No changes needed in lori. The ssl library's API stays the same; only the internal implementation simplifies. The DataInterceptor pattern, the SSL class's memory BIO interface, and all interceptor code remain unchanged.

What changes. In ponylang/ssl:

• Remove all ifdef "openssl_0.9.0" branches and the associated FFI declarations (SSLv23_method, SSL_library_init, SSL_load_error_strings, CRYPTO_num_locks, CRYPTO_set_locking_callback, EVP_MD_CTX_create, EVP_MD_CTX_destroy, sk_pop, sk_free).
• Remove the @ponyint_ssl_multithreading coupling to the Pony runtime.
• The _SSLInit._init() body becomes the simple OPENSSL_init_ssl path only.
• ALPN code no longer needs version guards (it was unavailable on 0.9.0).
• If also dropping 1.1.x, the 3.0.x-only path eliminates the SSL_get_peer_certificate vs SSL_get1_peer_certificate branch and the XOF digest finalization branch.
• Roughly 40% of ifdef branching disappears by dropping 0.9.0 alone.

Advantages.

• Lowest effort of any approach -- pure subtraction from existing code.
• No risk of regression in lori; the integration surface is unchanged.
• Removes the most fragile coupling (runtime threading callback).
• Eliminates the most painful maintenance burden (0.9.0 API differences).
• OpenSSL 0.9.0 has been EOL since 2015; no users should still need it.

Disadvantages.

• Does not address the fundamental issue: lori is still wrapping OpenSSL's large, complex C API via FFI.
• The remaining 1.1.x/3.0.x branching still exists (though it is much smaller).
• The FFI surface area remains at roughly 55 networking calls (minus a handful of 0.9.0-specific ones).
• Memory management concerns (finalizers, GC/C memory coordination) remain.
• Future OpenSSL version changes (like the 3.4 XOF behavior change) will continue to require maintenance.
• Global initialization is still required.

Effort estimate. Small. This is removing code, not adding it. Could be done in a single PR to ponylang/ssl.

Risk factors. Minimal technical risk. The main risk is community pushback if any users still depend on 0.9.0, but that seems unlikely given the version has been EOL for over a decade.

---

Approach 2: Switch to rustls via rustls-ffi

What it is. Replace OpenSSL with rustls, using its C API (rustls-ffi). Rustls is a memory-safe TLS implementation written in Rust, backed by the ISRG/Prossimo memory safety initiative. Its C API is explicitly designed for caller-managed transport -- it never touches a socket.

How it would work with lori. Rustls's I/O model maps directly to DataInterceptor. The core cycle is:

1. Caller feeds ciphertext into rustls_connection_read_tls() (maps to incoming() receiving wire data).
2. Caller calls rustls_connection_process_new_packets() to advance the TLS state machine.
3. Caller reads plaintext via rustls_connection_read() (maps to pushing data to IncomingDataReceiver).
4. Caller writes plaintext via rustls_connection_write() (maps to outgoing() receiving application data).
5. Caller extracts ciphertext via rustls_connection_write_tls() (maps to pushing data to WireSender).

The read_tls and write_tls methods use callbacks rather than buffer copies, reducing data copying. The caller checks rustls_connection_wants_read() and rustls_connection_wants_write() to determine when I/O is needed. This is the same "encrypted pipe" pattern that DataInterceptor implements, just with different function names.

What changes. In ponylang/ssl: either rewrite the SSL / SSLContext classes to wrap rustls-ffi instead of OpenSSL, or create a new library. The FFI surface would be much smaller -- rustls-ffi is intentionally minimal, with opaque pointer types, paired _new/_free lifecycle functions, and consistent result codes. In lori: SSLClientInterceptor and SSLServerInterceptor would need to change their internal implementation to call rustls functions instead of the ssl library's SSL class, but the DataInterceptor trait and all external interfaces remain identical.

Advantages.

• Best I/O model fit of any actively maintained library. The no-socket design was built for exactly this use case. While it uses callbacks for read_tls/write_tls, those callbacks present library-owned buffers that the caller reads from or writes to -- closer to buffer operations than the "perform the I/O yourself" callbacks of mbedTLS/s2n.
• No global initialization required. No global mutable state.
• Memory safety in the TLS implementation itself (Rust's guarantees). Connection objects are not thread-safe (used from one thread at a time), but stateless objects like configs can be shared -- compatible with Pony's actor model where each connection lives in one actor.
• Significantly smaller FFI surface than OpenSSL. The C API is well-documented and designed for language bindings.
• No version branching headaches. Rustls has a single, clean API. Opaque pointer types with paired _new/_free functions are straightforward for Pony to manage.
• TLS 1.2 and 1.3 supported. ALPN, SNI, client certificates. Post-quantum key exchange (X25519MLKEM768) offered by default.
• FIPS 140-3 capable when built with the fips feature (uses aws-lc-rs backed by FIPS-validated AWS-LC).
• Apache 2.0 / MIT dual license -- no GPL concerns.
• Actively maintained by the rustls project with ISRG backing.
• Outperforms OpenSSL in benchmarks.

Disadvantages.

• Requires a Rust toolchain to build. This is the major practical barrier. Building rustls-ffi requires cargo, which means either: (a) users need Rust installed, (b) the Pony ecosystem ships prebuilt static libraries for each platform, or (c) the build system manages a Rust toolchain automatically. None of these are trivial.
• Dynamic linking is experimental with no ABI stability guarantees. Static linking is recommended, which means the Rust-built .a file must match the target platform.
• Uses aws-lc-rs by default for cryptographic operations (a Rust wrapper around AWS-LC, which is C). So this is not "pure Rust" for crypto -- it has its own C dependency chain inside.
• Certificate verification cannot be turned off in the main API (deliberate security decision). If lori's set_client_verify(false) / set_server_verify(false) needs to be preserved, this requires using the dangerous module.
• No DTLS support (not currently needed by lori, but worth noting).
• No TLS 1.0/1.1 support by design. This is likely fine for lori but could matter for users connecting to legacy servers.

Effort estimate. Medium. The ponylang/ssl library would need a substantial rewrite of its internals (or a new library created alongside it). Lori's interceptor code would need moderate changes to use the new API. The build system integration for the Rust toolchain is the largest unknown.

Risk factors. Build toolchain complexity is the primary risk. The Pony ecosystem's build system (corral, ponyc) would need to handle a Rust dependency, which is unprecedented. Platform coverage for prebuilt libraries needs to match Pony's supported platforms. The Rust toolchain requirement could be a barrier for contributors and CI.

---

Approach 3: Switch to mbedTLS

What it is. Replace OpenSSL with mbedTLS (maintained by ARM via the TrustedFirmware project). MbedTLS is a C library designed for embedded systems with a small footprint, clean modular API, and no external dependencies.

How it would work with lori. MbedTLS supports custom transport callbacks via mbedtls_ssl_set_bio(), which takes an opaque context pointer and send/receive callback functions. The send callback signature is int (*)(void *ctx, const unsigned char *buf, size_t len) and the receive callback is similar. For lori's DataInterceptor, the context pointer would reference the interceptor's buffer state. When incoming() is called, the interceptor would buffer the wire data and then call mbedtls_ssl_read(), which internally calls the receive callback to pull from that buffer. The receive callback copies ciphertext from the buffer into mbedTLS's internal buffer. Similarly, outgoing() would call mbedtls_ssl_write(), which encrypts and calls the send callback, where the interceptor captures the ciphertext and pushes it to WireSender. This callback-based model adds a layer of indirection compared to rustls's buffer-oriented approach, but it is proven and widely used.

What changes. In ponylang/ssl: rewrite internals to wrap mbedTLS instead of OpenSSL. The FFI calls would change entirely -- mbedTLS uses mbedtls_<module>_<operation> naming with _init() / _free() lifecycle on each module. The callback-based I/O model requires different plumbing than OpenSSL's memory BIO approach. In lori: similar changes to the interceptors as with rustls, adapting to the callback model.

Advantages.

• Self-contained C library with no external dependencies. Builds with any C compiler. Trivially statically linked.
• Small binary footprint -- designed for embedded systems.
• Clean, modular C API with consistent naming. Moderate size -- significantly smaller than OpenSSL, though larger than rustls-ffi.
• Highly configurable via mbedtls_config.h -- individual features can be enabled/disabled at compile time.
• No Rust toolchain required. Standard C build with CMake or make.
• TLS 1.2 and 1.3 support (1.3 added in the 3.x branch). ALPN, SNI, client certificates.
• Apache 2.0 license (dual-licensed with GPLv2+, but the Apache option avoids GPL concerns).
• Actively maintained with releases every 3-6 months. Latest LTS branch is 3.6.x.
• Custom memory allocators supported -- potential for better GC integration.

Disadvantages.

• I/O callback model expects the callee to perform actual data transfer (copy data in/out), unlike rustls's callbacks which present library-owned buffers. The callback approach requires FFI callbacks from C into Pony, which adds complexity (Pony must provide C-callable function pointers, manage the context pointer safely, ensure the callback doesn't violate reference capabilities). This is more complex to implement correctly than OpenSSL's memory BIO approach or rustls's buffer-presenting callbacks.
• Threading is not enabled by default -- requires compile-time flags (MBEDTLS_THREADING_C). Custom threading must be set up before any other mbedTLS call. RNG seeding must happen in the initial thread. These constraints need careful handling in Pony's actor model.
• Not FIPS certified. NIST test vectors are incorporated but no formal validation exists. This is a gap compared to OpenSSL, rustls (via aws-lc), or wolfSSL.
• Post-quantum cryptography is only in early experimental stages.
• The callback I/O model means mbedTLS assumes it is driving the I/O flow (calling mbedtls_ssl_read triggers the receive callback). This is an inversion from lori's model where the application pushes data in. The impedance mismatch is manageable but adds complexity.

Effort estimate. Medium to large. Rewriting the ssl library internals for mbedTLS's callback model (where the callee must perform data transfer) requires more careful FFI plumbing than rustls's callback model (where the callee just reads/writes library-owned buffers). Build integration is simpler since mbedTLS is plain C.

Risk factors. The FFI callback model is the main technical risk. Pony's FFI system can create C-callable function pointers, but managing the context pointer and ensuring memory safety across the FFI boundary during callbacks requires careful implementation. The threading constraints need validation against Pony's scheduler. Lack of FIPS certification may matter for some users.

---

Approach 4: Switch to s2n-tls

What it is. Replace OpenSSL with Amazon's s2n-tls, a TLS implementation focused on simplicity and security. s2n-tls is designed as a minimal TLS library that delegates cryptographic operations to a separate libcrypto (OpenSSL's libcrypto, AWS-LC, or LibreSSL).

How it would work with lori. S2n-tls supports custom send/receive callbacks via s2n_connection_set_recv_cb() and s2n_connection_set_send_cb(), with opaque context pointers set via s2n_connection_set_recv_ctx() / s2n_connection_set_send_ctx(). The callback model is similar to mbedTLS: the interceptor would buffer wire data, and when s2n reads, its receive callback pulls from that buffer. The send callback captures ciphertext for delivery to WireSender. Both callbacks must be implemented even for unidirectional use, since TLS control messages flow in both directions.

What changes. In ponylang/ssl: rewrite internals to wrap s2n-tls. The API is smaller and more stable than OpenSSL's (single header file, s2n.h, with opaque struct pointers). In lori: similar interceptor changes as with mbedTLS, adapting to the callback model.

Advantages.

• Designed for simplicity and security. Single header file. Stable API and ABI within major versions.
• FIPS 140-3 capable when paired with AWS-LC (Certificate #4698). AWS-LC was the first cryptographic library to include ML-KEM in FIPS 140-3 validation.
• Post-quantum hybrid key exchange (X25519MLKEM768, SecP256r1MLKEM768) via AWS-LC.
• No internal locks or mutexes -- APIs are not thread-safe unless documented, but this matches Pony's model where each connection lives in one actor.
• Apache 2.0 license.
• Battle-tested: handles 100% of Amazon S3's TLS traffic since 2017.
• TLS 1.0 through 1.3. ALPN, SNI, client certificates.
• Actively maintained with frequent commits.

Disadvantages.

• Requires a libcrypto dependency (OpenSSL's libcrypto, AWS-LC, or LibreSSL). This means you are not eliminating the OpenSSL dependency chain entirely -- you are replacing OpenSSL's TLS layer while keeping (or substituting) its crypto layer. AWS-LC is the recommended pairing, but it is a large C/C++ library with its own build complexity.
• Requires global initialization (s2n_init()) before use. Requires s2n_cleanup() per thread and globally. Known to interact with other libraries that have their own global init. This is the same kind of global state concern as OpenSSL.
• Per-thread state exists for random number generation. Thread-local memory must be cleaned up via s2n_cleanup() per thread. This requires understanding of how Pony's scheduler manages threads.
• Callback-based I/O model has the same impedance mismatch as mbedTLS (the library assumes it drives I/O flow via callbacks).
• Platform support is Linux-primary. macOS, FreeBSD, OpenBSD, and Windows (added 2025) are supported but Linux is the development focus. Post-quantum cipher suites are currently Linux-only.
• Build system uses CMake. Not as simple as mbedTLS's self-contained build due to the libcrypto dependency.

Effort estimate. Medium to large. Similar to mbedTLS in implementation complexity (callback-based I/O model). The additional complexity of managing a libcrypto dependency and per-thread cleanup adds to the effort.

Risk factors. The per-thread state and global initialization are concerns for Pony's scheduler, which manages its own thread pool. Thread-local cleanup must happen on each scheduler thread, which is not straightforward to arrange in Pony. The libcrypto dependency means the build complexity is not reduced as much as with mbedTLS. The Linux-primary focus could affect macOS and Windows users.

---

Approach 5: Implement TLS Protocol in Pony, Use C Only for Crypto Primitives

What it is. Implement the TLS record layer, handshake state machine, and protocol logic in Pony, calling out to C only for cryptographic primitives (AES, SHA, RSA, ECDH, X25519, etc.). This is the approach taken by Erlang/OTP, Haskell's tls package, OCaml's ocaml-tls, and Zig's standard library.

How it would work with lori. A Pony TLS library would be a natural DataInterceptor: a class that implements the TLS state machine, accepts ciphertext bytes, produces plaintext bytes, and vice versa. No FFI callbacks, no memory BIOs, no OpenSSL state machine -- the TLS protocol is native Pony code. The interceptor's incoming() method would feed bytes into the Pony TLS state machine, which parses TLS records, performs handshake steps (calling C crypto primitives as needed), and delivers decrypted data to the IncomingDataReceiver. The outgoing() method would take plaintext, construct TLS records, encrypt them (via C crypto primitives), and push ciphertext to WireSender.

The crypto primitives would be the only FFI layer. These could come from OpenSSL's libcrypto, AWS-LC, or a standalone crypto library. The FFI surface would shrink from ~55 OpenSSL networking calls to a handful of crypto function calls (symmetric ciphers, hash functions, key exchange, signature verification).

What changes. A new Pony library implementing TLS 1.2 and 1.3 protocol logic:

• TLS record layer (parsing and constructing records)
• Handshake state machine (ClientHello, ServerHello, certificate exchange, key derivation, Finished)
• Certificate validation (X.509 parsing, chain verification, hostname matching)
• Key schedule and transcript hash computation
• Alert protocol
• ALPN negotiation
• SNI extension

The existing ponylang/ssl library could be retained for its crypto primitives (Digest, HashFn) or replaced with a thinner crypto-only FFI layer. Lori's interceptors would be rewritten to wrap the Pony TLS library instead of the SSL class.

Advantages.

• Eliminates the impedance mismatch between C TLS state machines and Pony's actor model. The TLS protocol becomes native Pony code that naturally respects reference capabilities and the actor execution model.
• The resulting DataInterceptor implementation would be simpler and more natural than wrapping any C library. No FFI callbacks, no buffer management across the FFI boundary, no need to coordinate C and Pony memory lifetimes for TLS state.
• No version branching. The protocol implementation is controlled entirely by the Pony codebase.
• No global initialization. No threading concerns beyond what Pony already handles.
• Drastically reduced FFI surface -- only crypto primitives, which have stable, simple APIs.
• Pony's type system and reference capabilities could enforce protocol invariants at compile time (similar to what OCaml achieves with its algebraic data types for handshake states).
• Cross-project precedent is strong: Erlang, Haskell, OCaml, Go, and Zig all implement TLS protocol logic in the host language. Erlang's OTP ssl module is the most directly relevant -- it uses the same actor model and delegates only crypto primitives to C via NIFs.
• OCaml's nqsb-TLS demonstrated that a pure-language implementation can have a trusted code base 25x smaller than an OpenSSL-based equivalent, with handshake performance matching OpenSSL and bulk throughput at 73-84%.
• The Haskell tls library was motivated by exactly the problem lori faces: C TLS libraries are "extremely stateful" and wrapping them from a language with different memory and concurrency models creates "IO mess to do essentially pure things."

Disadvantages.

• Largest implementation effort by a wide margin. TLS 1.3 alone is RFC 8446 (the protocol), plus RFC 5280 (X.509), RFC 6125 (hostname verification), and supporting RFCs. TLS 1.2 adds further complexity with its wider cipher suite negotiation and more complex handshake.
• Sustained maintenance burden. Cryptographic protocols require ongoing attention: new cipher suites, security advisories, protocol extensions. Go's crypto/tls has at least 5 named core maintainers (Valsorda, Shoemaker, McCarney, Murino, Neil), some full-time. Erlang's ssl module is maintained by the OTP team at Ericsson.
• Security risk during the maturation period. A new TLS implementation has not been battle-tested. OpenSSL, for all its complexity, has been subjected to enormous scrutiny. TLS implementation bugs can be subtle and catastrophic.
• FIPS certification, if ever needed, requires its own substantial investment. Go proved it is possible for a pure-language implementation but it was a major effort (Filippo Valsorda became the top committer to the entire Go repository primarily through FIPS 140 work).
• Pony's community and contributor base is small relative to Go, Erlang, or Haskell. The maintenance burden per person is higher.
• Performance of protocol logic is not a concern (it is dominated by crypto operations underneath), but the crypto primitives still require C FFI.
• A recent data point: Common Lisp's pure-tls (2025) implemented TLS 1.3 in a "short amount of time" with AI assistance, suggesting TLS 1.3 alone may be tractable. But TLS 1.3 only is not sufficient for general use unless all peers support it (picotls has this same limitation).

Effort estimate. Large. This is a multi-month project for an experienced developer, plus ongoing maintenance. Implementing TLS 1.3 alone is more tractable than TLS 1.2+1.3 together, since TLS 1.3 is a significantly cleaner protocol. A phased approach (TLS 1.3 first, TLS 1.2 later) is possible.

Risk factors. The primary risk is sustainability: can the Pony community maintain a TLS implementation long-term? Security bugs in a less-scrutinized implementation. Scope creep (TLS has many extensions, cipher suites, and edge cases). The effort may not be justified given Pony's community size unless there is a clear path to shared maintenance. Erlang's lesson about deadlock risk (the tls_sender split) is worth studying before designing the Pony implementation's concurrency model.

Discussion

The approaches form a clear spectrum from least to most ambitious:

Approach 1 (drop 0.9.0) is pure upside with near-zero risk. It should be done regardless of which other approach is pursued. The question is whether it goes far enough.

Approaches 2-4 (alternative C libraries) trade one set of FFI complexity for another. The key differentiator is the I/O model:

• Rustls-ffi has the best I/O model fit -- no socket ownership, maps directly to DataInterceptor. All three libraries (rustls-ffi, mbedTLS, s2n-tls) use callbacks for I/O, but the nature of those callbacks differs: rustls-ffi's read_tls/write_tls callbacks present a library-owned buffer that the caller reads from or writes to (borrow-and-report-consumed), while mbedTLS and s2n-tls callbacks expect the callee to perform the I/O operation itself (copy data in/out). Rustls-ffi also exposes rustls_connection_read() and rustls_connection_write() for plaintext, which are straightforward buffer-copy operations. The Rust toolchain dependency is the practical barrier.
• MbedTLS and s2n-tls use I/O callbacks where the callee is expected to perform actual data transfer. MbedTLS is self-contained (no external deps, plain C, trivially builds); s2n-tls requires a libcrypto and has global init / per-thread state concerns that are awkward for Pony's scheduler. MbedTLS is the stronger candidate of the two for Pony integration, though its lack of FIPS certification and early-stage post-quantum support are gaps.
• WolfSSL was considered but its GPLv2 license is problematic for ponylang projects. Commercial licensing exists but changes the relationship.

Approach 5 (Pony TLS) is the most architecturally clean but the most expensive. The cross-language precedent is strong -- Erlang, Haskell, OCaml, Go, and Zig all chose this path, each for reasons that apply equally to Pony (actor model impedance mismatch, memory model conflicts, desire for transport-agnostic TLS). The question is whether the Pony community can sustain the maintenance.

Key questions that would drive the decision:

1. How much does the Rust toolchain dependency matter? If the answer is "not much" (e.g., prebuilt static libraries are distributed, or the build system handles it), rustls-ffi is the strongest short-to-medium term option. If it is a dealbreaker, mbedTLS is the next best C library option.

2. Is there appetite for a longer-term investment in a Pony TLS library? The architectural benefits are real and every comparable language ecosystem has eventually gone this direction. But the maintenance commitment is significant. A phased approach (TLS 1.3 first, using C crypto primitives) could reduce the initial scope.

3. What is the minimum acceptable scope? If only TLS 1.3 is required (all target peers support it), the implementation effort for approaches 2-5 is significantly reduced. TLS 1.2 support roughly doubles the complexity due to its more complex handshake and wider cipher negotiation.

4. How important is FIPS compliance? This eliminates mbedTLS and BearSSL, favors rustls (via aws-lc), s2n-tls (via AWS-LC), or staying with OpenSSL. A pure Pony implementation could achieve FIPS but at significant certification cost.

5. Should approach 1 be done immediately as a standalone improvement? Dropping 0.9.0 support is valuable regardless of the long-term direction and has no downside.

[SeanTAllen]

Direction A (SSL as a first-class TCPConnection concern) was implemented:

• PR Add _on_send_failed and _on_start_failure lifecycle callbacks #159 — Added _on_send_failed and _on_start_failure lifecycle callbacks
• PR Make SSL a first-class TCPConnection concern #160 — Added ssl_client/ssl_server constructors, removed DataInterceptor infrastructure

Protocol transformations (Direction B / composable protocol layers) remains an open area for future research if real use cases emerge.