Neither Denied nor Exposed: Fixing WebRTC Privacy Leaks

To establish peer-to-peer connections and achieve real-time web-based communication, the Web Real-Time Communication (WebRTC) framework requires address information of the communicating peers. This means that users behind, say, Network Address Translation (NAT) or firewalls normally rely on the Interactive Connectivity Establishment (ICE) framework for the sake of negotiating information about the connection and media transferring. This typically involves Session Traversal Utilities for NAT (STUN)/Traversal using Relays around NAT (TURN) servers, which assist the peers with discovering each other’s private and public IP:port , and relay traffic if direct connection fails. Nevertheless, these IP:port pieces of data can be easily captured by anyone who controls the corresponding STUN/TURN server, and even more become readily available to the JavaScript application running on the webpage. While this is acceptable for a user that deliberately initiates a WebRTC connection, it becomes a worrisome privacy issue for those being unaware that such a connection is attempted. Furthermore, the application acquires more information about the local network architecture compared to what is exposed in usual HTTP interactions, where only the public IP is visible. Even though this problem is well-known in the related literature, no practical solution has been proposed so far. To this end, and for the sake of detecting and preventing in real time the execution of STUN/TURN clandestine, privacy-invading requests, we introduce two different kinds of solutions: (a) a browser extension, and (b) an HTTP gateway, implemented in C++ as well as in Golang. Both solutions detect any WebRTC API call before it happens and inform accordingly the end-user about the webpage’s intentions. We meticulously evaluate the proposed schemes in terms of performance and demonstrate that, even in the worst case, the latency introduced is tolerable.