Guide de configuration TLS et SRTP pour SBC : sécuriser la signalisation SIP et les médias vocaux

La signalisation SIP circule en texte clair par défaut. L’audio également. Sans chiffrement, toute personne ayant accès au chemin réseau entre deux terminaux peut capturer les messages SIP, extraire les métadonnées d’appel et reconstituer des conversations vocales entières à partir de paquets RTP capturés.
Transport Layer Security (TLS) et Secure Real-time Transport Protocol (SRTP) résolvent ces problèmes, mais ils protègent des éléments différents. TLS chiffre le canal de signalisation (les messages SIP qui établissent, modifient et terminent les appels). SRTP chiffre le canal média (les paquets vocaux proprement dits). Un Session Border Controller (SBC) est l’équipement réseau qui applique ces deux protocoles à la frontière du réseau vocal.
Ce guide couvre les étapes pratiques de configuration de TLS et SRTP sur un SBC : comment les deux protocoles dépendent l’un de l’autre, où placer les frontières de chiffrement dans votre architecture réseau, comment gérer les environnements mixtes avec des équipements existants, et comment résoudre les problèmes de déploiement les plus courants.

Pourquoi SRTP doit être déployé avec TLS

Il est tentant de considérer TLS et SRTP comme simplement complémentaires. Ce n’est pas le cas. La sécurité de l’un dépend de l’autre, et déployer SRTP sans TLS crée un faux sentiment de sécurité.
Voici pourquoi. Le mécanisme d’échange de clés SRTP le plus courant, SDP Security Descriptions (SDES, défini dans la RFC 4568), intègre les clés de chiffrement directement dans le corps SDP des messages SIP. Lorsqu’un terminal envoie un SIP INVITE pour établir une session média chiffrée, l’offre SDP inclut un attribut crypto contenant la clé SRTP en encodage base64.
Si ce SIP INVITE transite sur du UDP ou du TCP non chiffré, les clés SRTP sont visibles par quiconque peut capturer le trafic de signalisation. Un attaquant qui intercepte l’échange SIP peut extraire les clés, puis les utiliser pour déchiffrer chaque paquet SRTP de la session. Le chiffrement vocal devient inutile.
TLS empêche cela en chiffrant l’intégralité du message SIP, y compris le corps SDP et ses attributs crypto. Avec TLS actif, un attaquant qui capture le trafic sur le chemin de signalisation ne voit que la session TLS chiffrée, et non le contenu SIP ni les clés SRTP qu’il contient.
La règle de déploiement est simple : ne déployez jamais SRTP sur de la signalisation SIP non chiffrée dans un environnement de production. Le SBC est l’emplacement idéal pour appliquer cette règle, car il termine et ré-émet à la fois la signalisation et les médias à la frontière du réseau.

Architecture : où se situe le chiffrement dans votre réseau

Un ProSBC fonctionnant comme Back-to-Back User Agent (B2BUA) termine les sessions SIP de chaque côté de manière indépendante. Cette architecture est essentielle pour le chiffrement, car elle signifie que le SBC gère deux contextes de sécurité complètement séparés : un pour chaque segment de l’appel.
Sur le segment externe (face à un fournisseur de trunk SIP ou un opérateur), le SBC peut appliquer TLS et SRTP. Sur le segment interne (face à votre IP-PBX, centre de contact ou terminal), le SBC peut utiliser le transport que l’équipement interne supporte. Les deux segments sont indépendants, chacun avec sa propre politique de chiffrement.
Cela crée trois modèles de déploiement pratiques.

Modèle 1 : chiffrement de bout en bout

Les deux côtés du SBC supportent TLS et SRTP. Le SBC peut fonctionner en mode relais SRTP, faisant transiter les médias chiffrés sans les déchiffrer. Cela préserve le chiffrement de bout en bout et réduit la charge de traitement du SBC. La signalisation sur les deux segments passe par TLS.
Ce modèle est idéal lorsque votre infrastructure interne et vos pairs externes supportent tous le chiffrement moderne. Il offre la posture de sécurité la plus robuste.

Modèle 2 : pont de chiffrement

