4. Sicurezza per le applicazioni WebRTC

Le applicazioni WebRTC determinano le politiche di sicurezza per le sessioni che creano. Questa sezione descrive i meccanismi di sicurezza disponibili per le applicazioni e come dovrebbero essere utilizzati.

4.1 Consenso all'invio

Per prevenire gli attacchi "biglietto da visita" (Sezione 3.1), WebRTC richiede che l'endpoint ricevente acconsenta esplicitamente alla ricezione del traffico. Ciò si ottiene tramite il protocollo Interactive Connectivity Establishment (ICE) [RFC8445]. Prima di inviare qualsiasi traffico non ICE a una destinazione, un endpoint WebRTC DEVE verificare che la destinazione abbia risposto a una richiesta di binding STUN ICE. Ciò dimostra che la destinazione è attiva e disposta a ricevere traffico su quella porta.

4.2 Consenso all'accesso ai dispositivi locali

Per prevenire lo spionaggio (Sezione 3.2), i browser DEVONO richiedere il consenso esplicito dell'utente prima di consentire a un sito di accedere alla fotocamera o al microfono. Questo consenso DOVREBBE essere specifico per l'origine che richiede l'accesso e DOVREBBE essere revocabile.

4.3 Comunicazione sicura

Per fornire riservatezza e integrità, tutto il traffico multimediale e dati WebRTC DEVE essere crittografato e autenticato.

Per i media (audio/video), viene utilizzato SRTP [RFC3711], con chiavi stabilite tramite DTLS-SRTP [RFC5764].
Per i canali dati, viene utilizzato SCTP su DTLS [RFC8261].

Ciò garantisce che gli aggressori sul percorso di rete non possano leggere o modificare la comunicazione.

4.4 Identità

Mentre DTLS fornisce l'autenticazione del canale, non identifica intrinsecamente l'utente all'altra estremità. WebRTC fornisce meccanismi per "Identity Provider" (IdP) per affermare l'identità degli utenti e legare tali identità ai certificati DTLS utilizzati per la chiamata. Ciò consente agli utenti di verificare con chi stanno comunicando, indipendentemente dal servizio di segnalazione.