OpenSSL (iohOpenSSL) ist der plattformübergreifende TLS-Transport für sgcWebSockets. Er läuft auf jeder Plattform, die die Bibliothek unterstützt, und ist auf den meisten der Standard, mit der breitesten Protokoll- und Cipher-Abdeckung aller Backends. Aktiviere ihn, indem du TLSOptions.IOHandler auf iohOpenSSL setzt, und liefere dann die OpenSSL-Laufzeitbibliotheken neben deiner Anwendung aus.
Plattformübergreifendes TLS, umgesetzt über Indys Socket, verfügbar auf jeder Plattform, die sgcWebSockets unterstützt.
OpenSSL ist die plattformübergreifende TLS-Implementierung, die sgcWebSockets über Indys Socket legt. Sie ist auf Windows, Linux, macOS, iOS und Android verfügbar und auf den meisten davon das Standard-Backend. Wähle OpenSSL, wenn du auf jeder Plattform identisches TLS-Verhalten brauchst oder wenn du von einer Fähigkeit abhängst, die nur OpenSSL bereitstellt.
Das Backend deckt TLS 1.0 bis TLS 1.3 mit der breitesten Cipher-Suite-Auswahl aller sgcWebSockets-Transporte ab. Du kannst einer privaten oder selbstsignierten Zertifizierungsstelle mit einer eigenen CA-Root (RootCertFile) vertrauen, ein Client-Zertifikat für wechselseitiges TLS vorlegen und Anwendungsprotokolle wie http/1.1 über ALPN ankündigen. Da sich alle vier Backends dieselbe TLSOptions-API teilen, lässt sich gegen OpenSSL geschriebener Code auf ein natives Backend übertragen, indem nur die IOHandler-Zeile geändert wird.
Der Kompromiss ist die Auslieferung. OpenSSL ist eine externe Abhängigkeit, also lieferst du seine Laufzeitbibliotheken mit deiner Anwendung aus und hältst sie gepatcht. Unter Windows bedeutet das libssl-3.dll und libcrypto-3.dll, unter Linux und Android die passenden .so-Dateien und auf Apple-Plattformen die .dylib-Dateien. Wenn du natives TLS ohne auszuliefernde Bibliotheken willst, sieh dir SChannel unter Windows oder die nativen Android- und Apple-Backends an, oder bleibe bei OpenSSL und binde es stattdessen statisch in deine Windows-Anwendung ein, siehe unten.
Setze TLSOptions.IOHandler auf iohOpenSSL und liefere dann die OpenSSL-Bibliotheken mit deinem Build aus.
uses
sgcWebSocket, sgcWebSocket_Types;
// ...
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohOpenSSL;
WSClient.TLSOptions.VerifyCertificate := True;
WSClient.TLSOptions.RootCertFile := ''; // optional custom CA (PEM/DER)
WSClient.TLSOptions.CertFile := ''; // optional client cert for mTLS
WSClient.TLSOptions.Password := '';
WSClient.TLSOptions.ALPNProtocols.Add('http/1.1');
WSClient.Host := 'your.server.com';
WSClient.Port := 443;
WSClient.Active := True;WSClient->TLS = true;
WSClient->TLSOptions->IOHandler = iohOpenSSL;
WSClient->TLSOptions->VerifyCertificate = true;
WSClient->TLSOptions->RootCertFile = ""; // optional custom CA (PEM/DER)
WSClient->TLSOptions->CertFile = ""; // optional client cert for mTLS
WSClient->TLSOptions->Password = "";
WSClient->TLSOptions->ALPNProtocols->Add("http/1.1");
WSClient->Host = "your.server.com";
WSClient->Port = 443;
WSClient->Active = true;OpenSSL ist eine externe Abhängigkeit, daher reisen die Laufzeitbibliotheken auf jeder Plattform mit deiner Anwendung mit.
Liefere libssl-3.dll und libcrypto-3.dll neben deiner ausführbaren Datei aus (den 32-Bit- oder 64-Bit-Build passend zu deinem Ziel), oder verzichte ganz auf die DLLs, indem du OpenSSL statisch einbindest, siehe unten.
Bündle die passenden libssl- und libcrypto-.so-Dateien und lade sie dann aus einem Pfad, den deine Anwendung zur Laufzeit erreichen kann.
Liefere die libssl- und libcrypto-.dylib-Dateien mit dem App-Bundle aus, damit die OpenSSL-Laufzeit auf dem Gerät verfügbar ist.
Da du die Bibliotheken selbst auslieferst, bist du dafür verantwortlich, sie zu aktualisieren, sobald ein Sicherheitsfix erscheint.
Unter Windows lässt sich OpenSSL direkt in deine .exe einbinden, anstatt zur Laufzeit aus libssl-3.dll und libcrypto-3.dll geladen zu werden.
Füge die Unit sgcIdSSLOpenSSL_Static zur uses-Klausel deines Projekts hinzu, mehr ist nicht einzurichten: keine Compiler-Direktive zu aktivieren, keine OpenSSL-API-Version zu wählen. Deine Anwendung nutzt die in die ausführbare Datei eingebundene OpenSSL-Bibliothek ab dem nächsten Start, sowohl für Client- als auch für Server-Komponenten, in 32-Bit- und 64-Bit-Builds. Entfernst du die Unit wieder aus der uses-Klausel, lädt deine Anwendung die OpenSSL-DLLs wieder genau wie zuvor.
uses
sgcWebSocket, sgcWebSocket_Classes,
sgcIdSSLOpenSSL_Static;Die aktuell eingebundene OpenSSL-Version ist 3.5.7, sie wird mit künftigen Updates aktualisiert, sodass du OpenSSL-Binärdateien nicht selbst verfolgen oder erneut ausliefern musst. Die statische Verknüpfung erfordert Delphi XE2 oder neuer sowie die benutzerdefinierte Indy-Bibliothek (in diesen Editionen der Standard); auf älteren Delphi-Versionen kompiliert die Unit zu nichts, und deine Anwendung lädt weiterhin wie gewohnt die OpenSSL-DLLs.
OpenSSL (iohOpenSSL) ist in jeder Edition von sgcWebSockets enthalten. Siehe die Feature-Matrix für die vollständige Aufschlüsselung.
Die statische Verknüpfung unter Windows erfordert Delphi XE2 oder neuer und ist in den Editionen Enterprise und All-Access verfügbar.