TLS-Stack für FreePascal und Delphi

OpenSSL wird überflüssig: TlsLib4Pascal ist eine neue Biblio­thek für TLS (Nach­folger von SSL), die einen voll­ständig ver­walte­ten TLS 1.2 und 1.3 Stack bereit­stellt.

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

Licence: MIT, © 2026 Ugochukwu Mmaduekwe

Die Bibliothek implementiert TLS 1.2 und TLS 1.3 von Grund auf neu, ohne dabei OpenSSL oder eine TLS-Engine des Betriebs­systems wie SChannel (Windows Secure Channel) zu ver­wenden. Der Code ist reines Object Pascal und läuft da­durch gleicher­maßen unter Windows, Linux, macOS und den BSDs.

Kryptografie: Als einzige Abhängig­keit wird ↗CryptoLib­4Pascal ge­nutzt, das die eigent­lichen kryptogra­fi­schen Primitive liefert. Das Krypto-Backend ist über eine ICryptoProvider-Schnitt­stelle aus­tausch­bar, so dass Entwick­ler bei Bedarf ein ande­res Backend ein­setzen können.

Architektur: Den Kern bildet eine Sans-IO-Engine, die keine Sockets, Threads oder Timer be­sitzt. Darauf setzen drei Integra­tions­ebenen auf: Ebene 1 ist eine ein­fache Fassade namens TTlsLib. Ebene 2 ist TTlsStream, ein Standard-TStream, der TLS über eine Transport-Schnitt­stelle mit nur zwei Metho­den spricht. Und Ebene 3 liefert ferti­ge Adapter für mORMot, Indy, Synapse und fcl-net. Jeder Adapter klinkt sich in die eigene SSL-Naht­stelle des je­weili­gen Stacks ein, so dass be­stehen­der Code oft nur eine neue uses-Klausel be­nötigt.

Protokoll-Merkmale: TLS 1.3 ver­wendet aus­schließ­lich AEAD-Cipher-Suites, während TLS 1.2 auf ein ge­härte­tes ECDHE- + AEAD-Profil be­schränkt bleibt. Schwache Optionen wie CBC-HMAC, RC4 und stati­scher RSA-Schlüssel­austausch sind be­wusst aus­geschlos­sen, und ein Post-Quanten-Hybrid-Schlüssel­austausch (↗X25519MLKEM768) ist standard­mäßig in jedem Preset akti­viert.

Trust and Verification: Die Biblio­thek führt eine voll­ständige PKIX-Pfad-Validie­rung durch, prüft Host­namen gegen die SANs des Zertifi­kats und unter­stützt so­wohl Certifi­cate Pinning als auch ge­stapel­tes oder Live-OCSP-/CRL-Widerruf. Das Ver­trauen auf das Betriebs­system (Zertifi­kats­speicher) lässt sich optio­nal als Paket hin­zufügen. Dabei arbei­tet die Biblio­thek fail-closed: sie schließt keinen Hand­shake ab, den sie nicht verifi­zie­ren kann.

Getestet wird die Bibliothek gegen die BoGo-Konformi­täts­suite von BoringSSL, die als ver­pflichten­des CI-Gate läuft, sowie gegen byte-exakte RFC-8448-Test­vektoren, eine OpenSSL-Inter­opera­bili­täts­matrix und struktur­bewuss­tes Fuzzing.

Anwendungsfälle: TlsLib4Pascal passt zu jedem Pascal-Projekt, das TLS ohne OpenSSL-Abhängig­keit be­nötigt. Typische Szenarien:

• HTTPS-Clients: Sobald die Adapter-Unit TlsLibFclNetTls ein­gebun­den ist, kann der Standard TFpHttpClient (fcl-web) HTTP GET und POST-Anfragen über TLS durch­führen, ganz ohne Änderun­gen am eigent­lichen HTTP-Code.
• HTTPS-Server: TFpHttpServer unter­stützt TLS auf die gleiche Weise über seine Eigen­schaf­ten UseSSL und Certifi­cateData, was sich für kleine ein­gebettete Web­server, REST-APIs oder Admin-Oberflächen eignet.
• FTP/FTPS und andere TCP-Protokolle: Ein Foren­nutzer hat bereits erfolg­reich einen FTP-Client von OpenSSL auf TlsLib4Pascal um­gestellt. Grundsätz­lich kann jedes Protokoll, das auf Synapse-, Indy- oder fcl-net Sockets auf­baut, auf diese Weise TLS er­halten.
• mORMot-basierte Dienste: Eine ein­zeilige globale Registrie­rung (RegisterTlsLib4PascalTls) ge­nügt, um jede TCrtSocket-Verbin­dung in einer mORMot-Anwendung auf TlsLib4Pascal um­zustellen.
• Eigene Protokolle über Rohsockets: Wer eine eigene Socket-Schicht be­sitzt, kann TTlsStream direkt über eine kleine Transport-Schnitt­stelle an­steuern oder für asynchrone Event-Loop Frame­works gleich die rohe Sans-IO-Engine selbst treiben.

Eigener Server mit HTTPS

Zertifikat und privater Schlüssel: Die Biblio­thek er­zeugt selbst keine Zertifi­kate, sondern erwartet zwei PEM-kodierte Eingaben - eine Zertifi­kats­kette, leaf-first, also das eigene Server-Zertifi­kat, evtl. ge­folgt von Zwischen-Zertifika­ten, sowie einen dazu passen­den priva­ten Schlüssel, der un­verschlüs­selt oder mit einem separat über­gebe­nen Passwort ver­schlüs­selt sein kann.

Woher diese Dateien stammen, hängt von der je­weili­gen Bereit­stellung ab. Für öffent­liche Produktions­server empfiehlt sich ein Zertifi­kat einer öffent­lichen CA, meist kostenlos über ↗Let's Encrypt, wobei Tools wie Certbot oder win-acme fullchain.pem und privkey.pem direkt er­zeugen.

Interne oder Entwicklungs-Server kommen dagegen häufig mit einem selbst­signier­ten Zertifi­kat aus, das sich ein­malig mit einem beliebi­gen Standard­werkzeug er­stellen lässt, etwa dem openssl-req Befehl oder PowerShells New-SelfSignedCerti­ficate.
Ein solches Werkzeug wird dabei nur offline zur Er­zeugung der PEM-Dateien ge­nutzt und ist keine Lauf­zeit­abhängig­keit von TlsLib4Pascal selbst. Auch PKCS#12-/.pfx-Bundles werden unter­stützt, aller­dings nur über die native API TTlsPresets ... WithCredential­Pkcs12 der Biblio­thek und nicht über TFpHttpServer.Certifi­cateData, das separate PEM-Dateien er­wartet.

Eine Konsequenz selbst­signierter Zertifi­kate ist, dass die client­seitige PKIX-Validie­rung von TlsLib4Pascal sie standard­mäßig ab­lehnt, da keine öffent­liche CA dahinter­steht. Wer sich mit einem selbst-signier­ten Test­server ver­binden möchte, muss das Zertifi­kat daher ent­weder explizit als Trust Anchor hin­zufügen oder - nur für lokale Tests, niemals in Produk­tion - die Verifi­zie­rung voll­ständig über die klar ge­kenn­zeich­nete „dangerous" API-Ober­fläche um­gehen.