DTLS en VoIP : comment DTLS et DTLS-SRTP sécurisent les clés média WebRTC et SIP

Tout appel vocal chiffré se heurte à un problème de l’œuf et de la poule : l’audio est protégé par SRTP, mais SRTP a besoin d’une clé secrète, et cette clé doit parvenir aux deux terminaux sans qu’un tiers à l’écoute puisse l’intercepter au passage. La façon dont les deux parties s’accordent sur cette clé est le choix le plus déterminant en matière de sécurité des médias en temps réel, et c’est précisément là que DTLS trouve sa place dans la pile protocolaire.

DTLS (Datagram Transport Layer Security) apporte la confidentialité et l’authentification de TLS aux transports non fiables qui tolèrent la perte de paquets, comme UDP, c’est-à-dire exactement ceux sur lesquels circulent la voix et la vidéo en temps réel. Associé à SRTP, il devient DTLS-SRTP : le mécanisme d’échange de clés que WebRTC rend obligatoire et que l’on rencontre de plus en plus à la frontière entre les médias issus des navigateurs et les réseaux SIP traditionnels. Ce guide explique ce qu’est DTLS, comment se déroule le handshake DTLS sur UDP, comment DTLS-SRTP négocie les clés média, en quoi DTLS diffère de TLS et où se place un contrôleur de session en bordure (SBC) dans tout cela.

Qu’est-ce que DTLS ?

DTLS est une version de TLS repensée pour les transports qui ne garantissent ni la livraison ni l’ordre des paquets. Le TLS standard suppose un flux d’octets fiable et ordonné, ce que fournit TCP. Or les médias en temps réel ne passent pas par TCP, car un paquet voix retransmis qui arrive en retard est pire qu’inutile : l’instant qu’il représente est déjà passé. La voix et la vidéo circulent sur UDP, où les paquets peuvent être perdus, dupliqués ou réordonnés, et TLS, tel qu’il est conçu, ne sait pas gérer cette situation.

DTLS résout le problème en conservant intact le modèle de sécurité de TLS et en ajoutant les mécanismes qui manquent à UDP. Il introduit des numéros de séquence explicites pour que le récepteur détecte les paquets manquants et les inversions d’ordre, un temporisateur de retransmission pour qu’un message de handshake perdu soit renvoyé au lieu de bloquer la connexion, et une règle imposant que chaque message de handshake respecte les limites du transport. La cryptographie, les suites cryptographiques et le modèle de confiance restent ceux de TLS. Seule l’enveloppe change.

Le protocole a évolué en parallèle de TLS. DTLS 1.2 (RFC 6347) correspond à TLS 1.2, et DTLS 1.3 (RFC 9147) correspond à TLS 1.3, dont il hérite le handshake plus rapide et les suites cryptographiques modernes. En VoIP, DTLS compte pour une raison principale : c’est le mécanisme qu’utilise WebRTC pour établir les clés qui protègent les médias.

Comment fonctionne le handshake DTLS

Le handshake DTLS suit la même logique qu’un handshake TLS, avec des adaptations qui lui permettent d’aboutir de façon fiable sur un canal de datagrammes sujet aux pertes. L’objectif reste le même : deux terminaux s’authentifient mutuellement et s’accordent sur un secret partagé avant que le moindre flux média protégé ne circule.

Le déroulement du handshake

1. ClientHello et HelloVerifyRequestLe client ouvre l’échange avec un ClientHello. Le serveur répond par un HelloVerifyRequest contenant un cookie sans état, et le client renvoie son ClientHello en y joignant ce cookie. Cet aller-retour vise à contrer les attaques par amplification de type déni de service (DoS) : le serveur ne conserve aucun état tant qu’il n’a pas la preuve que le client peut recevoir des paquets à l’adresse qu’il annonce.
2. Paramètres et certificat du serveurLe serveur envoie son ServerHello avec la suite cryptographique retenue, suivi de son certificat et de ses paramètres d’échange de clés. Avec DTLS-SRTP, le certificat est généralement autosigné, car la confiance repose sur une empreinte transmise par la signalisation et non sur une autorité de certification publique.
3. Échange de clés et certificat du clientLe client envoie sa propre contribution à l’échange de clés et, lorsque l’authentification mutuelle est utilisée, son propre certificat. Les deux parties disposent alors des éléments nécessaires pour dériver un secret maître partagé.
4. ChangeCipherSpec et FinishedChaque partie indique qu’elle passe aux clés négociées, puis envoie un message Finished qui couvre un hachage de l’ensemble du handshake. Si l’un des messages Finished ne peut pas être vérifié, le handshake est interrompu.

