OpenSSL oder native Kryptographie in Delphi: zur Laufzeit wählen

Die OpenSSL-DLLs aus einer Delphi-Anwendung zu entfernen war früher eine Build-Entscheidung. Man aktivierte ein Compiler-Define, baute neu und lieferte eine zweite ausführbare Datei an die Kunden aus, die kein OpenSSL auf ihren Rechnern haben durften. sgcWebSockets 2026.10 macht daraus eine Laufzeitentscheidung: eine einzige globale Variable, einmal beim Start gesetzt, entscheidet, ob die Anwendungskryptographie auf OpenSSL läuft oder auf der in die Bibliothek eingebauten, in Object Pascal geschriebenen Kryptographie.

Die Verbindungsseite, TLS ohne OpenSSL, wird in Delphi TLS 1.3 ohne OpenSSL-DLLs behandelt. Dieser Beitrag handelt von allem anderen: den Signaturen, Hashes, dem Schlüsselaustausch und der Verschlüsselung, die Ihre Anwendung außerhalb des TLS-Handshakes durchführt.

Eine Zeile beim Start

Die Unit sgcBase_Helpers deklariert die globale Variable sgcCryptoBackend vom Typ TsgcCryptoBackend:

uses
  sgcBase_Helpers;

begin
  sgcCryptoBackend := cbNative;
  sgcCheckNativeCrypto;
  Application.Initialize;
  ...

Der Schalter ist global, nicht pro Komponente, setzen Sie ihn also, bevor eine Komponente erstellt wird. sgcCheckNativeCrypto ist optional: Sind die nativen Krypto-Units nicht mit einkompiliert, löst er beim Start eine klare Meldung aus, statt bei der ersten Signatur, die Ihre Anwendung erstellen will.

Drei Werte

• cbOpenSSL ist die Vorgabe. Die Anwendungskryptographie läuft auf OpenSSL, genau wie in früheren Versionen, sodass ein Upgrade nichts ändert, bis Sie die Variable setzen.
• cbNative lässt die Anwendungskryptographie auf der Object-Pascal-Implementierung laufen. OpenSSL wird dafür nie geladen.
• cbAuto verwendet OpenSSL, wenn dessen Bibliotheken geladen werden können, und den nativen Code, wenn nicht. Die Prüfung läuft einmal, und das Ergebnis wird zwischengespeichert.

cbAuto ist die richtige Wahl für Produkte, die auf beide Arten ausgeliefert werden. Manche Kunden installieren die OpenSSL-Bibliotheken neben der ausführbaren Datei, manchen ist das nicht erlaubt, und derselbe Build funktioniert für beide, ohne ein Support-Ticket wegen einer fehlenden DLL.

// same executable, with or without the OpenSSL libraries beside it
sgcCryptoBackend := cbAuto;

Was dem Schalter folgt

Der Schalter deckt die Kryptographie ab, die die Komponenten für Sie erledigen:

• die Hashing- und HMAC-Hilfsfunktionen;
• JWT-Signierung und -Verifizierung, HS, RS und ES;
• OAuth2- und DPoP-Proofs;
• AWS Signature V4 und signierte CloudFront-URLs;
• Web Push;
• Ende-zu-Ende-Verschlüsselung (E2EE), bei der Peers mit unterschiedlichen Backends zusammenarbeiten, sodass ein Client mit cbNative mit einem Server spricht, der noch auf OpenSSL läuft;
• WebAuthn und Passkeys;
• SAML und XML-Signaturen;
• NTLM;
• AEAD, ML-KEM und HKDF;
• QUIC-Paketschutz, die DTLS- und WebRTC-Zertifikate und SRTP.

Keiner dieser Bereiche erfordert eine Codeänderung. Ein JWT, das gestern mit OpenSSL signiert wurde, wird heute nativ signiert, weil die Variable es so vorgibt.

Die Verbindungen sind eine eigene Einstellung

sgcCryptoBackend ändert nicht, wie eine Komponente sich verbindet. Das TLS einer Verbindung wird pro Komponente gewählt, mit IOHandler = iohNativeTLS, bei den TCP-, HTTP- und WebSocket-Komponenten und allem, was darauf aufbaut, wie MQTT, bei QUIC und HTTP/3, und bei DTLSOptions für WebRTC:

sgcCryptoBackend := cbNative;                  // application crypto
oClient.TLSOptions.IOHandler := iohNativeTLS;  // this connection

Eine Komponente, die beim OpenSSL-Handler bleibt, lädt beim Verbinden weiterhin OpenSSL. Mit iohNativeTLS bei QUIC, HTTP/3 und DTLS wird überhaupt kein OpenSSL verwendet, unabhängig davon, was der Schalter sagt. Eine Anwendung, die nirgends OpenSSL haben möchte, setzt beides: den Schalter für ihre Kryptographie und den Handler bei jeder Komponente, die eine sichere Verbindung öffnet.

Das Define ist jetzt optional

Bisher bedeutete der Betrieb ohne OpenSSL das Compiler-Define SGC_NATIVE_CRYPTO. Es wird nicht mehr benötigt. Ohne es werden sowohl der OpenSSL- als auch der native Code einkompiliert, und die Variable entscheidet zur Laufzeit.

Das Define hat noch einen Nutzen. Es erzwingt das native Backend, egal was sgcCryptoBackend sagt, und entfernt den OpenSSL-Code aus den Anwendungs-Krypto-Units, sodass die ausführbare Datei kleiner wird. Wenn Sie wissen, dass ein Build nie OpenSSL verwenden wird, ist es weiterhin die richtige Wahl. Wenn Sie es noch nicht wissen, lassen Sie es aus und entscheiden Sie beim Start.

Warum das wichtig ist

• Ein einziger Build. Kunden, die ohne OpenSSL ausliefern müssen, sei es wegen Lizenzierung, eines Sicherheitsaudits, das nach jeder Drittanbieter-Binärdatei fragt, oder gesperrter Rechner, auf denen niemand eine DLL kopieren darf, erhalten dieselbe ausführbare Datei wie alle anderen.
• Ein Fallback. cbAuto hält eine Anwendung funktionsfähig, wenn die OpenSSL-Bibliotheken fehlen, statt bei der ersten Signatur zu scheitern.
• Mobil. Unter iOS und Android gibt es kein OpenSSL, das man für die Anwendungskryptographie bündeln könnte.
• Überall derselbe Code. Der Schalter funktioniert gleich unter Windows, Linux, macOS, iOS und Android, mit Delphi 7 bis Delphi 13 und C++Builder.

Aktualisierung

Nichts ändert sich, bis Sie die Variable setzen, weil cbOpenSSL die Vorgabe ist. Um das native Backend auszuprobieren, fügen Sie die beiden obigen Zeilen zu Ihrer Projektdatei hinzu, führen Sie Ihre Tests aus und vergleichen Sie. Die vollständige Liste dessen, was dem Schalter folgt, und welche Einstellung jeder Bereich für null OpenSSL zur Laufzeit benötigt, finden Sie im Hilfethema Betrieb ohne OpenSSL.

Weiterlesen

• Delphi TLS 1.3 ohne OpenSSL-DLLs, die Verbindungsseite

Fragen, Feedback oder Hilfe bei der Migration? Kontaktieren Sie uns. Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.