TLS stack for FreePascal

OpenSSL becomes unnecessary: TlsLib4Pascal is a new TLS library for Object Pascal. It provides a fully managed TLS 1.2 + TLS 1.3 stack.

↗https://github.com/Xor-el/TlsLib4Pascal

Licence: MIT © 2026 Ugochukwu Mmaduekwe

The library implements TLS 1.2 and TLS 1.3 from scratch. It does not use OpenSSL. It does not use any OS TLS engine like SChannel. The code is pure Object Pascal. It runs identically on Windows, Linux, macOS, and the BSDs.

Cryptography: The library uses CryptoLib4Pascal as its only dependency. This provides the actual cryptographic primitives. The crypto backend is pluggable through an ICryptoProvider interface. Developers can swap in a different backend if needed.

Protocol features: TLS 1.3 uses AEAD-only cipher suites. TLS 1.2 is restricted to a hardened ECDHE + AEAD profile. Weak options like CBC-HMAC, RC4, and static RSA key exchange are excluded by design. Post-quantum hybrid key exchange (X25519MLKEM768) is enabled by default in every preset.

Trust and verification: The library performs full PKIX path validation. It checks hostnames against certificate SANs. It supports certificate pinning. It supports both stapled and live OCSP/CRL revocation checks. OS system trust is available as an opt-in package. The library fails closed: it will not complete a handshake it cannot verify.

Architecture: The core is a sans-IO engine. It owns no sockets, threads, or timers. Three integration tiers sit on top of this core. Tier 1 is a simple facade called TTlsLib. Tier 2 is TTlsStream, a standard TStream that speaks TLS over a two-method transport interface. Tier 3 consists of drop-in adapters for mORMot, Indy, Synapse, and fcl-net. Each adapter plugs into that stack's own SSL seam, so existing code often needs only one new uses clause.

Testing: The library is tested against BoringSSL's BoGo conformance suite. This runs as a required CI gate. It is also tested against RFC 8448 byte-exact vectors, an OpenSSL interop matrix, and structure-aware fuzzing.

Use cases: TlsLib4Pascal fits any Object Pascal project that needs TLS without an OpenSSL dependency. Typical scenarios:

• HTTPS clients: Standard TFPHTTPClient (fcl-web) can do HTTP GET/POST over TLS once the TlsLibFclNetTls adapter unit is linked in. No code changes to the HTTP calls themselves are needed.
• HTTPS servers: TFPHTTPServer (fphttpserver) supports TLS the same way, through its UseSSL and CertificateData properties. This covers small embedded web servers, REST APIs, or admin interfaces.
• FTP/FTPS and other TCP protocols: One forum tester already switched an FTP client from OpenSSL to TlsLib4Pascal and reported success. Any protocol built on Synapse, Indy, or fcl-net sockets can gain TLS the same way.
• mORMot-based services: A one-line global registration (RegisterTlsLib4PascalTls) switches every TCrtSocket connection in a mORMot application to TlsLib4Pascal.
• Custom protocols over raw sockets: Developers who own their own socket layer can drive TTlsStream directly over a small transport interface, or drive the raw sans-IO engine for async/event-loop frameworks.
• Post-quantum-ready deployments: Because X25519MLKEM768 hybrid key exchange is on by default, this library is a straightforward way to add post-quantum protection to a Pascal application today, ahead of most other Pascal TLS options.
• Cross-platform deployment: Since the stack is pure Pascal with no OS or OpenSSL binding, the same code and the same TLS behavior run unchanged on Windows, Linux, macOS, and BSD builds — useful for teams shipping to multiple platforms from one Lazarus codebase.

Certificate and private key: The library does not generate certificates for you. It expects two PEM-encoded inputs: A certificate chain, leaf-first: your server's own certificate, followed by any intermediate certificates. And a private key, matching that leaf certificate. It can be unencrypted, or encrypted with a password supplied separately.

Where these files come from depends on the deployment: Public production servers should use a certificate from a public CA, most commonly free via Let's Encrypt (tools like Certbot or win-acme produce fullchain.pem and privkey.pem directly). Internal or development servers typically use a self-signed certificate, created once with any standard tool (OpenSSL's openssl req command, PowerShell's New-SelfSignedCertificate, or similar). This tool is only used offline to produce the PEM files — it is not a runtime dependency of TlsLib4Pascal itself. PKCS#12/.pfx bundles are also supported, but only through the library's native TTlsPresets ... WithCredentialPkcs12 API, not through TFPHTTPServer.CertificateData, which expects separate PEM files.

One consequence of self-signed certificates: TlsLib4Pascal's client-side PKIX validation will reject them by default, since no public CA backs them. Clients connecting to a self-signed test server must add that certificate as an explicit trust anchor, or — for local testing only, never in production — bypass verification entirely through the library's clearly marked "dangerous" API surface.