Tout au long de l’échange, chaque série de messages est protégée par un temporisateur de retransmission. Si la réponse attendue n’arrive pas, l’expéditeur renvoie ses messages au lieu de conclure à un échec, ce qui permet au handshake d’aboutir même sur un chemin qui perd des paquets sans le signaler.

Pourquoi l’échange de cookie est important

Le cookie du HelloVerifyRequest est un petit détail au rôle considérable pour la sécurité. Comme DTLS fonctionne sur UDP, un attaquant peut facilement falsifier l’adresse source d’un ClientHello et diriger la réponse cryptographique, coûteuse pour le serveur, vers une victime. Exiger du client qu’il renvoie un cookie émis par le serveur l’oblige à prouver qu’il reçoit réellement le trafic à l’adresse annoncée, ce qui ferme ce vecteur d’amplification avant que le serveur n’engage le moindre traitement réel.

Comment DTLS-SRTP négocie les clés média

DTLS-SRTP ne sert pas à chiffrer les médias. Ceux-ci restent transportés par SRTP, exactement comme avec n’importe quelle autre méthode d’échange de clés. DTLS-SRTP résout un problème plus difficile : faire parvenir les clés SRTP aux deux terminaux en toute sécurité. Pour cela, il exécute un handshake DTLS complet directement sur le chemin média, puis dérive les clés SRTP du secret produit par ce handshake.

Toute l’élégance du dispositif tient à la façon dont la confiance est ancrée. Les deux terminaux échangent des certificats autosignés pendant le handshake DTLS, mais un certificat autosigné ne prouve rien à lui seul. Le lien vient de la signalisation : chaque terminal publie un hachage de son certificat sous la forme d’un attribut a=fingerprint dans le SDP de l’offre et de la réponse SIP ou WebRTC. Une fois le handshake DTLS terminé, chaque partie compare le certificat effectivement reçu à l’empreinte annoncée dans la signalisation. En cas de correspondance, elle a la certitude d’avoir négocié avec le pair prévu, et non avec un intercepteur.

Cette conception donne à DTLS-SRTP une propriété dont SDES est dépourvu. Avec SDES, la clé maîtresse SRTP figure dans le corps SDP : quiconque peut lire la signalisation peut déchiffrer les médias, et c’est pourquoi SDES n’est sûr que si la signalisation SIP est elle-même encapsulée dans TLS. Avec DTLS-SRTP, la signalisation ne transporte qu’une empreinte, sans aucune utilité pour un attaquant : les véritables éléments de clé ne quittent jamais le chemin média et sont négociés à nouveau pour chaque session. C’est cette séparation qui explique pourquoi WebRTC impose DTLS-SRTP et interdit totalement SDES.

D’où viennent les clés

Une fois le handshake DTLS terminé, les deux terminaux appliquent au secret maître partagé la même fonction de dérivation de clés, définie dans la RFC 5764, afin de produire les clés maîtresses et les sels SRTP. L’association DTLS peut alors être maintenue uniquement comme contexte de gestion des clés, tandis que SRTP prend le relais pour transporter l’audio et la vidéo. Aucune des deux parties n’a jamais transmis de clé SRTP en clair, et aucune n’a fait confiance à un message qu’elle ne pouvait pas vérifier à l’aide de l’empreinte reçue par la signalisation.

DTLS ou TLS : quelle différence ?

DTLS et TLS partagent le même noyau cryptographique, les mêmes suites cryptographiques et le même modèle de confiance. Ce qui les distingue, c’est le transport pour lequel chacun a été conçu et, dans les réseaux voix, le rôle que chacun finit par jouer. TLS fonctionne sur TCP, un transport fiable et orienté connexion, et sécurise la signalisation SIP. DTLS fonctionne sur UDP, un transport non fiable et sans connexion, et sécurise, sous sa forme DTLS-SRTP, l’échange des clés média.

