Delphi TLS 1.3 sans DLL OpenSSL

· Composants
Delphi TLS 1.3 sans DLL OpenSSL

Tout développeur Delphi qui a livré du TLS connaît la routine. Quelle version d'OpenSSL cette machine a-t-elle. Pourquoi le serveur du client a la 1.1 et la machine de build a la 3.0. Quelles deux DLL doivent accompagner l'exécutable, et que se passe-t-il quand un antivirus en supprime une. sgcWebSockets 2026.10 offre une échappatoire : un moteur TLS 1.3 écrit en Object Pascal, à l'intérieur de la bibliothèque, sans aucune DLL.

C'est une implémentation réelle, pas un wrapper : le handshake, la couche d'enregistrements, le key schedule et la validation des certificats sont entièrement en Pascal. Un client ou un serveur parle TLS sans rien d'installé.

Une seule propriété

oClient := TsgcWebSocketClient.Create(nil);
oClient.URL := 'wss://www.esegece.com:2053';
oClient.TLSOptions.IOHandler := iohNativeTLS;
oClient.Active := True;

Sur un serveur, c'est le même interrupteur sur SSLOptions :

oServer.SSLOptions.IOHandler := iohNativeTLS;
oServer.SSLOptions.CertFile := 'server.pem';
oServer.SSLOptions.KeyFile := 'server.key';
oServer.SSL := True;

ALPN, S N I et les certificats client sont là, sur le handler Indy et sur les serveurs I O C P et E P O L L. Rien d'autre ne change dans votre code.

Faire confiance à ce que la machine approuve déjà

Un client TLS ne vaut que ce que valent ses ancres de confiance, et livrer un cacert.pem qui vieillit mal est en soi un problème de maintenance. Le moteur peut utiliser les racines auxquelles le système d'exploitation fait déjà confiance :

oClient.TLSOptions.NativeTLS_Options.UseSystemRoots := True;

Sous Windows, elles proviennent du magasin système ROOT, sous Linux et Android du premier ensemble de certificats trouvé parmi les emplacements habituels. C'est désactivé par défaut, ce qui maintient les ancres de confiance exactement à ce que dit RootCertFile.

Post-quantique, aujourd'hui, à cause de demain

Un attaquant qui ne peut pas casser votre session TLS aujourd'hui peut quand même l'enregistrer et la conserver. La question intéressante n'est pas de savoir si un ordinateur quantique existe déjà, mais combien de temps votre trafic reste sensible. C'est pourquoi TLS évolue vers l'échange de clés hybride, où le secret partagé reste sûr tant que l'une ou l'autre des deux moitiés tient.

Le moteur négocie les groupes hybrides de la RFC 10024, et la liste de groupes par défaut commence déjà par l'hybride :

oClient.TLSOptions.NativeTLS_Options.Groups :=
  'X25519MLKEM768:SecP256r1MLKEM768:X25519';

Les trois hybrides sont X25519MLKEM768, SecP256r1MLKEM768 et SecP384r1MLKEM1024. Les deux listes utilisent des noms au style OpenSSL séparés par des deux-points, et une valeur vide conserve les valeurs par défaut du moteur.

La cryptographie qui se trouve dessous

La même version ajoute les primitives post-quantiques elles-mêmes au pack sgcCrypto, en Object Pascal, sans aucune bibliothèque externe :

Ils sont validés par rapport aux vecteurs de réponses connues du NIST, qui sont livrés avec la bibliothèque comme un jeu de tests plutôt que comme une simple affirmation.

Un durcissement que vous n'avez pas à demander

La même passe a durci le côté classique contre les attaques temporelles. Les opérations sur la clé privée RSA utilisent le blinding et une exponentiation à temps constant avec vérification du résultat, la multiplication scalaire sur courbe elliptique et la signature Ed25519 s'exécutent en temps constant, et AES et GHASH n'indexent plus une table avec des octets secrets. Les clés privées sont vérifiées lors de leur importation, de sorte qu'une clé qui n'appartient pas à son certificat est refusée au lieu de produire des signatures que personne ne peut vérifier, et une signature dont l'encodage ASN.1 n'est pas un DER minimal est désormais rejetée plutôt qu'acceptée.

Quand utiliser quoi

OpenSSL et SChannel ne vont nulle part, et pour beaucoup d'applications ils restent la bonne réponse : OpenSSL si vous avez besoin d'interopérabilité TLS 1.2 avec quelque chose d'ancien, SChannel si la politique du client veut que Windows possède la cryptographie. Le moteur natif est fait pour le cas où le déploiement est le problème : un seul exécutable, aucune DLL à côté, le même comportement sous Windows et sous Linux, et l'échange de clés post-quantique sans attendre que la plateforme rattrape son retard.

Mise à niveau

Le moteur fait partie du pack sgcCrypto et se sélectionne par composant, donc rien ne change tant que vous ne définissez pas IOHandler. Une build sans les unités de cryptographie déclenche un message clair au lieu d'échouer de façon obscure au moment du handshake.

À lire aussi

Voir la vidéo

Il existe une courte vidéo à ce sujet sur la chaîne eSeGeCe.

Des questions, un retour ou besoin d'aide pour la migration ? Contactez-nous — vous recevrez une réponse des personnes qui ont écrit le code.