Eine sichere Android-App mit Delphi oder C++Builder auszuliefern, bedeutete bisher immer eine zusätzliche Pflichtaufgabe: libssl.so und libcrypto.so im APK mitzuliefern, damit OpenSSL zur Laufzeit vorhanden ist. sgcWebSockets nimmt Ihnen diese Pflicht ab. Ein neues natives TLS-Backend, iohAndroidTLS, übergibt die Verschlüsselung an Android selbst, sodass Ihre App über TLS verbindet, ohne dass OpenSSL-Bibliotheken auszuliefern sind. Es ist in der Enterprise-Edition verfügbar.
Im Hintergrund steuert das Backend die plattformeigene javax.net.ssl.SSLEngine über JNI an. Das Betriebssystem führt den Handshake, die Datensatzverschlüsselung und die Zertifikatsprüfung durch. sgcWebSockets gibt lediglich Klartext hinein und erhält Chiffretext zurück, was bedeutet, dass der gesamte TLS-Stack derjenige ist, den Google mit dem Betriebssystem ausliefert und patcht.
Eine Zeile zum Umschalten
Das TLS-Backend wird über TLSOptions.IOHandler ausgewählt. Um Androids natives TLS zu nutzen, setzen Sie es auf iohAndroidTLS. Alles andere in Ihrem Netzwerkcode bleibt gleich.
uses
sgcWebSocket, sgcWebSocket_Types;
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAndroidTLS;
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;Auf anderen Plattformen behalten Sie das jeweils passende Backend: iohOpenSSL funktioniert überall, und iohSChannel ist die native Option unter Windows, die nichts auszuliefern braucht. Eine kleine Bedingung hält eine einzige Client-Komponente auf jedem Ziel korrekt.
WSClient.TLS := True;
{$IFDEF ANDROID}
WSClient.TLSOptions.IOHandler := iohAndroidTLS; // native, no OpenSSL .so
{$ELSE}
{$IFDEF MSWINDOWS}
WSClient.TLSOptions.IOHandler := iohSChannel; // native on Windows
{$ELSE}
WSClient.TLSOptions.IOHandler := iohOpenSSL; // OpenSSL elsewhere
{$ENDIF}
{$ENDIF}
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;Kein OpenSSL im APK
Das ist der zentrale Vorteil. Mit dem nativen Backend trägt das APK weder libssl.so noch libcrypto.so. Das Paket ist kleiner, und Sie jagen nie wieder einer OpenSSL-Version hinterher, bauen nicht wegen eines Sicherheitshinweises neu und passen keinen Bibliotheks-Build an ein Gerät an. Die TLS-Implementierung liegt auf dem Gerät und wird von Android gepflegt, sodass Sicherheitskorrekturen über System-Updates statt über Ihren Release-Zyklus ankommen.
Es beseitigt außerdem eine ganze Klasse von Bereitstellungsproblemen. Es gibt kein „Bibliothek nicht gefunden“, keine Architektur-Diskrepanz zwischen der mitgelieferten .so und dem Gerät, und keine zweite Kopie der Kryptografie zum Auditieren. Sie setzen eine Eigenschaft und liefern aus.
Ein vollwertiger TLS-Client, kein abgespeckter
Das native Backend ist ein vollständiger Client. Es prüft den Server gegen den Android-System-Truststore und führt eine Hostnamen-Verifizierung durch, sodass Verbindungen zu öffentlichen Zertifizierungsstellen ohne zusätzliche Konfiguration funktionieren. Es verhandelt TLS 1.3 und unterstützt ALPN unter Android 10 (API 29) und neuer, womit Sie während des Handshakes Anwendungsprotokolle wie http/1.1 ankündigen können.
Da es hinter derselben TLSOptions-API wie jedes andere Backend liegt, funktionieren die vertrauten Eigenschaften weiter. VerifyCertificate schaltet die Peer-Validierung ein oder aus, RootCertFile vertraut einer privaten Stelle, CertFile und Password präsentieren ein Client-Zertifikat, und ALPNProtocols listet die zu verhandelnden Protokolle auf.
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAndroidTLS;
WSClient.TLSOptions.VerifyCertificate := True;
WSClient.TLSOptions.ALPNProtocols.Add('http/1.1'); // Android 10 (API 29)+
WSClient.Host := 'your.server.com';
WSClient.Port := 443;
WSClient.Active := True;Funktioniert mit den Komponenten, die Sie bereits nutzen
Das Backend ist in die gemeinsam genutzten TLSOptions eingebunden, daher ist es nicht auf den WebSocket-Client beschränkt. Die TCP- und HTTP/2-Clients sowie die anderen Komponenten, die TLSOptions bereitstellen, wählen es auf dieselbe Weise aus. Wenn Ihr Code bereits TLSOptions setzt, ist das Hinzufügen von nativem Android-TLS eine einzige Zuweisung, ohne Änderung daran, wie Sie die Verbindung öffnen, senden oder empfangen.
Dieselbe Idee auf Apple
Wenn Sie auch iOS oder macOS anvisieren, erledigt das dazugehörige iohAppleTLS-Backend dort dieselbe Aufgabe: Es nutzt Apples eigenes TLS, ohne eine OpenSSL-.dylib auszuliefern, und es erreicht TLS 1.3 über Network.framework. Das Muster ist identisch, Sie wählen lediglich den nativen Handler pro Plattform. Die Details lesen Sie auf der Seite Natives Apple-TLS.
Verfügbarkeit
Natives Android-TLS (iohAndroidTLS) wird in der Enterprise-Edition von sgcWebSockets ausgeliefert. 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, siehe den Abschnitt SSL / TLS und die Seite Natives Android-TLS.
Laden Sie es von der sgcWebSockets-Download-Seite herunter, oder beziehen Sie es über GetIt oder Ihr registriertes Konto.
Fragen, Rückmeldungen oder Hilfe beim Umstieg einer Android-App weg von OpenSSL? Kontaktieren Sie uns, Sie erhalten eine Antwort von den Leuten, die den Code geschrieben haben.