4. Sécurité pour les applications WebRTC

Les applications WebRTC déterminent les politiques de sécurité pour les sessions qu'elles créent. Cette section décrit les mécanismes de sécurité disponibles pour les applications et comment ils devraient être utilisés.

4.1 Consentement à envoyer

Pour prévenir les attaques "carte d'appel" (Section 3.1), WebRTC exige que le point de terminaison récepteur consente explicitement à recevoir du trafic. Ceci est accompli via le protocole Interactive Connectivity Establishment (ICE) [RFC8445]. Avant d'envoyer tout trafic non-ICE à une destination, un point de terminaison WebRTC DOIT vérifier que la destination a répondu à une requête de liaison STUN ICE. Cela prouve que la destination est active et disposée à recevoir du trafic sur ce port.

4.2 Consentement pour accéder aux appareils locaux

Pour prévenir l'espionnage (Section 3.2), les navigateurs DOIVENT exiger le consentement explicite de l'utilisateur avant de permettre à un site d'accéder à la caméra ou au microphone. Ce consentement DEVRAIT être spécifique à l'origine demandant l'accès et DEVRAIT être révocable.

4.3 Communication sécurisée

Pour assurer la confidentialité et l'intégrité, tout le trafic média et de données WebRTC DOIT être chiffré et authentifié.

Pour les médias (audio/vidéo), SRTP [RFC3711] est utilisé, avec des clés établies via DTLS-SRTP [RFC5764].
Pour les canaux de données, SCTP sur DTLS [RFC8261] est utilisé.

Cela garantit que les attaquants sur le chemin réseau ne peuvent pas lire ou modifier la communication.

4.4 Identité

Bien que DTLS fournisse l'authentification du canal, il n'identifie pas de manière inhérente l'utilisateur à l'autre extrémité. WebRTC fournit des mécanismes pour les "Fournisseurs d'Identité" (Identity Providers, IdPs) pour affirmer l'identité des utilisateurs et lier ces identités aux certificats DTLS utilisés pour l'appel. Cela permet aux utilisateurs de vérifier avec qui ils communiquent, indépendamment du service de signalisation.