Un côté supporte TLS et SRTP. L’autre non. C’est le scénario de déploiement réel le plus courant, où le ProSBC sécurise le système téléphonique existant.
Votre fournisseur de trunk SIP ou Microsoft Teams exige TLS et SRTP. Votre IP-PBX existant ne supporte que UDP et RTP. Le SBC se positionne entre les deux, acceptant le SIP/RTP non chiffré du PBX et convertissant vers TLS/SRTP en direction du pair externe. Aucune mise à niveau complète du PBX n’est nécessaire.
Le SBC effectue la conversion RTP vers SRTP sur le chemin média et la terminaison/ré-émission TLS sur le chemin de signalisation. Le réseau interne reste non chiffré (et doit être protégé par d’autres contrôles de sécurité réseau), tandis que tout le trafic traversant l’internet public est entièrement chiffré.

Modèle 3 : politiques de chiffrement par trunk

Les réseaux réels ne sont pas uniformes. Vous pouvez avoir certaines connexions opérateur exigeant TLS et SRTP, d’autres ne supportant que TLS sans SRTP, et des trunks internes où le chiffrement n’est pas nécessaire.
Un SBC correctement configuré vous permet de définir la politique de chiffrement par groupe de trunks (appelé Network Access Point, ou NAP, dans la terminologie ProSBC). Chaque trunk spécifie indépendamment si TLS est requis, préféré ou désactivé, et si SRTP est requis, préféré ou désactivé.
Cette granularité est essentielle. Une politique de chiffrement globale vous oblige soit à tout chiffrer (ce qui casse les connexions existantes), soit à ne rien chiffrer (ce qui laisse les connexions externes exposées). Les politiques par trunk vous permettent d’appliquer le chiffrement exactement là où il est nécessaire.

Configuration de TLS : sécuriser la signalisation SIP

La configuration TLS sur un SBC comporte quatre étapes : gestion des certificats, configuration de l’écoute, attribution de la politique par trunk et TLS mutuel optionnel.

Étape 1 : gestion des certificats

Toute connexion TLS exige que le SBC présente un certificat X.509 valide à ses pairs. ProSBC définit une configuration par défaut pour ce paramètre. Le certificat doit répondre aux exigences suivantes :
Le Common Name (CN) ou le Subject Alternative Name (SAN) du certificat doit correspondre au Fully Qualified Domain Name (FQDN) que les pairs externes utilisent pour joindre le SBC. Si l’adresse de signalisation de votre SBC est sbc.example.com, le certificat doit être émis pour ce domaine.
Le certificat doit être émis par une autorité de certification (CA) reconnue par vos pairs. Pour le SIP trunking général, les certificats de CA publiques comme DigiCert, Sectigo ou Let’s Encrypt conviennent. Cependant, certains fournisseurs de services peuvent avoir des exigences plus strictes à cet égard, comme pour Microsoft Teams Direct Routing : le certificat doit être émis par l’une des CA figurant sur la liste de racines de confiance publiée par Microsoft.
Installez à la fois le certificat public du SBC et sa clé privée (en tant que certificat local) ainsi que la chaîne CA complète (en tant que certificats de confiance) sur le SBC. Consultez les suites de chiffrement TLS et SRTP supportées dans la documentation ProSBC. L’absence de certificats intermédiaires dans les chaînes de certificats est l’une des causes les plus fréquentes d’échec de la poignée de main TLS.
Mettez en place un processus d’« audit de certificats ». Un certificat TLS qui expire sans renouvellement provoquera des échecs d’appel immédiats sur chaque trunk qui l’utilise. Assurez-vous de mener des audits et une surveillance régulière pour vous assurer qu’aucun certificat n’est expiré.

Étape 2 : activer l’écoute TLS

Configurez le SBC pour écouter les connexions TLS sur son interface de signalisation. Les paramètres clés incluent :
Port d’écoute. Le port TLS par défaut pour SIP est 5061, mais il est entièrement configurable. Si vous devez utiliser un port différent pour des raisons opérationnelles ou de sécurité, configurez-le en conséquence. L’important est que vos pairs sachent à quel port se connecter.
Version TLS minimale. Si votre SBC supporte des versions plus anciennes de TLS, désactivez TLS 1.0 et TLS 1.1, qui présentent des vulnérabilités connues. Définissez TLS 1.2 comme version minimale. TLS 1.3 est préféré lorsque les deux côtés le supportent, car il offre une sécurité améliorée et une poignée de main plus rapide (un aller-retour au lieu de deux). ProSBC n’autorise que TLS 1.2 lorsque TLS 1.3 n’est pas utilisé.

Étape 3 : définir les politiques TLS

Définissez la politique TLS pour chaque groupe de trunks en fonction des exigences des pairs. Par exemple : TLS (1.3 par défaut, ou 1.2), TCP ou UDP.

