Most TLS incidents in the field are not broken cryptography - they are configuration mistakes: verification left off, the wrong trust anchor, a certificate accepted for the wrong host. StreamSec Tools is designed so the common mistakes are hard, or impossible, to make by accident. Verification and trust are not options you switch on; they are built into the one code path a certificate can travel.

YOU CANNOT CONNECT WITHOUT VERIFYING

A peer certificate reaches the engine through a single path, and it is accepted only if it validates to a trusted anchor. There is no "verify off" property to forget. A client with no configured trust anchor does not connect insecurely - it fails the handshake with an unknown_ca alert. And a verification failure aborts the handshake there and then; you never receive a finished-but-unverified connection whose result you have to remember to inspect.

The verification hooks work the safe way round, too: with no handler installed the outcome is deny. The events exist only to relax a decision that already failed - so forgetting to handle one refuses the certificate rather than silently accepting it. (In a C library whose verify callback returns "1" for success, a single stray line can turn every error into acceptance.)

THE OS TRUST STORE IS NOT SILENTLY INHERITED

Your trust anchors are an explicit, application-controlled set. StreamSec does not automatically trust whatever roots happen to live in the Windows certificate store, so a root that a corporate MITM proxy or a machine administrator injected there is not trusted by default. Using the Windows store is a deliberate choice, not the fallback. The reverse is just as easy: pin a single certificate, run a private PKI, or refuse a public root you do not want - the trust model is yours.

A NON-CA CERTIFICATE CANNOT SIGN ONE

Path validation enforces the chain rules by default: to act as an issuer, a certificate must be marked as a CA (basicConstraints) and carry the key usage that permits signing, within the path-length and name constraints its issuers set. The old "any valid leaf certificate can be used as an intermediate" confusion does not arise.

SECURE RENEGOTIATION ONLY

Renegotiation is cryptographically bound to the original handshake (RFC 5746), with no switch to allow the legacy, insecure form - so the renegotiation prefix-injection attack (CVE-2009-3555) is refused by design rather than left to configuration.

WHOLE CLASSES OF C VULNERABILITIES DO NOT APPLY

StreamSec Tools is native Object Pascal with no OpenSSL underneath, which removes several bug families by construction rather than by patching:

• No heartbeat extension exists - the code path behind Heartbleed (CVE-2014-0160) is simply not present.
• Length-bounded DER parsing - the ASN.1 decoder checks every offset and length against the buffer before reading, and rejects malformed encodings, avoiding the pointer-arithmetic parser bugs behind a long line of ASN.1 CVEs.
• Public and private keys are different types - signing needs a private key and verifying needs a public key, so mixing them up does not compile; keys are managed objects, not raw exportable blobs.
• No global initialisation or thread-locking callbacks to register - the pre-1.1.0 OpenSSL requirement that crashed applications which got it wrong has no equivalent here.

SAFE DEFAULTS OUT OF THE BOX

Where behaviour is a default rather than a structural guarantee, the default is the safe one: server-identity (hostname) checking is on, the shipped profile prefers AEAD cipher suites with forward secrecy and disables RC4, anonymous suites and SSL 3.0 / TLS 1.0 / 1.1, TLS compression is off (CRIME) and 0-RTT is off. You get a modern, safe configuration without composing a cipher string.

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