Livrer une application Android sécurisée avec Delphi ou C++Builder a toujours impliqué une corvée supplémentaire : embarquer libssl.so et libcrypto.so dans l'APK pour qu'OpenSSL soit présent à l'exécution. sgcWebSockets supprime cette corvée. Un nouveau backend TLS natif, iohAndroidTLS, confie le chiffrement à Android lui-même, si bien que votre application se connecte en TLS sans aucune bibliothèque OpenSSL à déployer. Il est disponible dans l'édition Enterprise.
En coulisses, le backend pilote le javax.net.ssl.SSLEngine de la plateforme via JNI. Le système d'exploitation effectue la poignée de main, le chiffrement des enregistrements et la validation du certificat. sgcWebSockets se contente d'injecter du texte en clair et de récupérer du texte chiffré, ce qui signifie que toute la pile TLS est celle que Google livre et corrige avec le système.
Une ligne pour changer
Le backend TLS se sélectionne via TLSOptions.IOHandler. Pour utiliser le TLS natif d'Android, affectez-lui iohAndroidTLS. Tout le reste de votre code réseau reste inchangé.
uses
sgcWebSocket, sgcWebSocket_Types;
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAndroidTLS;
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;Sur les autres plateformes, vous conservez le backend qui convient : iohOpenSSL fonctionne partout, et iohSChannel est l'option native, sans rien à déployer, sous Windows. Une petite condition garde un composant client unique correct sur chaque cible.
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;Aucun OpenSSL dans l'APK
C'est l'avantage majeur. Avec le backend natif, l'APK n'embarque ni libssl.so ni libcrypto.so. Le package est plus petit, et vous ne courez plus jamais après une version d'OpenSSL, ne recompilez plus suite à une alerte de sécurité et n'ajustez plus une compilation de bibliothèque à un appareil. L'implémentation TLS réside sur l'appareil et est maintenue par Android, si bien que les correctifs de sécurité arrivent par les mises à jour système plutôt que par votre cycle de publication.
Cela élimine aussi toute une catégorie de problèmes de déploiement. Plus de « bibliothèque introuvable », plus d'incompatibilité d'architecture entre le .so embarqué et l'appareil, et plus de seconde copie de cryptographie à auditer. Vous définissez une propriété et vous livrez.
Un client TLS complet, pas une version allégée
Le backend natif est un client complet. Il valide le serveur par rapport au magasin de confiance système d'Android et effectue la vérification du nom d'hôte, de sorte que les connexions vers des autorités de certification publiques fonctionnent sans configuration supplémentaire. Il négocie TLS 1.3 et prend en charge ALPN sur Android 10 (API 29) et versions ultérieures, ce qui vous permet d'annoncer des protocoles applicatifs tels que http/1.1 pendant la poignée de main.
Comme il s'appuie sur la même API TLSOptions que tous les autres backends, les propriétés habituelles continuent de fonctionner. VerifyCertificate active ou désactive la validation du pair, RootCertFile fait confiance à une autorité privée, CertFile et Password présentent un certificat client, et ALPNProtocols liste les protocoles à négocier.
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;Compatible avec les composants que vous utilisez déjà
Le backend est câblé dans les TLSOptions partagées, il ne se limite donc pas au client WebSocket. Les clients TCP et HTTP/2 et les autres composants qui exposent TLSOptions le sélectionnent de la même manière. Si votre code définit déjà TLSOptions, ajouter le TLS Android natif se résume à une seule affectation, sans rien changer à la façon dont vous ouvrez la connexion, envoyez ou recevez.
La même idée chez Apple
Si vous ciblez aussi iOS ou macOS, le backend complémentaire iohAppleTLS y fait le même travail : il utilise le TLS propre à Apple, sans aucun .dylib OpenSSL à déployer, et il atteint TLS 1.3 via Network.framework. Le principe est identique, il vous suffit de choisir le gestionnaire natif selon la plateforme. Vous pouvez lire les détails sur la page TLS Apple natif.
Disponibilité
Le TLS Android natif (iohAndroidTLS) est livré dans l'édition Enterprise de sgcWebSockets. Pour le détail complet des quatre backends TLS, OpenSSL sur toutes les plateformes, SChannel sous Windows, et les gestionnaires natifs Android et Apple, consultez la section SSL / TLS et la page TLS Android natif.
Téléchargez-le depuis la page de téléchargement de sgcWebSockets, ou récupérez-le via GetIt ou votre compte enregistré.
Des questions, des retours ou besoin d'aide pour faire migrer une application Android hors d'OpenSSL ? Contactez-nous, vous recevrez une réponse des personnes qui ont écrit le code.