Étape 4 : TLS mutuel (mTLS)

Le TLS standard est unidirectionnel : le SBC présente son certificat au pair, et le pair le valide. Le pair ne prouve pas son identité au SBC (note : le SBC est le client et le pair est le serveur dans cet exemple).
Le TLS mutuel ajoute une deuxième étape de validation. Le SBC demande et valide également le certificat du pair. Cela empêche les équipements non autorisés d’établir des connexions SIP avec le SBC, même s’ils connaissent l’adresse IP et le port corrects.
mTLS est requis pour Microsoft Teams Direct Routing et est recommandé pour les interconnexions opérateur et tout environnement soumis à des exigences de conformité réglementaire. Pour configurer mTLS, installez les certificats CA de confiance (ou les certificats spécifiques des pairs) dans le magasin de confiance de votre SBC, et configurez le trunk pour exiger l’authentification du pair.

Configuration de SRTP : chiffrer les médias vocaux

Une fois TLS sécurisant le canal de signalisation, vous pouvez configurer SRTP en toute sécurité pour le chiffrement des médias. La configuration SRTP implique trois décisions : méthode d’échange de clés, chiffrement RTP vers SRTP et comportement du relais SRTP.

Étape 1 : méthode d’échange de clés

Deux mécanismes d’échange de clés sont utilisés en pratique :
SDES (SDP Security Descriptions, RFC 4568) est la méthode la plus largement supportée. Les clés SRTP sont échangées dans l’attribut crypto de l’offre ou de la réponse SDP au sein de la signalisation SIP. SDES est simple à configurer et compatible avec la plupart des terminaux SIP et des fournisseurs de trunking. L’exigence critique : la signalisation SIP doit fonctionner sur TLS lors de l’utilisation de SDES, car les clés sont intégrées dans le corps SDP en texte clair.
DTLS-SRTP échange les clés via une poignée de main DTLS séparée sur le chemin média, indépendamment de la signalisation SIP. Il est requis pour les applications WebRTC, plus complexe à configurer, et ne dépend pas de la signalisation SIP pour l’échange de clés. DTLS-SRTP est principalement utilisé pour les applications vocales et vidéo basées sur navigateur.
(Note : il existe techniquement d’autres méthodes d’échange appelées ZRTP et MIKEY, mais elles ne sont pas couramment utilisées sur le terrain).
Pour la plupart des déploiements SBC impliquant le SIP trunking, l’interconnexion opérateur et les plateformes de communications unifiées, SDES sur une signalisation protégée par TLS est l’approche standard.

Étape 2 : conversion RTP vers SRTP

C’est l’une des capacités les plus précieuses d’un SBC dans un environnement à chiffrement mixte. Lorsqu’un côté d’un appel supporte SRTP et l’autre non, le SBC convertit entre les deux :
Le SBC reçoit les médias RTP non chiffrés du terminal existant. Il chiffre les médias en SRTP et les transmet au pair capable de chiffrement. Dans le sens inverse, il déchiffre le SRTP entrant et envoie du RTP au terminal existant.
Cette conversion se produit de manière transparente. Aucun des terminaux ne sait que l’autre côté utilise un transport média différent. Le SBC gère l’ensemble de la gestion des clés, du chiffrement et du déchiffrement.
Les cas d’utilisation courants de la conversion RTP vers SRTP incluent la connexion d’un IP-PBX existant (RTP uniquement) à un fournisseur de trunk SIP exigeant SRTP, le pontage d’une ancienne plateforme de centre de contact vers Microsoft Teams, et le support des utilisateurs distants sur des connexions chiffrées tandis que le PBX du siège fonctionne en interne sans chiffrement.

Étape 3 : relais SRTP

Lorsque les deux terminaux supportent SRTP, le SBC peut fonctionner en mode relais. Il fait transiter les médias chiffrés sans les déchiffrer ni les re-chiffrer. Cela préserve le chiffrement de bout en bout des médias et réduit la charge de traitement du SBC.
Le relais SRTP est approprié lorsque les deux pairs négocient une méthode d’échange de clés et des suites de chiffrement compatibles, et que le SBC n’a pas besoin d’inspecter ou de modifier les médias (pas de transcodage, pas d’enregistrement, pas de manipulation média requise sur cet appel).

Scénarios de déploiement

Microsoft Teams Direct Routing

