OpenSSL (iohOpenSSL) est le transport TLS multiplateforme de sgcWebSockets. Il fonctionne sur chaque plateforme ciblée par la bibliothèque et constitue le choix par défaut sur la plupart d'entre elles, avec la plus large couverture de protocoles et de chiffrements de tous les backends. Activez-le en définissant TLSOptions.IOHandler sur iohOpenSSL, puis déployez les bibliothèques d'exécution OpenSSL avec votre application.
TLS multiplateforme implémenté sur le socket d'Indy, disponible sur chaque plateforme ciblée par sgcWebSockets.
OpenSSL est l'implémentation TLS multiplateforme que sgcWebSockets superpose au socket d'Indy. Il est disponible sur Windows, Linux, macOS, iOS et Android, et constitue le backend par défaut sur la plupart d'entre eux. Choisissez OpenSSL lorsque vous avez besoin d'un comportement TLS identique sur chaque plateforme, ou lorsque vous dépendez d'une fonctionnalité que seul OpenSSL expose.
Le backend couvre TLS 1.0 à TLS 1.3 avec la plus large sélection de suites de chiffrement de tous les transports sgcWebSockets. Vous pouvez faire confiance à une autorité privée ou auto-signée avec une racine CA personnalisée (RootCertFile), présenter un certificat client pour le TLS mutuel et annoncer des protocoles applicatifs tels que http/1.1 via ALPN. Comme les quatre backends partagent la même API TLSOptions, du code écrit pour OpenSSL passe à un backend natif en changeant uniquement la ligne IOHandler.
Le compromis se situe au niveau du déploiement. OpenSSL est une dépendance externe, vous livrez donc ses bibliothèques d'exécution avec votre application et les maintenez à jour. Sous Windows, cela signifie libssl-3.dll et libcrypto-3.dll, sous Linux et Android les fichiers .so correspondants, et sur les plateformes Apple les fichiers .dylib. Si vous souhaitez un TLS natif sans aucune bibliothèque à déployer, regardez SChannel sous Windows ou les backends natifs Android et Apple, ou continuez à utiliser OpenSSL en le liant statiquement dans votre exécutable Windows, voir ci-dessous.
Définissez TLSOptions.IOHandler sur iohOpenSSL, puis déployez les bibliothèques OpenSSL avec votre build.
uses
sgcWebSocket, sgcWebSocket_Types;
// ...
WSClient.TLS := True;
WSClient.TLSOptions.IOHandler := iohOpenSSL;
WSClient.TLSOptions.VerifyCertificate := True;
WSClient.TLSOptions.RootCertFile := ''; // CA personnalisée optionnelle (PEM/DER)
WSClient.TLSOptions.CertFile := ''; // certificat client optionnel pour 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 = ""; // CA personnalisée optionnelle (PEM/DER)
WSClient->TLSOptions->CertFile = ""; // certificat client optionnel pour mTLS
WSClient->TLSOptions->Password = "";
WSClient->TLSOptions->ALPNProtocols->Add("http/1.1");
WSClient->Host = "your.server.com";
WSClient->Port = 443;
WSClient->Active = true;OpenSSL est une dépendance externe, les bibliothèques d'exécution accompagnent donc votre application sur chaque plateforme.
Déployez libssl-3.dll et libcrypto-3.dll à côté de votre exécutable (le build 32 bits ou 64 bits correspondant à votre cible), ou évitez complètement les DLL en liant OpenSSL statiquement, voir ci-dessous.
Embarquez les fichiers .so libssl et libcrypto correspondants, puis chargez-les depuis un chemin que votre application peut atteindre à l'exécution.
Livrez les fichiers .dylib libssl et libcrypto avec le bundle de l'application afin que l'exécution OpenSSL soit disponible sur l'appareil.
Comme les bibliothèques vous incombent, vous êtes responsable de leur mise à jour lorsqu'un correctif de sécurité est publié.
Sous Windows, OpenSSL peut être lié directement à l'intérieur de votre .exe au lieu d'être chargé depuis libssl-3.dll et libcrypto-3.dll à l'exécution.
Ajoutez l'unité sgcIdSSLOpenSSL_Static à la clause uses de votre projet et il n'y a rien d'autre à configurer : aucune directive de compilation à activer, aucune version d'API OpenSSL à choisir. Votre application commence à utiliser la bibliothèque OpenSSL liée dans l'exécutable dès son prochain démarrage, aussi bien pour les composants client que serveur, en builds 32 bits et 64 bits. Retirez l'unité de la clause uses et votre application revient exactement au chargement des DLL OpenSSL comme avant.
uses
sgcWebSocket, sgcWebSocket_Classes,
sgcIdSSLOpenSSL_Static;La version d'OpenSSL actuellement liée est la 3.5.7, rafraîchie lors des futures mises à jour afin que vous n'ayez pas besoin de suivre ou de redéployer vous-même les binaires OpenSSL. La liaison statique nécessite Delphi XE2 ou une version ultérieure, ainsi que la bibliothèque Indy personnalisée (celle utilisée par défaut dans ces éditions) ; sur les versions de Delphi plus anciennes, l'unité ne compile rien et votre application continue de charger les DLL OpenSSL comme d'habitude.
OpenSSL (iohOpenSSL) est inclus dans toutes les éditions de sgcWebSockets. Consultez la matrice des fonctionnalités pour le détail complet.
La liaison statique sous Windows nécessite Delphi XE2 ou une version ultérieure et est disponible dans les éditions Enterprise et All-Access.