WebRTC in general is very secure and LiveSwitch follows the WebRTC spec. Here we discuss implementation specifics of LiveSwitch's security measures, as well as covering basic network related configuration.
Network Configuration and Required Port
- STUN servers provide a WAN address discovery service and listen on port 3478 by default, but any port can be used. Firewall rules must be added to allow inbound UDP traffic on the configured port.
- TURN servers extend STUN to support relaying around restrictive firewall rules. Like STUN, they listen on port 3478 by default, but any port can be used. Firewall rules must be added to allow inbound UDP and/or TCP traffic on the configured port.
- TURNS servers extend TURN by using TLS (SSL) to secure the underlying TCP connection. Since app data is already encrypted, this simply adds a layer of security on the TURN headers, but is useful to traverse firewalls that only allow TLS/SSL traffic. TURNS servers listen on port 5349 by default, but any port can be used. Port 443 is recommended since it is generally allowed by client networks. Firewall rules must be added to allow inbound TCP traffic on the configured port.
- Clients are the originator of requests and as such, they require no special firewall rules, provided outbound traffic is allowed.
- Media Server clustering requires TCP traffic on port 8445. If 8445 is unavailable the next port will be tried incrementally until one is available (that is, 8446, 8447, 8448, 8449, etc).
- Media Server client connections require inbound UDP traffic on ports 49152-65535 on public interfaces.
- The SIP Connector requires TCP/UDP traffic on port 5060 on public interfaces.
Even the most restrictive corporate networks generally allow HTTP traffic on port 80 and TLS/SSL traffic on port 443 for HTTPS. For this reason, we recommend running a TURN server that listens on port 443 for TURNS.
All connections are secured using DTLS. Secure X.509 certificates are automatically generated for each connection using ECDSA (default, P-256 curve) or RSA (2048-bit) signing, but custom certificates and key-pairs can be provided. Certificate fingerprints (used to verify the peer during key exchange) are exchanged via signaling in the SDP blobs, so it is imperative to ensure security at the signaling layer.
- DTLS 1.2 with support for cipher suites that support perfect forward secrecy (PFS). See below for the specific cipher suites allowed by the key exchange.
- Certificates use ECDSA signing with keys generated for the P-256 curve.
- Certificates can use RSA signing with variable key length (default is 2048 bits).
- Data is encrypted using AES 128-bit encryption with 80-bit message authentication per SRTP standards.
- Certificate fingerprints used in the initial session setup use SHA-2.
- Signaling tokens used to authentication gateway requests use HMAC-SHA-2.
- Message integrity for STUN payloads used in NAT traversal use HMAC-SHA-1 as mandated by https://tools.ietf.org/html/rfc5389#section-15.4.
- Message integrity for SRTP payloads used in media flow use HMAC-SHA-1 as mandated by https://tools.ietf.org/html/rfc3711#section-4.2.1.
- LiveSwitch uses OpenSSL 1.1.1 TLS on the server for cryptographic key exchange which negotiates Encrypt-then-MAC by default.
Cipher Suites Used for DTLS
LiveSwitch connections are extremely secure once established, provided the signaling layer is also secure. Since the certificate fingerprints must be signaled in the SDP offer/answer blobs, a weakness in the signaling layer allows the possibility of a man-in-the-middle attack. For LiveSwitch, it is the Gateway that provides the signaling layer, and when installed on a server with a trusted SSL certificate, LiveSwitch's Gateway uses TLS encryption (HTTPS/WSS). The LiveSwitch Gateway also allows you to provide rate limiting, blacklisting, and whitelisting of client connections through a token-based registration model. Managing these registration tokens is an application-level security concern. We recommend an authenticated API endpoint on your own authentication server to generate and deliver registration tokens to the client securely at runtime as requested. For DDoS protection, it's recommended to use a third-party service like CloudFlare.
Again, all signaling connections must be secured via TLS to make security guarantees, so your LiveSwitch Gateway must be running on a server with a trusted SSL certificate, and all traffic to the Gateway must be configured to use secure connections.
See below for the client signaling flow diagram:
TURN Traffic Concerns and Secure TURNS
The percentage of time that WebRTC traffic is established over relay (TURN) varies greatly depending on the network environment. For example, TURN may not be required in many home networks, but in more restrictive corporate networks, where symmetric NAT is normal, requiring TURN is far more common. In general, we estimate 20%-30% of connections use TURN.
When connecting to a TURN server, clients are authenticated by username and password. Managing these credentials is an application-level security concern. We recommend an authenticated API endpoint on your own authentication server to deliver these credentials to the client securely at runtime as requested.
For added security, you can force all traffic through TURN, which guarantees that clients cannot learn information about each others' private networks (optionally including their WAN IP).
When TURN is in use, all data flows through the TURN server. Before sending data to the TURN server, clients first encrypt it using the keys exchanged via DTLS and then prepend a TURN header with destination address information. The TURN server can only read the header, as it does not have access to the keys necessary to decrypt the payload. TURNS provides an additional level of layer of security on top of this (for TCP only) by securing the TCP stream with TLS. By doing this, the entire stream is encrypted, which includes the TURN headers (and re-encrypts the payload). The TURN server is still not able to decrypt the payload, but by encrypting the entire stream, the headers are now safe from packet sniffers. This allows the traffic to pass through stateful packet inspection in routers that would otherwise block non-HTTPS traffic.