Teams Direct Routing a des exigences de chiffrement spécifiques. Le SBC doit supporter TLS (TLS mutuel avec les racines CA publiées par Microsoft), et tous les médias doivent utiliser SRTP. Le SBC se positionne entre l’infrastructure Teams et votre connectivité PSTN, gérant TLS/SRTP côté Teams et le transport supporté par votre fournisseur de trunk SIP de l’autre côté.
Points de configuration clés : installez un certificat d’une CA approuvée par Microsoft, configurez mTLS sur le trunk côté Teams, définissez SRTP comme requis, et activez la conversion RTP vers SRTP si votre fournisseur de trunk SIP ne supporte pas SRTP.

Interconnexion avec un fournisseur de trunk SIP

Les principaux fournisseurs de trunk SIP (Bandwidth, Telnyx, Twilio et autres) supportent désormais TLS et SRTP. Activez TLS sur le trunk côté opérateur et définissez SRTP comme requis ou préféré selon la documentation du fournisseur. Certains fournisseurs supportent mTLS ; consultez leurs guides de configuration.

Intégration de PBX existants

De nombreuses organisations exploitent des IP-PBX déployés avant que TLS et SRTP ne soient devenus la norme. Ces systèmes ne supportent que UDP/TCP pour la signalisation et RTP pour les médias. Le SBC gère la conversion de chiffrement sans nécessiter de modification du PBX.
Configurez le trunk côté PBX avec TLS désactivé et SRTP désactivé. Configurez le trunk côté externe avec TLS requis et SRTP requis. Le SBC fait le pont entre les deux domaines de chiffrement.

Utilisateurs distants et en télétravail

Les téléphones SIP et les softphones se connectant via l’internet public doivent toujours utiliser TLS et SRTP. Sans chiffrement, un utilisateur sur le Wi-Fi d’un café transmet ses appels vocaux en texte clair sur un réseau partagé.
Configurez le trunk côté accès pour exiger TLS et SRTP. Cela protège à la fois les métadonnées de signalisation et le contenu vocal contre l’écoute clandestine sur les réseaux non sécurisés.

Dépannage des problèmes courants de TLS et SRTP

Échecs de poignée de main TLS

Certificat expiré est le problème TLS le plus courant. Le certificat du SBC a expiré et les pairs rejettent la connexion. Vérifiez les dates d’expiration des certificats et renouvelez-les avant l’échéance.
CA non reconnue se produit lorsque le pair ne fait pas confiance à la CA ayant émis votre certificat. Installez votre chaîne de certificats (y compris les intermédiaires) et vérifiez que le magasin de confiance du pair inclut votre CA. Pour Teams Direct Routing, vérifiez que votre CA figure sur la liste approuvée par Microsoft.
Non-concordance du FQDN se produit lorsque le CN ou le SAN du certificat ne correspond pas au nom d’hôte que le pair utilise pour se connecter. Le certificat doit correspondre au FQDN dans les en-têtes SIP, pas seulement à l’adresse IP.
Non-concordance de version TLS se produit lorsque votre SBC exige TLS 1.2 mais que le pair ne supporte que TLS 1.0, ou l’inverse. Vérifiez les paramètres de version TLS minimale des deux côtés.

Échecs de négociation SRTP

Non-concordance des suites de chiffrement se produit lorsque le SBC propose une seule méthode d’échange de clés mais que le pair ne supporte qu’une suite différente. Vérifiez la configuration des suites cryptographiques des deux côtés.
Attribut crypto manquant se produit lorsque le terminal distant n’inclut pas d’attribut crypto dans son SDP. Il est possible qu’il ne supporte pas SRTP, ou que SRTP ne soit pas activé de son côté. Si le trunk est défini sur SRTP requis, l’appel échouera.
SRTP proposé mais rejeté se produit lorsque le pair inclut des attributs crypto dans l’offre mais que la réponse du SBC les supprime, ou inversement. Vérifiez que SRTP est activé sur le bon trunk et que le mode d’application n’est pas défini sur désactivé.

Audio unidirectionnel après l’activation de SRTP

Cela peut être causé par divers facteurs, notamment un problème d’interopérabilité avec les implémentations SRTP, un problème de négociation SRTP via SIP/SDP, ou un simple problème réseau. Lorsque SRTP est activé, les médias peuvent utiliser des ports différents ou des caractéristiques de transport différentes. Vérifiez que les pare-feu entre le SBC et les terminaux autorisent les ports média SRTP. Vérifiez que la configuration NAT ne réécrit pas les en-têtes des paquets SRTP. Utilisez la capture de paquets pour confirmer que les médias circulent dans les deux sens.

