Une fois qu'il existe une paire de candidats valide (les deux pairs peuvent se connecter et échanger des données entre eux), il est temps de sécuriser la connexion. DTLS est un protocole cryptographique qui chiffre les données pour éviter l'inspection ou la modification du contenu des données échangées.
DTLS nécessite les bibliothèques openSSL (à partir d'openSSL 1.1+)
La configuration du DTLS se trouve dans la propriété RTCOptions.DTLSOptions du TsgcRTCPeerConnection. Pour activer DTLS, définissez la propriété RTCOptions.DTLS sur True. Voici les principales propriétés :
RootCertFile : chemin vers le magasin de confiance utilisé pour vérifier l'autre extrémité, normalement un fichier contenant l'autorité de certification. C'est le sens que cette propriété a également sur les transports TLS et QUIC. Il ne s'agit pas du certificat de cette extrémité, et une configuration qui renseigne RootCertFile et KeyFile en laissant CertFile vide lève une erreur au démarrage de la connexion.
CertFile : chemin vers le fichier de certificat de cette extrémité. Le fichier peut contenir le certificat accompagné de ses intermédiaires, un fichier de chaîne fonctionne donc.
KeyFile : chemin vers le fichier de clé du certificat.
VerifyCertificate : si la chaîne de certificats de l'autre extrémité doit être vérifiée, activez cette propriété. WebRTC authentifie l'autre extrémité par l'empreinte transportée dans le SDP et non par une chaîne de certificats, laisser cette propriété désactivée est donc la configuration WebRTC normale, et elle n'est pas concernée par la vérification de chaîne désormais appliquée sur les transports DTLS.
VerifyDepth : est une propriété entière qui représente le nombre maximum de liens autorisés lors de la vérification, c'est-à-dire la profondeur de chaîne maximale autorisée lorsque le certificat de l'autre extrémité est vérifié.
OpenSSL_Options : configuration des bibliothèques openSSL.
APIVersion: permet de définir quelle API OpenSSL sera utilisée. Seule l'API OpenSSL 1.1+ prend en charge DTLS.
oslAPI_1_1 : utilise l'API 1.1 OpenSSL, nécessite notre bibliothèque Indy personnalisée et permet d'utiliser les bibliothèques OpenSSL 1.1.1 (avec prise en charge de TLS 1.3).
oslAPI_3_0 : utilise l'API OpenSSL 3.0, nécessite notre bibliothèque Indy personnalisée et permet d'utiliser les bibliothèques OpenSSL 3.0.0 (avec prise en charge de TLS 1.3).
LibPath : ici vous pouvez configurer l'emplacement des bibliothèques openSSL
oslpNone : c'est la valeur par défaut ; les bibliothèques OpenSSL doivent se trouver dans le même dossier que le binaire ou dans un chemin connu.
oslpDefaultFolder : définit automatiquement le chemin openSSL où les bibliothèques doivent être situées pour toutes les personnalités de l'IDE.
oslpCustomFolder : si cette option est sélectionnée, définissez le chemin complet dans la propriété LibPathCustom.
LibPathCustom : lorsque LibPath = oslpCustomFolder, définissez ici le chemin complet où se trouvent les bibliothèques openSSL.
UnixSymLinks : activer ou désactiver le chargement des liens symboliques sous les systèmes Unix (activé par défaut, sauf sous OSX64) :
oslsSymLinksDefault : activés par défaut sauf sous OSX64 (après MacOS Monterey, le chargement de la bibliothèque sans version échoue.).
oslsSymLinksLoadFirst : Charger d'abord les liens symboliques avant de tenter de charger les bibliothèques de version.
oslsSymLinksLoad : Charger les liens symboliques après avoir tenté de charger les bibliothèques de version.
oslsSymLinksDontLoad : ne pas charger les SymLinks.