# Neither Denied nor Exposed: Fixing WebRTC Privacy Leaks
## 1 Introduction  
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. In 2011, WebRTC [1] was developed, offering high-quality real-time communication between web browsers, mobile applications, and IoT devices. WebRTC uses JavaScript Application Programming Interfaces (APIs), defined by the World Wide Web Consortium (W3C) for enabling multi-platform voice, text, and video communications. Typically, WebRTC is used for realizing real-time audio and video calls, web conferencing between a number of peers, and even direct file transfers, without the need for extra extensions or additional applications. The biggest benefit of this technology is that the whole communication is achievedvia a typical web browser, like Chrome or Mozilla. Although 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. It is worth noting here that such an attack is not possible due to vulnerabilities in the WebRTC protocol per se, but only by abusing its legitimate features. In more detail, any user browsing the web is able to visit a webpage or use services like sending an email. This is feasible, as web servers have either a public or a port-forwarded IP address, exchanging data with any device. Specifically, 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. However, 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. This is because, when the caller tries to initiate a session, the callee's NAT will not be aware of the callee behind it, and thus will drop the connection [1]. In order to bypass such impediments and explore different connection methods, WebRTC deploys some extra protocols. WebRTC allows media to get transferred between peers, regardless their network topology, even if the peers are behind NAT. Nevertheless, in order to successfully create a connection, each peer needs to dynamically generate and discover the most effective path for sending media to the rest of the peers. WebRTC achieves that by taking advantage of the ICE [4] framework. ICE uses two different methods, namely Session Traversal Utilities for NAT (STUN) [5] and Traversal using Relays around NAT (TURN) [6], to correspondingly assist with the user's browser identify their public IP address and port, and relay traffic if direct connection fails. A STUN server is used by a peer if the latter needs to identify its IP:port address information as seen from a public perspective, i.e., as it is generated by the NAT box closest to the server, while the TURN server acts as an intermediate when the peer's network forbids P2P connections. The response received by STUN is made available to the JavaScript code that initiated the request; since this code runs locally on the user's system, it has access to the private IP address of the user as well. This procedure is transparent to the end-user, so they are completely unaware of these STUN/TURN requests when they visit a webpage. An attacker is able to setup their own STUN/TURN server, forcing the user's browser to perform queries to this server, by placing a short JavaScript code to a webpage before the user visits it.