Een veilig gesprek heeft meer dan één gegevenspad. Signalering coördineert wie belt en hoe eindpunten verbinding maken; het mediapad vervoert audio en video. Bescherming van het ene pad beschermt niet automatisch het andere, en geen van beide verbergt op zichzelf alle communicatiepatronen.
WebRTC biedt belangrijke beveiligingsmechanismen, maar de identiteitscontroles van een applicatie, de rollen van servers en de opnamemodus bepalen nog steeds de volledige privacygrens.
Signalering en media hebben verschillende taken
| Laag | Gebruikelijk doel | Beveiligingsvraag |
|---|---|---|
| Signalering | Uitnodigingen, sessiebeschrijvingen en verbindingskandidaten | Wie kan de instelinformatie lezen of veranderen, en hoe wordt de beoogde gesprekspartner geauthenticeerd? |
| Media | Audio, video en bijbehorende realtime streams | Waar eindigt de versleuteling, en welke eindpunten hebben toegang tot de media? |
| Operationele records | Routering, verbindingstijden en afleverstatus | Welke metadata kan de dienst of het netwerk waarnemen? |
| Opname | Een kopie maken die wordt bewaard | Wie ontvangt leesbare inhoud of bruikbare opnamesleutels, en waar wordt de kopie opgeslagen? |
Een berichtenprotocol kan versleutelde signalering vervoeren, maar WebRTC vereist niet universeel het envelopformaat van een specifieke berichtenapp. Andere geauthenticeerde ontwerpen zijn mogelijk.
Wat DTLS-SRTP biedt
De WebRTC-beveiligingsarchitectuur, RFC 8827, vereist bescherming van mediakanalen en beschrijft het opzetten van DTLS-SRTP-sleutels. Vereenvoudigd gezegd helpt DTLS de cryptografische context tot stand te brengen, en beschermt SRTP de realtime mediapakketten.
De eindpunten van die bescherming zijn belangrijk. Een directe versleutelde verbinding tussen deelnemers verschilt van een verbinding die eindigt bij een server die media verwerkt. Sommige systemen voor meerdere deelnemers voegen een afzonderlijke end-to-endlaag toe boven op de transportversleuteling naar de server. Het woord ‘WebRTC’ alleen vertelt niet welke architectuur een product gebruikt.
Waarom authenticatie van signalering belangrijk is
Het opzetten van een gesprek kan informatie bevatten waarmee de mediaverbinding aan de beoogde partij wordt gekoppeld. Als een aanvaller die informatie ongemerkt kan vervangen, kan versleuteling een beschermde verbinding met het verkeerde eindpunt tot stand brengen.
RFC 8827 bespreekt deze relatie tussen signalering, identiteiten en DTLS-vingerafdrukken. HTTPS beschermt een verbinding met de signaleringsdienst; het neemt op zichzelf niet de noodzaak weg om rekening te houden met een kwaadwillende of gecompromitteerde dienst. End-to-end geauthenticeerde signalering of een geschikt onafhankelijk mechanisme voor verificatie van de gesprekspartner kan die grens versterken.
Vertrouwelijkheid van signalering is een verwant maar ander doel: het beperkt wie insteldetails kan lezen. Een ontwerp moet zowel vertrouwelijkheid als authenticatie uitleggen, in plaats van een versleuteld gegevensblok als afdoende bewijs voor beide te behandelen.
Versleutelde signalering maakt een gesprek niet onzichtbaar
De relay kan nog steeds weten tussen welke accounts of apparaten hij routeert. Netwerkwaarnemers kunnen verbindingstijden, verkeersvolume en serveradressen zien. Gesprekspartners of relay-infrastructuur kunnen afhankelijk van het verbindingsontwerp ook netwerkinformatie te weten komen.
Het versleutelen van een gespreksuitnodiging bewijst daarom niet dat de dienst geen gesprek kan afleiden, relaties in kaart kan brengen of gespreksgerelateerde records kan bewaren. Inhoud verbergen en verkeerspatronen verbergen zijn afzonderlijke problemen.
De door Livara gepubliceerde grens
De beveiligingspagina van Livara beschrijft directe en groepsgesprekken als end-to-endversleuteld, maar maakt een uitdrukkelijke uitzondering voor optionele serveropnamen: zolang de zichtbare REC-status actief is, gebruikt het gesprek transportversleuteling in plaats van E2EE.
Het dreigingsmodel wijst ook claims over anonimiteit van metadata en bescherming tegen een gecompromitteerd apparaat af. Dit zijn productuitspraken, geen onafhankelijke verificatie van elk gesprekspad. Deze gids beweert geen ongeverifieerde deelnemerslimiet, signaleringsformaat of postkwantumimplementatie voor media.
Een postkwantumsleuteluitwisseling van een berichtenapp verbetert met name niet automatisch een afzonderlijke WebRTC-mediahandshake. De algoritmen en sleutelbinding op het mediapad moeten onafhankelijk worden beoordeeld.
Vóór een gevoelig gesprek
- Bevestig de deelnemers en bekijk onverwachte identiteitswijzigingen.
- Controleer of opname is ingeschakeld en wat er volgens de applicatie daardoor verandert.
- Begrijp of de dienst media verwerkt of alleen beschermde pakketten doorstuurt.
- Houd rekening met de apparaten en ruimtes rond deelnemers: malware, schermopnamen of iemand in de buurt die meeluistert kunnen inhoud na ontsleuteling blootleggen.
- Vraag om architectuur- en testbewijs voor precies de modus die u gebruikt, in plaats van te vertrouwen op een algemeen label ‘versleutelde gesprekken’.
Een nuttige beveiligingsclaim vermeldt afzonderlijk wie toegang heeft tot signalering, media, metadata en opnamen.
