Abstract
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.
Highlights
The need for enabling Peer-to-Peer (P2P) communication without the requirement of providing extra extensions or native apps to the peers has been of utmost importance for years
Web Real-Time Communication (WebRTC) is supported by companies such as Google, Microsoft, Mozilla, and Opera, and, despite WebRTC’s popularity [2,3], a significant privacy issue remains unresolved: the IP addresses, both private and public, of each client visiting a website which is capable of performing a WebRTC peer connection request, can be potentially revealed to the website host
We consider an adversary with the following capabilities: (1) they can intercept, modify, or inject any message in the public communication channels; (2) they adhere to all cryptographic assumptions, e.g., an adversary is not able to decrypt an encrypted message without knowledge of the decryption key; (3) they are able to setup and operate their own Session Traversal Utilities for NAT (STUN)/Traversal using Relays around NAT (TURN) server; (4) they are able to inject JavaScript code to any webpage; (5) they can lure individuals into visiting certain webpages by, say, exercising social engineering techniques
Summary
The need for enabling Peer-to-Peer (P2P) communication without the requirement of providing extra extensions or native apps to the peers has been of utmost importance for years. WebRTC is supported by companies such as Google, Microsoft, Mozilla, and Opera, and, despite WebRTC’s popularity [2,3], a significant privacy issue remains unresolved: the IP addresses, both private and public, of each client visiting a website which is capable of performing a WebRTC peer connection request, can be potentially revealed to the website host This enables malicious sites to attack clients which would otherwise be inaccessible, e.g., behind a firewall or NAT. In case the client is behind a NAT gateway, NAT maps the device’s private IP address to a public IP address and forwards each request to the server and each response back to the client When it comes to P2P services like video telephony where both devices, i.e., the caller and callee, are behind different NAT gateways, an obstacle arises when trying to establish the connection. The last section concludes and provides some pointers for future work
Sign-in/Register to view highlights & summary Sign-in/Register to access full text options 
Free) 
Talk to us
Join us for a 30 min session where you can share your feedback and ask us any queries you have
Schedule a call
