WebRTC est-il sécurisé ? Comment la présentation peer-to-peer protège votre contenu

« WebRTC est-il sécurisé ? » fait partie de ces questions qui paraissent simples mais méritent une vraie réponse, surtout si vous êtes sur le point d'y faire passer une présentation au conseil d'administration, un appel avec des investisseurs ou un pitch client. La réponse courte est oui, par conception. Mais la réponse honnête explique pourquoi, car « c'est un standard du web » n'est pas, à lui seul, un argument.

WebRTC est la technologie qui se cache derrière la plupart des outils modernes de vidéo et de contrôle en peer-to-peer, y compris la connexion entre le téléphone d'un présentateur et l'ordinateur qui affiche ses diapositives dans Cliqer. Comprendre ce qu'elle protège, et ce qu'elle ne protège pas, vous permettra de mieux juger n'importe quel outil qui l'utilise, pas seulement le nôtre.

Ce qu'est réellement WebRTC

WebRTC (Web Real-Time Communication) est un standard ouvert maintenu par le W3C et pris en charge nativement par tous les principaux navigateurs. Il définit comment deux appareils peuvent établir une connexion directe pour échanger de l'audio, de la vidéo ou des données quelconques, sans qu'aucun des deux n'ait besoin d'installer un plugin. Vous trouverez la spécification technique et le contexte sur webrtc.org.

Le mot clé est « direct ». Contrairement à un appel vidéo entièrement acheminé par les serveurs d'une entreprise, WebRTC est conçu pour relier deux appareils l'un à l'autre aussi directement que le réseau le permet, et ne bascule sur un relais que lorsqu'un chemin direct est impossible. Ce seul choix de conception explique l'importance du reste de cet article : un protocole bâti autour de connexions directes exige un modèle de sécurité différent de celui d'un protocole bâti autour d'un serveur central, et il vaut la peine de comprendre ces deux aspects avant de lui confier le contenu d'une salle de conseil.

Dans WebRTC, le chiffrement n'est pas optionnel

C'est ici que se trouve la véritable réponse à la question de la sécurité. WebRTC ne propose aucun mode non chiffré. Chaque connexion WebRTC, qu'elle transporte un canal de données, de l'audio ou de la vidéo, est chiffrée par conception :

• DTLS (Datagram Transport Layer Security) sécurise les canaux de données, le canal à faible latence utilisé notamment pour les commandes de changement de diapositive et la position du pointeur.
• SRTP (Secure Real-time Transport Protocol) sécurise tous les flux audio ou vidéo, comme un partage d'écran ou le flux d'une caméra.
• La négociation initiale qui établit la connexion, appelée signalisation, passe séparément par WSS (WebSocket Secure) : l'étape de coordination est donc elle aussi chiffrée, avant même que la liaison peer-to-peer n'existe.

Aucun paramètre de configuration ne permet de désactiver ce chiffrement. Il est intégré au standard, ce qui constitue une garantie sensiblement différente de « nous avons choisi d'activer le chiffrement », car il ne peut pas être discrètement mal configuré.

Peer-to-peer ou routage par serveur : pourquoi c'est important pour le contenu

Comme WebRTC relie directement les appareils, une application qui repose sur lui dispose d'un véritable choix que les outils routés par serveur n'ont pas : décider si le contenu doit un jour transiter par un serveur. Dans Cliqer, les commandes de changement de diapositive, les coordonnées du pointeur laser, l'état du minuteur et tout flux d'écran ou de caméra circulent directement entre l'appareil du présentateur et l'ordinateur hôte, ou via un relais chiffré si aucun chemin direct n'est disponible. Les serveurs applicatifs coordonnent qui se trouve dans la salle ; ils ne se trouvent jamais sur le chemin des médias, et le contenu de votre présentation n'est jamais téléversé.

Cette architecture compte surtout pour tout ce qui est sensible : présentations au conseil d'administration, feuilles de route produit, résultats financiers non publiés. Nous approfondissons ce cas précis dans présenter du contenu confidentiel.

Le rôle du relais

Tous les réseaux ne permettent pas une connexion directe. Les pare-feu d'entreprise, le Wi-Fi des hôtels et le NAT des opérateurs (CGNAT) peuvent tous bloquer le chemin direct que privilégie WebRTC. Dans ce cas, la connexion bascule sur un relais TURN, qui transmet les mêmes paquets chiffrés en DTLS et SRTP sans détenir les clés permettant de les déchiffrer. Le relais transporte des octets ; il ne peut pas les lire.

Nous expliquons précisément le fonctionnement de ce repli, et pourquoi il ne dégrade pas la sécurité, dans les serveurs TURN expliqués. C'est aussi pour cette raison que les pare-feu d'entreprise bloquent rarement un outil WebRTC bien conçu, un sujet que nous abordons dans pourquoi les pare-feu d'entreprise bloquent les outils de présentation.

Ce contre quoi WebRTC ne protège pas

Le chiffrement en transit ne résume pas à lui seul la sécurité, et il est bon d'être honnête sur ce qu'il ne couvre pas :

Comment le vérifier vous-même

Inutile de croire un éditeur sur parole. Quelques vérifications pratiques :

1. Demandez un schéma des flux de données, pas une page marketing, et vérifiez quels flux sont en peer-to-peer et lesquels passent par un serveur.
2. Vérifiez si l'application exige des règles de pare-feu entrantes. Une application WebRTC bien conçue ne devrait avoir besoin que de connexions sortantes.
3. Demandez ce qui se passe sur un réseau qui bloque les connexions directes. Il doit exister un repli via un relais chiffré, pas un échec pur et simple.
4. Lisez la documentation Sécurité et réseau pour connaître les ports et protocoles précis utilisés.

Si vous évaluez un outil pour toute une équipe plutôt que pour un seul appel, intégrez ces points à la checklist de sécurité pour logiciels de présentation, plus complète, car le chiffrement n'est qu'un des nombreux critères qu'un véritable audit doit couvrir.

FAQ

Commencer

Si le chiffrement et le routage peer-to-peer comptent dans votre évaluation des outils de présentation, lisez la présentation complète de la sécurité, ou essayez Cliqer gratuitement et examinez vous-même le comportement de la connexion avant de l'utiliser pour présenter quoi que ce soit de sensible.