Short answer: you get OpenSSL-verified wire compatibility with none of OpenSSL's deployment, binding and patching burden. StreamSec Tools is native Object Pascal compiled into your application - so you can read, debug and ship it in a single executable.

1. IT COMPILES INTO YOUR EXECUTABLE

Linking OpenSSL means shipping and versioning libssl / libcrypto DLLs: installer weight, DLL conflicts when another product puts a different OpenSSL on the machine, and the obligation to redeploy binaries every time an OpenSSL CVE lands - whether or not it touches a code path you use. StreamSec is compiled straight into the EXE: single-file deployment, the version pinned at build time, and your patch story is "rebuild," not "chase DLLs across customer installs."

2. NO BINDINGS LAYER

Calling OpenSSL from Delphi means maintaining a C-header translation layer against an API that has churned hard - 1.0, 1.1 and 3.x each broke bindings, and the Delphi ecosystem's wrappers trailed those transitions by years. A native implementation has no FFI boundary at all: palette components, design-time configuration, events, refcounted key containers, and a handshake you can single-step in the IDE debugger - which you cannot do through a C DLL.

3. ONE COHERENT STACK, NOT GLUE

TLS is rarely the whole need. The same native library covers TLS, X.509 path validation and certificate generation, CMS, PKCS#8/#12 and OCSP (client, responder and stapling), and SSH and SFTP - one API style, one vendor, one audit surface. The OpenSSL route usually becomes OpenSSL plus additional libraries plus custom glue.

4. CURRENT, PROVEN BY INTEROP

This is not a legacy-only trade-off. The stack does TLS 1.3 with post-handshake KeyUpdate (RFC 9846), 0-RTT, HelloRetryRequest, mutual TLS, session resumption, OCSP stapling on 1.2 and 1.3, and ChaCha20-Poly1305. On post-quantum it implements ML-KEM and the RFC 9954 hybrid groups (X25519MLKEM768 and the SecP variants), plus ML-DSA and EdDSA in CertificateVerify - each interop-tested against OpenSSL itself, so you get OpenSSL compatibility without carrying the C dependency.

5. AUDITABILITY AND SUPPLY CHAIN

Full source, in the language your team already reads, built by your own compiler from your own project. No prebuilt C binaries in the trust chain, and the shipped code is only what your linker pulled in - not a multi-megabyte general-purpose library of which you use a fraction.

6. HARD TO MISCONFIGURE

Many TLS failures in the field are configuration mistakes, not broken cryptography - and several of the classic ones are OpenSSL footguns that StreamSec's design makes hard to reach by accident:

• There is no "verify off" switch: trust validation is inseparable from importing the peer chain, so a client with no configured trust anchor cannot silently connect unverified - it fails the handshake. (An empty OpenSSL trust store with the default settings connects anyway.)
• A verification failure aborts the handshake in-band - you never get a completed-but-unverified connection whose result you must remember to check.
• The operating-system trust store is not silently inherited, so a corporate-proxy or admin-injected root is not trusted by default.
• A certificate that is not a CA cannot sign another certificate - basicConstraints and key usage are enforced.

More on this: Secure by construction.

WHERE OPENSSL IS THE RIGHT CALL

• If a customer contractually requires a FIPS 140-validated module, use OpenSSL's FIPS provider or Windows CNG.
• OpenSSL has more review hours than any crypto library in history. The honest counter is that StreamSec's far smaller, single-language surface is practically auditable by you, and its correctness is continuously checked against OpenSSL as the reference.
• If the organisation's policy is "everything links OpenSSL," that is rarely worth fighting.

See also StreamSec vs Windows Schannel, or return to the Why StreamSec overview.