In most cases, packets from one peer can reach the other by heading toward the other peer's NAT. The NAT mapping address can be acquired and established via a STUN service.
If one of the peers is behind a symmetric NAT, we may need to use a relay server (TURN) to deliver the packets. Therefore, there may be concerns about whether this relay server can inspect the packets passing through it.
This understanding is important because it affects the decision of whether to choose an readily available “Network Traversal Service” or a self-provided TURN service.
Public medium
Since the audio packets sent by the peer must pass through the public Internet (NATs, routers) before reaching the other peer, the packets must be encrypted against malicious attacks to prevent the contents of the packets from being viewed. Therefore, WebRTC uses “DTLS-SRTP” to ensure that only peers can see the contents of the packets.
DTLS-SRTP
DTLS is based on top of UDP and also includes handshake, certificate exchange, key exchange, etc. With DTLS, data can be transmitted securely via UDP through the insecure public medium. DTLS is the first step after the signaling process in WebRTC. Given the ICE candidates, the peers begin the handshake and it should be noted that the fingerprint exchanged during the signaling process is used to verify the authenticity of the certificates in DTLS.
After the DTLS process, the peer pair can communicate securely with each other using the secret shared between them. Subsequently, WebRTC extracts a key from the DTLS layer and uses this key as input for SRTP encryption to ensure that the audio packets are encrypted in SRTP. The key is used until the “re-handshake and re-key.”
Rehandshake and Rekey
The lifetime of the encryption key used for SRTP is specified in the “maximum_lifetime” parameter in the SRTP profile. When this lifetime is reached, a new handshake is performed within the existing secure channel, and once the rehandshake is complete, the new key is used.
Relay medium
The TURN server cannot inspect audio packets between peers because WebRTC sets up DTLS between peers and the TURN server only forwards the payload. The DTLS-SRTP mechanism protects the data from access by any medium on the data path. Only peers can decrypt the packets.
WebRTC peers use three types of transport with relay servers:
-
UDP
-
TCP
-
TLS-over-TCP
Failed to load the diagram preview image.
Authentication Required
Page ID: 1644790167
UDP Transport
The payload sent by the TURN client (within the NAT) to the TURN server in UDP format initially consists of DTLS handshake messages and is forwarded to the peer in UDP format. Once the handshake is complete, the SRTP encryption key is extracted so that the peer can send SRTP to the TURN, which then forwards it.
TCP Transport
The TURN client establishes a TCP connection with the TURN server and begins sending the payload data via the TCP connection. At the beginning, the payload data is still intended for setting up DTLS with the peer. The encryption key is then extracted and the TURN client sends the SRTP as payload data in the TCP connection. The TURN server forwards the SRTP as soon as it receives it.
TLS-over-TCP Transport
This process is fully integrated into a TLS-over-TCP channel, which means that the audio packets between the TURN client and the TURN server are double-encrypted. After the TURN server has decrypted the TLS packet, the payload remains SRTP-encrypted. The TURN server forwards this SRTP in UDP format to the peer.
Summary
The relay server only forwards the payload. The security of the payload depends on a different mechanism. In the WebRTC scenario, DTLS-SRTP is used to ensure confidentiality and authenticity when communicating over the Internet.
Reference