TLS in einer mit Delphi oder C++Builder erstellten iOS- oder macOS-App auszuliefern bedeutete bisher, OpenSSL mitzuliefern: eine libssl.dylib und eine libcrypto.dylib, mit der App gebündelt, von Ihnen versionsabgeglichen und gepatcht. sgcWebSockets beseitigt diese Anforderung. Ein neues natives TLS-Backend, iohAppleTLS, nutzt Apples eigenes TLS, sodass Ihre App sicher verbindet, ohne auszuliefernde OpenSSL-.dylib. Es ist in der Enterprise-Edition verfügbar.
Noch besser: Auf modernen Systemen erhalten Sie damit TLS 1.3. Das Backend wählt automatisch die beste System-API für das Gerät, alles hinter einer einzigen Einstellung, sodass Sie nicht nach OS-Version verzweigen und Ihr Code überall gleich bleibt.
Eine Zeile zum Umschalten
Das TLS-Backend wird über TLSOptions.IOHandler ausgewählt. Um Apples natives TLS zu verwenden, setzen Sie es auf iohAppleTLS. Der Rest Ihres Netzwerk-Codes ändert sich nicht.
uses
sgcWebSocket, sgcWebSocket_Types;
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAppleTLS;
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;Auf anderen Plattformen behalten Sie das passende Backend: iohOpenSSL funktioniert überall, iohSChannel ist nativ unter Windows, und iohAndroidTLS ist die native Option ohne Auslieferung unter Android. Eine kleine Bedingung hält eine Client-Komponente auf jedem Ziel korrekt.
WSClient.TLS := True;
{$IF Defined(IOS) or Defined(MACOS)}
WSClient.TLSOptions.IOHandler := iohAppleTLS; // native, no OpenSSL .dylib
{$ELSEIF Defined(ANDROID)}
WSClient.TLSOptions.IOHandler := iohAndroidTLS; // native, no OpenSSL .so
{$ELSEIF Defined(MSWINDOWS)}
WSClient.TLSOptions.IOHandler := iohSChannel; // native on Windows
{$ELSE}
WSClient.TLSOptions.IOHandler := iohOpenSSL; // OpenSSL elsewhere
{$ENDIF}
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;Keine OpenSSL-.dylib auszuliefern
Mit dem nativen Backend gibt es kein OpenSSL zu bündeln, versionsabzugleichen oder zu patchen. Der TLS-Stack wird mit dem Betriebssystem ausgeliefert, sodass die App schlanker und frei von einer Krypto-Abhängigkeit eines Drittanbieters ist. Für App-Store-Einreichungen bedeutet das auch eine native Bibliothek weniger zu begründen, und Ihre TLS-Richtlinie folgt der von Apple statt einem Bibliotheks-Build, den Sie vor Monaten eingefroren haben. Sicherheitskorrekturen kommen über OS-Updates.
TLS 1.3 mit automatischem Fallback
Die einzelne Einstellung iohAppleTLS wählt die richtige System-API je Gerät. Unter macOS 10.14+ und iOS 12+ nutzt sie Network.framework, das TLS 1.3 mitbringt. Auf älteren Systemen fällt sie auf Secure Transport zurück, das bei TLS 1.2 endet. Sie schreiben keinerlei Versionsprüfungen, das Backend wählt den Pfad und Ihr Code ist auf beiden identisch.
Ein vollständiger TLS-Client
Dies ist ein vollständiger Client, kein abgespeckter. Er nutzt den System-Trust-Store, führt SNI und Hostnamen-Verifizierung durch und stellt einen OnAppleTLSVerifyPeer-Callback bereit, sodass Sie das Zertifikat selbst prüfen und annehmen oder ablehnen können. Sie können einer privaten Stelle mit einer eigenen CA-Wurzel über RootCertFile vertrauen, ein Client-Zertifikat für gegenseitiges TLS mit CertFile und Password vorlegen und Anwendungsprotokolle wie http/1.1 über ALPN ankündigen.
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAppleTLS;
WSClient.TLSOptions.VerifyCertificate := True;
WSClient.TLSOptions.ALPNProtocols.Add('http/1.1');
WSClient.TLSOptions.RootCertFile := ''; // optional custom CA (PEM/DER)
WSClient.TLSOptions.CertFile := ''; // optional client cert (PKCS#12) for mTLS
WSClient.TLSOptions.Password := ''; // client cert password
WSClient.OnAppleTLSVerifyPeer := DoVerifyPeer; // optional custom validation
WSClient.Host := 'your.server.com';
WSClient.Port := 443;
WSClient.Active := True;Der Verify-Peer-Callback gibt Ihnen den Zertifikats-Subject und seinen SHA-256-Fingerabdruck, das Ergebnis der Trust-Auswertung und ein Accept-Flag, das Sie setzen, um die Verbindung zuzulassen oder zu blockieren. Es ist die natürliche Stelle, um ein Zertifikat zu pinnen oder Ihre eigene Richtlinie zusätzlich zur System-Trust-Entscheidung anzuwenden.
Funktioniert mit den Komponenten, die Sie bereits nutzen
Das Backend sitzt hinter den gemeinsamen TLSOptions, ist also nicht auf den WebSocket-Client beschränkt. Die TCP- und HTTP/2-Clients und die anderen Komponenten, die TLSOptions bereitstellen, wählen es auf dieselbe Weise. Wenn Ihr Code TLSOptions bereits konfiguriert, ist das Aktivieren von nativem Apple-TLS eine einzige Zuweisung, ohne Änderung daran, wie Sie verbinden oder Daten austauschen.
Dieselbe Idee unter Android
Wenn Sie auch Android anvisieren, erledigt das begleitende iohAndroidTLS-Backend dort dieselbe Aufgabe: Es nutzt Androids eigenes TLS über die Plattform-SSLEngine, ohne auszuliefernde OpenSSL-.so. Das Muster ist identisch, Sie wählen den nativen Handler je Plattform. Die Details finden Sie auf der Seite Natives Android-TLS.
Verfügbarkeit
Natives Apple-TLS (iohAppleTLS) ist in der Enterprise-Edition von sgcWebSockets enthalten. Für die vollständige Aufschlüsselung der vier TLS-Backends, OpenSSL auf jeder Plattform, SChannel unter Windows sowie die nativen Android- und Apple-Handler, sehen Sie den Abschnitt SSL / TLS und die Seite Natives Apple-TLS.
Laden Sie es von der sgcWebSockets-Download-Seite herunter oder beziehen Sie es über GetIt oder Ihr registriertes Konto.
Fragen, Feedback oder Hilfe beim Umzug einer iOS- oder macOS-App weg von OpenSSL? Kontaktieren Sie uns, Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.