OpenSSL ou cryptographie native en Delphi : choisir au runtime

6 octobre 2026 · Composants

Retirer les DLL OpenSSL d'une application Delphi était autrefois une décision prise à la compilation. Vous activiez une directive de compilation, vous recompiliez, et vous livriez un second exécutable aux clients qui ne pouvaient pas avoir OpenSSL sur leurs machines. sgcWebSockets 2026.10 en fait une décision prise au runtime : une seule variable globale, définie une fois au démarrage, détermine si la cryptographie de l'application s'exécute sur OpenSSL ou sur la cryptographie intégrée à la bibliothèque, écrite en Object Pascal.

Le côté connexion, le TLS sans OpenSSL, est couvert dans Delphi TLS 1.3 sans DLL OpenSSL. Cet article couvre tout le reste : les signatures, les empreintes, l'échange de clés et le chiffrement que votre application effectue en dehors du handshake TLS.

Une ligne au démarrage

L'unité sgcBase_Helpers déclare la variable globale sgcCryptoBackend, de type TsgcCryptoBackend :

uses
  sgcBase_Helpers;

begin
  sgcCryptoBackend := cbNative;
  sgcCheckNativeCrypto;
  Application.Initialize;
  ...

L'interrupteur est global, pas par composant, il faut donc le définir avant la création de tout composant. sgcCheckNativeCrypto est facultatif : si les unités de cryptographie native ne sont pas compilées, il lève une exception au démarrage avec un message clair, plutôt qu'à la première signature que votre application tente de produire.

Trois valeurs

cbOpenSSL est la valeur par défaut. La cryptographie de l'application s'exécute sur OpenSSL, exactement comme dans les versions précédentes, donc la mise à niveau ne change rien tant que vous ne définissez pas la variable.
cbNative exécute la cryptographie de l'application sur l'implémentation Object Pascal. OpenSSL n'est jamais chargé pour elle.
cbAuto utilise OpenSSL quand ses bibliothèques peuvent être chargées, et le code natif quand ce n'est pas le cas. La vérification s'exécute une seule fois et le résultat est mis en cache.

cbAuto est celui qu'il faut pour les produits déployés des deux façons. Certains clients installent les bibliothèques OpenSSL à côté de l'exécutable, d'autres n'y sont pas autorisés, et la même build fonctionne pour les deux sans qu'un ticket de support ne signale une DLL manquante.

// same executable, with or without the OpenSSL libraries beside it
sgcCryptoBackend := cbAuto;

Ce que couvre l'interrupteur

L'interrupteur couvre la cryptographie que les composants effectuent pour votre compte :

les fonctions d'aide pour le hachage et le HMAC ;
la signature et la vérification JWT, HS, RS et ES ;
les preuves OAuth2 et DPoP ;
AWS Signature V4 et les URL signées CloudFront ;
Web Push ;
le chiffrement de bout en bout (E2EE), où des pairs sur des moteurs différents interopèrent, de sorte qu'un client en cbNative puisse dialoguer avec un serveur resté sur OpenSSL ;
WebAuthn et les passkeys ;
SAML et les signatures XML ;
NTLM ;
AEAD, ML-KEM et HKDF ;
la protection des paquets QUIC, les certificats DTLS et WebRTC, et SRTP.

Aucun de ces éléments n'exige de modification de code. Un JWT signé avec OpenSSL hier est signé nativement aujourd'hui, parce que la variable le dit.

Les connexions sont un réglage à part

sgcCryptoBackend ne change pas la façon dont un composant se connecte. Le TLS d'une connexion se choisit par composant, avec IOHandler = iohNativeTLS, sur les composants TCP, HTTP et WebSocket et tout ce qui est construit dessus, comme MQTT, sur QUIC et HTTP/3, et sur DTLSOptions pour WebRTC :

sgcCryptoBackend := cbNative;                  // application crypto
oClient.TLSOptions.IOHandler := iohNativeTLS;  // this connection

Un composant qui garde le handler OpenSSL charge toujours OpenSSL au moment de se connecter. Avec iohNativeTLS sur QUIC, HTTP/3 et DTLS, aucun OpenSSL n'est utilisé, quoi que dise l'interrupteur. Une application qui ne veut OpenSSL nulle part définit les deux : l'interrupteur pour sa cryptographie, et le handler sur chaque composant qui ouvre une connexion sécurisée.

La directive de compilation devient facultative

Jusqu'à présent, fonctionner sans OpenSSL supposait la directive de compilation SGC_NATIVE_CRYPTO. Elle n'est plus nécessaire. Sans elle, le code OpenSSL et le code natif sont tous deux compilés, et c'est la variable qui décide au runtime.

La directive garde encore une utilité. Elle force le moteur natif quoi que dise sgcCryptoBackend et retire le code OpenSSL des unités de cryptographie de l'application, ce qui réduit la taille de l'exécutable. Si vous savez qu'une build n'utilisera jamais OpenSSL, elle reste le bon choix. Si vous ne le savez pas encore, laissez-la désactivée et décidez au démarrage.

Pourquoi c'est important

Une seule build. Les clients qui doivent livrer sans OpenSSL, pour des raisons de licence, un audit de sécurité qui questionne chaque binaire tiers, ou des machines verrouillées où personne n'a le droit de copier une DLL, reçoivent le même exécutable que tout le monde.
Un repli. cbAuto maintient une application fonctionnelle quand les bibliothèques OpenSSL sont absentes, au lieu d'échouer à la première signature.
Mobile. Sur iOS et Android, il n'y a pas d'OpenSSL à embarquer pour la cryptographie de l'application.
Le même code partout. L'interrupteur fonctionne de la même façon sous Windows, Linux, macOS, iOS et Android, de Delphi 7 à Delphi 13 et sous C++Builder.

Mise à niveau

Rien ne change tant que vous ne définissez pas la variable, puisque cbOpenSSL est la valeur par défaut. Pour essayer le moteur natif, ajoutez les deux lignes ci-dessus à votre fichier projet, lancez vos tests, et comparez. La liste complète de ce que couvre l'interrupteur, et du réglage nécessaire dans chaque domaine pour n'utiliser aucun OpenSSL au runtime, se trouve dans la rubrique d'aide Fonctionner sans OpenSSL.