# Neither Denied nor Exposed: Fixing WebRTC Privacy Leaks
## 3 WebRTC Background  
Before explaining how a malicious user can exploit any browser offering WebRTC capabilities, we should describe in detail how WebRTC works. Let's consider an example with two users, [PERSON] and [PERSON], who both use a WebRTC client, and [PERSON] wishes to call [PERSON] (Figure 3). To create a P2P connection, [PERSON] needs to generate a Session Description Protocol (SDP) [13] offer. Note that SDP is a format  
Figure 4: Using a TURN server. protocol intended to describe media details, transport addresses, and any other session description metadata to the peers. In our example, the SDP message is sent between the peers, using HTTP or WebSockets. That is, [PERSON] and [PERSON] have to exchange SDP data using the existing signaling channel in order to negotiate audio and video media parameters, such as media codecs and video resolution. Additional information regarding setting up, updating, and tearing down the WebRTC session, such as transport addresses and related metadata, will also be exchanged using SDP. This process is initiated along with the creation of an RTCPeerConnection object as explained in Section 2. The SDP offer includes information about [PERSON]'s network connection, and as [PERSON]'s data may follow different communication paths before they reach the outside, this offer must contain the shortest and most efficient network path. This is where ICE is applied to help gather the different nodes of [PERSON]'s network, known as ICE candidates. The reason why the SDP offer is vital in this step is that it includes all the ICE candidates that [PERSON] can use for communicating with [PERSON], along with others, important for the call information. For building the list of ICE candidates, [PERSON] makes a STUN request to a STUN server which is expected to respond with her public IP address and port(s). At this point, the STUN server allows [PERSON]'s client to discover its public IP address and, say, the type of NAT it is behind from, by sending back to her a success response which contains all the appropriate information. All in all, every node that forwards [PERSON]'s traffic from the local network to the Internet is considered an ICE candidate, and the whole process of IP and port identification is called ICE candidate gathering. There are three types of candidates:  
1. **Host Candidate**: Contains the private IP address and local UDP and TCP ports which are associated with the user's local interface. They are generated by the client itself. 2. **Server Reflexive Candidate**: Contains the public IP address and UDP and TCP port of the user that is returned by the STUN server. In contrast to Host Candidate, the client sends query messages to the STUN server, which will pass through the NAT, creating a NAT binding that is a public-private IP address mapping. The response contains the public IP and port (IP:port) generated for the binding. 3. **Relayed Candidate**: Similar to Server Reflexive Candidate, this type of candidate contains the translated public address of the user; however, the NAT binding is obtained by a TURN server, instead of a STUN. An example of an SDP message after an \"RTCPeerConnection\" initiation procedure is presented in Listing 2. As observed from the listing, three different candidates were gathered. The first one consists of the user's interface (private) IP address, along with the port the browser is listening to. In this case, if the remote peer, i.e., the callee, is part of the same intranet this candidate will be selected, and the Real-time Transport Protocol (RTP), which is the protocol used for delivering audio and video, will run over UDP. The second candidate is identical to the first; however, TCP will be used instead of UDP. The last candidate is a reflexive one, as a STUN server was used to return the user's public IP:port. Therefore, it is a lower priority candidate, but it will be nonetheless probed if the peers reside in different networks.