Caractéristique	TLS	DTLS
Transport	TCP (fiable, ordonné)	UDP (non fiable, non ordonné)
Gestion des pertes de paquets	Repose sur TCP	Retransmission intégrée
Rôle habituel en VoIP	Chiffrement de la signalisation SIP (port 5061)	Échange de clés média DTLS-SRTP
Protection anti-DoS	Handshake TCP	Échange de cookie sans état
Sensibilité à la latence	Blocage en tête de ligne en cas de perte	Pas de blocage en tête de ligne

En pratique, les deux protocoles sont complémentaires et non concurrents. Un appel WebRTC vers SIP sécurisé utilise souvent les deux à la fois : TLS protège la signalisation SIP côté réseau, tandis que DTLS-SRTP négocie les clés média côté navigateur. Aucun ne remplace l’autre, et un SBC doit souvent prendre en charge les deux simultanément, sur les branches opposées d’un même appel.

DTLS-SRTP à la frontière entre WebRTC et SIP

DTLS-SRTP est obligatoire dans WebRTC et pratiquement universel dans les communications par navigateur, mais la plupart des opérateurs SIP et des PBX existants ne l’ont jamais adopté. Ils s’appuient sur SDES sur TLS, ou sur du RTP en clair lorsqu’aucun chiffrement n’est négocié. Lorsqu’un navigateur doit joindre un numéro de téléphone desservi par le trunk d’un opérateur, il faut un élément placé entre les deux mondes pour traduire l’échange de clés. Cet élément, c’est le SBC.

Comme un contrôleur de session en bordure fonctionne en agent utilisateur dos à dos (B2BUA), il termine entièrement les médias sur chaque branche et les régénère de façon indépendante. Côté navigateur, il peut exécuter le handshake DTLS, vérifier l’empreinte et dériver les clés SRTP à la manière de WebRTC. Côté opérateur, il peut négocier SDES sur TLS, convertir en RTP en clair ou appliquer toute autre méthode prise en charge par l’autre extrémité. Les deux branches ont des contextes cryptographiques entièrement distincts : le navigateur obtient le DTLS-SRTP qu’il exige sans que l’opérateur ait quoi que ce soit à changer. C’est la même frontière de chiffrement par branche que celle décrite dans l’architecture d’une passerelle WebRTC vers SIP, où le passage de relais du chiffrement des médias fait partie des cinq sous-systèmes de traduction pris en charge par la passerelle.

La frontière ne se limite pas au chiffrement. Le même SBC gère l’ensemble des différences entre WebRTC et SIP : la terminaison ICE, pour que les candidats de traversée de NAT du navigateur aboutissent à une adresse stable, la médiation de codecs lorsque le navigateur propose Opus et que l’opérateur attend du G.711, et la normalisation des en-têtes SIP, pour que l’appel paraisse natif de chaque côté. La traduction DTLS-SRTP n’est qu’une des tâches de la passerelle, mais c’est elle qui préserve la confidentialité des médias sur tout le parcours.

Questions fréquentes

Conclusion

DTLS existe parce que les médias en temps réel ne peuvent pas se permettre la latence des allers-retours de TCP, et parce que des médias sécurisés ne peuvent pas reposer sur des clés qui circulent dans une signalisation en clair. En transposant le modèle de sécurité de TLS à UDP et en l’associant à SRTP, DTLS-SRTP résout le problème de l’échange de clés d’une manière qui résiste à la perte de paquets et à l’usurpation, sans jamais exposer de clé média à quiconque lit la signalisation. C’est cette combinaison qui en a fait le socle obligatoire de la sécurité des médias WebRTC.

La difficulté, dans les réseaux en production, tient au fait que les navigateurs parlent DTLS-SRTP alors que la plupart des opérateurs et des PBX ne le font pas. Relier ces deux mondes sans affaiblir l’un ou l’autre est un problème de chiffrement par branche, et c’est exactement le type de traduction qu’un contrôleur de session en bordure est fait pour assurer en périphérie du réseau.