Livrer TLS dans une application iOS ou macOS construite avec Delphi ou C++Builder signifiait auparavant embarquer OpenSSL : une libssl.dylib et une libcrypto.dylib empaquetées avec l'application, dont vous deviez assurer la correspondance de version et les correctifs. sgcWebSockets supprime cette exigence. Un nouveau backend TLS natif, iohAppleTLS, utilise le TLS propre à Apple, de sorte que votre application se connecte en toute sécurité sans aucune .dylib OpenSSL à déployer. Il est disponible dans l'édition Enterprise.
Mieux encore, sur les systèmes modernes il vous offre TLS 1.3. Le backend sélectionne automatiquement la meilleure API système pour l'appareil, le tout derrière un seul paramètre, vous n'avez donc pas à différencier selon la version de l'OS et votre code reste le même partout.
Une seule ligne pour basculer
Le backend TLS est sélectionné via TLSOptions.IOHandler. Pour utiliser le TLS natif d'Apple, réglez-le sur iohAppleTLS. Le reste de votre code réseau ne change pas.
uses
sgcWebSocket, sgcWebSocket_Types;
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohAppleTLS;
WSClient.URL := 'wss://www.esegece.com:2053';
WSClient.Active := True;Sur les autres plateformes, vous conservez le backend qui convient : iohOpenSSL fonctionne partout, iohSChannel est natif sous Windows, et iohAndroidTLS est l'option native sans rien à déployer sous Android. Une petite condition garde un seul composant client correct sur chaque cible.
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;Aucune .dylib OpenSSL à déployer
Avec le backend natif, il n'y a aucun OpenSSL à embarquer, à faire correspondre en version ou à corriger. La pile TLS est livrée avec le système d'exploitation, l'application est donc plus légère et libérée d'une dépendance cryptographique tierce. Pour les soumissions à l'App Store, cela signifie aussi une bibliothèque native de moins à justifier, et votre politique TLS suit celle d'Apple plutôt qu'une version de bibliothèque que vous avez figée il y a des mois. Les correctifs de sécurité arrivent via les mises à jour de l'OS.
TLS 1.3 avec repli automatique
Le seul paramètre iohAppleTLS choisit la bonne API système par appareil. Sur macOS 10.14+ et iOS 12+, il utilise Network.framework, qui apporte TLS 1.3. Sur les systèmes plus anciens, il se replie sur Secure Transport, qui plafonne à TLS 1.2. Vous n'écrivez aucune vérification de version, le backend sélectionne le chemin et votre code est identique dans les deux cas.
Un client TLS complet
Il s'agit d'un client complet, et non d'une version réduite. Il utilise le magasin de confiance du système, effectue la vérification SNI et du nom d'hôte, et expose un rappel OnAppleTLSVerifyPeer afin que vous puissiez inspecter le certificat et l'accepter ou le rejeter vous-même. Vous pouvez faire confiance à une autorité privée avec une racine CA personnalisée via RootCertFile, présenter un certificat client pour le TLS mutuel avec CertFile et Password, et annoncer des protocoles applicatifs tels que http/1.1 via ALPN.
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;Le rappel de vérification du pair vous donne le sujet du certificat et son empreinte SHA-256, le résultat de l'évaluation de confiance, et un indicateur Accept que vous réglez pour autoriser ou bloquer la connexion. C'est l'endroit naturel pour épingler un certificat ou appliquer votre propre politique par-dessus la décision de confiance du système.
Fonctionne avec les composants que vous utilisez déjà
Le backend se trouve derrière les TLSOptions partagées, il n'est donc pas limité 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 configure déjà TLSOptions, activer le TLS Apple natif est une seule affectation, sans changement dans la façon dont vous vous connectez ou échangez des données.
La même idée sur Android
Si vous ciblez aussi Android, le backend compagnon iohAndroidTLS y fait le même travail : il utilise le TLS propre à Android via le SSLEngine de la plateforme, sans aucune .so OpenSSL à déployer. Le modèle est identique, vous choisissez le gestionnaire natif par plateforme. Les détails se trouvent sur la page Native Android TLS.
Disponibilité
Le TLS Apple natif (iohAppleTLS) est livré dans l'édition Enterprise de sgcWebSockets. Pour le détail complet des quatre backends TLS, OpenSSL sur chaque plateforme, SChannel sous Windows, et les gestionnaires natifs Android et Apple, consultez la section SSL / TLS et la page Native Apple TLS.
Téléchargez 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 migrer une application iOS ou macOS hors d'OpenSSL ? Contactez-nous, vous recevrez une réponse des personnes qui ont écrit le code.