Perturbations lors du renouvellement de certificats

Le remplacement d’un certificat sur un SBC en production peut provoquer de brèves interruptions de service si la procédure n’est pas gérée avec soin. Bonne pratique : téléversez le nouveau certificat à côté de l’existant, vérifiez que les poignées de main TLS réussissent avec le nouveau certificat dans un environnement de test, puis basculez le SBC de production vers le nouveau certificat lors d’une fenêtre de maintenance.

Outils de diagnostic

Les captures de traces SIP (montrant le contenu complet des messages SIP, y compris les attributs crypto du SDP) et la capture de paquets en direct (équivalent de Wireshark sur le SBC lui-même) sont les outils principaux. La documentation couvre le dépannage des problèmes TLS et audio étape par étape. Utilisez les traces SIP pour vérifier que les sessions TLS sont établies, que le SDP inclut des attributs crypto et que SRTP est correctement négocié dans la réponse SDP.

Liste de bonnes pratiques

Suivre ces pratiques vous aidera à garantir que votre déploiement TLS et SRTP est sécurisé, maintenable et résilient.

1. Déployez TLS avant SRTP.Sécurisez d’abord le canal de signalisation pour protéger l’échange de clés SRTP.
2. Utilisez TLS 1.2 ou supérieur.Désactivez TLS 1.0 et 1.1 sur tous les trunks.
3. Appliquez le chiffrement sur tous les trunks orientés externe.Tout trafic traversant l’internet public doit utiliser TLS et SRTP.
4. Configurez des politiques par trunk.Différents trunks ont des exigences différentes.
5. Programmez des rappels pour vérifier les expirations de certificats.Alertes à 30 jours et 7 jours.
6. Utilisez mTLS pour l’interconnexion opérateur.Le TLS unidirectionnel n’est pas suffisant pour les connexions à haute sécurité.
7. Activez la conversion RTP vers SRTP pour l’intégration des systèmes existants.Ne laissez pas les terminaux existants comme prétexte pour ignorer SRTP sur les trunks externes.
8. Testez avec des captures de paquets.Après avoir activé le chiffrement, vérifiez à l’aide d’une capture que la signalisation est chiffrée par TLS et que les charges utiles média apparaissent comme du SRTP chiffré.
9. Documentez la politique de chiffrement par trunk.Maintenez une matrice indiquant quels trunks utilisent TLS, SRTP, mTLS, et quelle méthode d’échange de clés. Cette documentation est essentielle pour les audits de conformité.
10. Révisez régulièrement les suites de chiffrement.Les normes cryptographiques évoluent. Assurez-vous de mettre à jour votre pile, de lire les notes de version et de déprécier les algorithmes faibles à mesure que les recommandations changent.

Ce qu’il faut rechercher dans un SBC pour le chiffrement

Tous les SBC ne gèrent pas le chiffrement de la même manière. Si vous évaluez un SBC pour un déploiement nécessitant TLS et SRTP, recherchez ces capacités :

Politiques TLS et SRTP par trunk

Le SBC doit vous permettre de configurer le chiffrement indépendamment sur chaque groupe de trunks. Les paramètres globaux uniquement ne fonctionnent pas dans les réseaux réels aux exigences hétérogènes.

Conversion RTP vers SRTP

Sans cette capacité, vous ne pouvez pas chiffrer les médias pour les terminaux existants. Cette seule capacité détermine souvent si une migration vers la voix chiffrée est possible sans remplacer l’infrastructure existante.

Relais SRTP

Pour les scénarios de chiffrement de bout en bout, le SBC doit pouvoir faire transiter les médias chiffrés sans les déchiffrer.

Architecture B2BUA

La terminaison et la ré-émission complètes du SIP sur chaque segment permettent des contextes de chiffrement indépendants. Les SBC basés sur un proxy SIP ne peuvent pas offrir le même niveau de contrôle du chiffrement.

Paramètres TLS configurables

Les ports, les suites de chiffrement, les versions TLS et la gestion des certificats doivent tous être configurables, pas codés en dur.

Outils de diagnostic intégrés

La capture de paquets en direct et les capacités de trace SIP sur le SBC lui-même sont essentielles pour dépanner les problèmes de chiffrement sans déployer une infrastructure de surveillance externe.

Questions fréquemment posées