Una chiamata sicura ha più di un percorso di dati. La segnalazione coordina chi sta chiamando e come si collegano gli endpoint; il percorso dei media trasporta audio e video. Proteggere un percorso non protegge automaticamente l’altro, e nessuno dei due da solo nasconde tutti gli schemi di comunicazione.
WebRTC offre importanti meccanismi di sicurezza, ma le verifiche d’identità dell’applicazione, i ruoli dei server e la modalità di registrazione determinano comunque il confine completo della privacy.
Segnalazione e media svolgono compiti diversi
| Livello | Scopo tipico | Domanda sulla sicurezza |
|---|---|---|
| Segnalazione | Inviti, descrizioni della sessione e candidati di connessione | Chi può leggere o alterare le informazioni di configurazione e come viene autenticato l’interlocutore previsto? |
| Media | Audio, video e flussi correlati in tempo reale | Dove termina la cifratura e quali endpoint possono accedere ai media? |
| Registri operativi | Instradamento, tempi di connessione e stato di recapito | Quali metadati può osservare il servizio o la rete? |
| Registrazione | Produrre una copia da conservare | Chi riceve testo in chiaro o chiavi di registrazione utilizzabili e dove viene archiviata la copia? |
Un protocollo di messaggistica può trasportare segnalazione cifrata, ma WebRTC non richiede universalmente il formato di involucro di uno specifico servizio di messaggistica. Sono possibili altri progetti autenticati.
Cosa offre DTLS-SRTP
L’architettura di sicurezza WebRTC, RFC 8827, richiede la protezione dei canali media e descrive l’instaurazione delle chiavi DTLS-SRTP. Semplificando, DTLS contribuisce a stabilire il contesto crittografico e SRTP protegge i pacchetti media in tempo reale.
Gli estremi di questa protezione contano. Una connessione cifrata diretta tra partecipanti è diversa da una connessione che termina su un server di elaborazione dei media. Alcuni sistemi multiparte aggiungono un livello end-to-end separato sopra la cifratura di trasporto verso il server. La sola parola «WebRTC» non indica quale architettura utilizzi un prodotto.
Perché conta l’autenticazione della segnalazione
L’instaurazione di una chiamata può contenere informazioni usate per legare la connessione dei media all’interlocutore previsto. Se un attaccante può sostituirle senza essere rilevato, la cifratura può creare una connessione protetta con l’endpoint sbagliato.
RFC 8827 discute questa relazione fra segnalazione, identità e impronte DTLS. HTTPS protegge una connessione al servizio di segnalazione; da solo non elimina la necessità di considerare un servizio malevolo o compromesso. La segnalazione autenticata end-to-end o un meccanismo indipendente appropriato di verifica dell’interlocutore possono rafforzare questo confine.
La riservatezza della segnalazione è un obiettivo collegato ma diverso: limita chi può leggere i dettagli dell’instaurazione. Un progetto dovrebbe spiegare sia riservatezza sia autenticazione, invece di considerare un blocco cifrato come prova sufficiente di entrambe.
La segnalazione cifrata non rende invisibile una chiamata
Il relay può ancora sapere fra quali account o dispositivi effettua l’instradamento. Gli osservatori della rete possono vedere tempi di connessione, volume del traffico e indirizzi dei server. Anche gli interlocutori o l’infrastruttura di relay possono apprendere informazioni di rete a seconda del progetto della connessione.
Di conseguenza, cifrare un invito a una chiamata non dimostra che il servizio non possa dedurre una chiamata, mappare relazioni o conservare registri relativi alle chiamate. Nascondere il contenuto e nascondere gli schemi di traffico sono problemi separati.
Il confine pubblicato da Livara
La pagina sulla sicurezza di Livara descrive le chiamate dirette e di gruppo come cifrate end-to-end, ma fa un’eccezione esplicita per la registrazione opzionale sul server: mentre lo stato visibile REC è attivo, la chiamata usa la cifratura di trasporto anziché E2EE.
Il suo modello di minaccia esclude inoltre promesse di anonimato dei metadati e di protezione da un dispositivo compromesso. Sono dichiarazioni sul prodotto, non una verifica indipendente di ogni percorso di chiamata. Questa guida non afferma limiti di partecipanti, formati di segnalazione o implementazioni post-quantistiche dei media non verificati.
In particolare, uno scambio di chiavi post-quantistico del servizio di messaggistica non aggiorna automaticamente un handshake separato dei media WebRTC. Gli algoritmi e il legame delle chiavi sul percorso dei media devono essere valutati indipendentemente.
Prima di una chiamata sensibile
- Confermate i partecipanti ed esaminate i cambi d’identità inattesi.
- Controllate se la registrazione è attiva e cosa, secondo l’applicazione, cambia quando lo è.
- Comprendete se il servizio elabora i media o inoltra soltanto pacchetti protetti.
- Considerate i dispositivi e le stanze attorno ai partecipanti: malware, acquisizioni dello schermo o una persona nelle vicinanze che ascolta possono esporre il contenuto dopo la decifratura.
- Chiedete prove dell’architettura e dei test per la modalità esatta che usate, invece di affidarvi a un generico distintivo «chiamate cifrate».
Un’affermazione di sicurezza utile identifica separatamente chi può accedere a segnalazione, media, metadati e registrazioni.
