Is WebRTC veilig? Zo beschermt peer-to-peer presenteren je content

“Is WebRTC veilig?” is zo’n vraag die simpel klinkt maar een degelijk antwoord verdient, zeker als je er binnenkort een bestuurspresentatie, investeerdersgesprek of klantpitch doorheen laat lopen. Kort gezegd: ja, dat zit in het ontwerp. Maar het eerlijke antwoord legt ook uit waarom, want “het is een webstandaard” is op zichzelf eigenlijk geen argument.

WebRTC is de technologie achter de meeste moderne peer-to-peer-tools voor video en bediening, waaronder de verbinding tussen de telefoon van een presentator en de computer waarop de slides draaien in Cliqer. Als je begrijpt wat het wel en niet beschermt, kun je elke tool die het gebruikt beter beoordelen, niet alleen de onze.

Wat WebRTC precies is

WebRTC (Web Real-Time Communication) is een open standaard die wordt beheerd door het W3C en die native wordt ondersteund in elke grote browser. De standaard beschrijft hoe twee apparaten een directe verbinding kunnen opzetten om audio, video of willekeurige data uit te wisselen, zonder dat een van beide kanten een plug-in hoeft te installeren. De technische specificatie en achtergrond lees je op webrtc.org.

Het sleutelwoord is “direct”. Anders dan bij een videogesprek dat volledig via de servers van een bedrijf loopt, is WebRTC gebouwd om twee apparaten zo direct met elkaar te verbinden als het netwerk toelaat, en valt het alleen terug op een relay als een direct pad niet mogelijk is. Die ene ontwerpkeuze is de reden dat de rest van dit artikel ertoe doet: een protocol dat draait om directe verbindingen vraagt om een ander beveiligingsmodel dan een protocol dat rond een centrale server is gebouwd, en het loont om beide kanten te begrijpen voordat je het de content van een bestuurskamer toevertrouwt.

Versleuteling is niet optioneel in WebRTC

Dit is het deel dat de beveiligingsvraag echt beantwoordt. WebRTC biedt geen onversleutelde modus. Elke WebRTC-verbinding, of die nu een datakanaal, audio of video draagt, is standaard versleuteld:

• DTLS (Datagram Transport Layer Security) beveiligt datakanalen, de verbinding met lage latency voor zaken als commando’s om naar de volgende slide te gaan en de positie van de aanwijzer.
• SRTP (Secure Real-time Transport Protocol) beveiligt alle audio- en videomedia, zoals een schermdeling of camerafeed.
• De eerste handshake die een verbinding opzet, signaling genoemd, loopt apart via WSS (WebSocket Secure), dus ook de coördinatiestap is versleuteld, nog voordat de peer-to-peer-verbinding bestaat.

Er is geen configuratie-instelling om dit uit te zetten. Het zit ingebakken in de standaard, en dat is een wezenlijk andere garantie dan “we hebben ervoor gekozen versleuteling in te schakelen”, omdat het niet ongemerkt verkeerd geconfigureerd kan worden.

Peer-to-peer versus via een server: waarom het uitmaakt voor je content

Omdat WebRTC apparaten direct verbindt, heeft een applicatie die erop is gebouwd een echte keuze die tools met serverroutering niet hebben: of content überhaupt ooit een server hoeft te raken. In Cliqer reizen commando’s om naar de volgende slide te gaan, coördinaten van de laserpointer, de timerstatus en elke scherm- of camerastream rechtstreeks tussen het apparaat van de presentator en de hostcomputer, of via een versleutelde relay als er geen direct pad beschikbaar is. De applicatieservers coördineren wie er in de ruimte zit; ze zitten nooit in het mediapad zelf, en je presentatiecontent wordt nooit geüpload.

Die architectuur is vooral belangrijk voor alles wat gevoelig is: bestuursdecks, productroadmaps, nog niet gepubliceerde financiële cijfers. Op dat specifieke geval gaan we dieper in bij vertrouwelijke content presenteren.

Waar de relay in beeld komt

Niet elk netwerk staat een directe verbinding toe. Bedrijfsfirewalls, hotelwifi en carrier-grade NAT kunnen allemaal het directe pad blokkeren waar WebRTC de voorkeur aan geeft. Gebeurt dat, dan valt de verbinding terug op een TURN-relay, die dezelfde met DTLS en SRTP versleutelde pakketten doorstuurt zonder de sleutels te hebben om ze te ontsleutelen. De relay verplaatst bytes; lezen kan hij ze niet.

Hoe die fallback precies werkt, en waarom het geen achteruitgang in beveiliging is, lees je in TURN-servers uitgelegd. Het is ook de reden dat bedrijfsfirewalls een goed gebouwde WebRTC-tool zelden volledig blokkeren, een onderwerp dat we behandelen in waarom bedrijfsfirewalls presentatietools blokkeren.

Waar WebRTC niet tegen beschermt

Versleuteling tijdens transport is niet het hele beveiligingsverhaal, en het is goed om eerlijk te zijn over wat het niet dekt:

Zelf controleren

Je hoeft hiervoor niet op het woord van een leverancier te vertrouwen. Een paar praktische controles:

1. Vraag om een dataflowdiagram, geen marketingpagina, en controleer welke datastromen peer-to-peer zijn en welke via een server lopen.
2. Controleer of de app inkomende firewallregels vereist. Een goed gebouwde WebRTC-app hoort alleen uitgaande verbindingen nodig te hebben.
3. Vraag wat er gebeurt op een netwerk dat directe verbindingen blokkeert. Er hoort een versleutelde relay-fallback te zijn, geen harde storing.
4. Lees de documentatie over beveiliging en netwerken voor de specifieke poorten en protocollen die worden gebruikt.

Beoordeel je een tool voor een heel team in plaats van voor één gesprek, neem dit dan mee in de bredere beveiligingschecklist voor presentatiesoftware, want versleuteling is maar één van de vele punten die een degelijke beoordeling hoort te behandelen.

Veelgestelde vragen

Aan de slag

Als versleuteling en peer-to-peer-routing meewegen in hoe je presentatietools beoordeelt, lees dan het volledige beveiligingsoverzicht, of probeer Cliqer gratis en bekijk zelf hoe de verbinding zich gedraagt voordat je er iets gevoeligs mee presenteert.