La parola d'ordine

Bentornati sulle due rive. Il ponte ha un progetto, ha un guado, e se serve ha un traghetto. Oggi ci chiediamo: come fanno le due rive a essere sicure di parlare tra loro?

Il carico passa per strade che non controlliamo: la rete del bar, il router dell'operatore, il traghetto in mezzo al fiume. Chiunque lungo la strada potrebbe guardare dentro i carri, o peggio, fingersi l'altra riva. Serve una parola d'ordine.

La prima cosa da sapere è anche la più rassicurante: in WebRTC la cifratura è obbligatoria.

Non c'è un'opzione per mandare audio e video in chiaro. Non c'è un parametro da dimenticare. Ogni pacchetto di ogni chiamata WebRTC è cifrato, sempre, in tutti i browser. Gli autori dello standard lo hanno deciso fin dall'inizio, e l'architettura di sicurezza descritta nella RFC 8827 lo rende un requisito, non un suggerimento.

È una scelta che ha fatto discutere, perché alcuni sistemi di telefonia tradizionale non cifrano, e collegare WebRTC a quei sistemi richiede un passaggio intermedio. Ma è stata la scelta giusta. Il web ha impiegato vent'anni per passare all'HTTPS ovunque. WebRTC ci è nato.

La cifratura usa due protocolli, ognuno con il suo compito.

Il primo è DTLS, cioè la versione di TLS, il protocollo del lucchetto nel browser, adattata ai datagrammi di UDP. Appena ICE ha trovato il guado, le due rive fanno una stretta di mano DTLS attraverso quel guado. Si scambiano i certificati e concordano un segreto comune. Una cosa curiosa: questi certificati non sono emessi da un'autorità. Li genera il browser stesso, al volo, e sono autofirmati.

Il secondo è SRTP, la versione sicura del protocollo che trasporta audio e video in tempo reale. SRTP è veloce e leggero, ma non sa scambiare le chiavi da solo. Ed ecco l'accoppiata, descritta nella RFC 5764: le chiavi di SRTP vengono ricavate dal segreto concordato con DTLS. DTLS fa la stretta di mano, SRTP porta i carri sigillati. I canali dati, invece, viaggiano direttamente dentro DTLS.

Ma se i certificati sono autofirmati, come fa una riva a sapere che il certificato che riceve è davvero quello dell'altra riva?

Qui torna in gioco la lettera del messaggero. Ricordate l'attributo fingerprint nell'SDP? È l'impronta del certificato, un'impronta crittografica calcolata con SHA duecentocinquantasei. Ogni riva scrive nella propria lettera l'impronta del proprio certificato. Durante la stretta di mano DTLS, il browser controlla che il certificato ricevuto corrisponda all'impronta che era scritta nella lettera. Se non corrisponde, la connessione si interrompe.

È la parola d'ordine: ci siamo scambiati un segno di riconoscimento con il messaggero, e al ponte controlliamo che chi si presenta lo conosca.

Avrete già capito dov'è il punto debole.

Tutta la sicurezza della parola d'ordine dipende dal messaggero. Se qualcuno controlla il canale di segnalazione, può aprire le lettere e sostituire l'impronta con quella di un proprio certificato. Poi si mette in mezzo, fa una stretta di mano con ognuna delle due rive, e ascolta tutto. È il classico attacco dell'uomo nel mezzo, e la cifratura di WebRTC non lo impedisce, perché ognuna delle due rive vede un'impronta che corrisponde alla lettera ricevuta.

Chi può controllare il messaggero? Prima di tutto, il gestore del servizio. Se usate un'applicazione WebRTC, vi state fidando di chi gestisce il server di segnalazione. Poi, chiunque riesca a compromettere quel server, o il canale verso di esso. Per questo la segnalazione deve viaggiare sempre su un canale cifrato e autenticato, WebSocket sicuri o HTTPS, e il server di segnalazione va protetto come qualunque altro sistema critico.

Se volete fare un passo in più, potete fare come le applicazioni di messaggistica che mostrano un codice di sicurezza. Prendete le due impronte, le combinate, ne ricavate un numero breve, e chiedete alle due persone di confrontarlo a voce. Se coincide, nessuno ha sostituito la parola d'ordine. Nelle note c'è il codice per farlo.

La sicurezza non è solo cifratura. È anche quello che una pagina può sapere di voi.

Per usare microfono e videocamera serve il permesso esplicito dell'utente, e il browser mostra un indicatore finché sono attivi. La pagina deve essere in un contesto sicuro. Fin qui, tutto bene.

Poi ci sono gli indirizzi IP. Per costruire il ponte, ICE deve scambiare gli indirizzi con l'altra riva. Questo significa che l'altra persona, in una chiamata diretta, vede il vostro indirizzo IP pubblico. Per molti non è un problema. Per chi ha bisogno di nascondere la propria posizione, sì. In passato WebRTC rivelava anche l'indirizzo privato, e perfino quello reale di chi usava una VPN: era il famoso problema delle perdite di indirizzi tramite WebRTC. Oggi i browser lo hanno mitigato con i nomi mDNS di cui abbiamo parlato nel terzo episodio, e con regole più severe su quali schede di rete usare.

Se la vostra applicazione deve proteggere l'indirizzo degli utenti, la soluzione è semplice e costosa: forzare il traghetto, con la politica relay. Ognuna delle due rive vede solo l'indirizzo del server TURN.

C'è un'ultima sfumatura, ed è importante.

In una chiamata tra due persone, la cifratura di WebRTC è da un capo all'altro: solo le due rive hanno le chiavi. Anche il traghetto vede soltanto carri sigillati. Ma nelle chiamate di gruppo, come vedremo nell'ottavo episodio, c'è quasi sempre un server multimediale in mezzo. E quel server fa la stretta di mano DTLS con ogni partecipante. Quindi ha le chiavi. La cifratura diventa da punto a punto: dal vostro browser al server, e dal server agli altri.

Per tornare a una vera cifratura da un capo all'altro serve un secondo livello. Lo standard si chiama SFrame, RFC 9605, pubblicato nel 2024: ogni fotogramma viene cifrato dal mittente con una chiave che il server non conosce, prima ancora di entrare in SRTP. Il server vede i pacchetti, sa a chi inoltrarli, ma non sa cosa contengono. Per farlo, i browser espongono un'API chiamata Encoded Transform, che vi permette di mettere le mani sui fotogrammi codificati prima che partano. La parte difficile, come sempre, è distribuire le chiavi in modo sicuro tra i partecipanti.

Quindi, ricapitolando: in WebRTC la cifratura è obbligatoria. DTLS verifica l'altra riva e ricava le chiavi, SRTP sigilla i carri. La parola d'ordine è l'impronta del certificato scritta nella lettera, e per questo il messaggero è il punto da proteggere. Con un server in mezzo, per la cifratura da un capo all'altro serve SFrame.

Adesso il ponte è sicuro. Ma cosa ci passa sopra, esattamente? Nel prossimo episodio guardiamo i carri: audio, video, codec e il modo in cui WebRTC si adatta a una rete che cambia di continuo. Ci sentiamo lì.