Security

Web Real-Time Communication (WebRTC) in general is secure and LiveSwitch follows the WebRTC specification. This topic explains implementation specifics of LiveSwitch's security measures, as well as covers 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 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 firewall rules 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's 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, then the next port will be tried incrementally until one is available; that's, 8446, 8447, 8448, 8449, and so on.
  • Media Server client connections require inbound UDP traffic on ports 49152-65535 on public interfaces.
  • 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, LiveSwitch recommends running a TURN server that listens on port 443 for TURNS.

Encryption

All connections are secured using DTLS. Secure X.509 certificates are automatically generated for each connection using Elliptic Curve Digital Signature Algorithm (ECDSA) (default, P-256 curve) or RSA (2048-bit) signing. Certificate fingerprints, used to verify the peer during key exchange, are exchanged through signaling in the SDP blobs, so it's imperative to ensure security at the signaling layer.

Connection Security

  • DTLS 1.2 with support for cipher suites that support Perfect Forward Secrecy (PFS). For the specific cipher suites allowed by the key exchange, refer to the Cipher Suites Used for DTLS section.
  • 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 Secure Real-time Transport Protocol (SRTP) standards.
  • Certificate fingerprints used in the initial session setup use SHA-2.
  • Signaling tokens used to authenticate gateway requests use HMAC-SHA-2.
  • Message integrity for STUN payloads used in NAT traversal use HMAC-SHA-1 as mandated by RFC 5389 Section 15.4.
  • Message integrity for SRTP payloads used in media flow use HMAC-SHA-1 as mandated by RFC 3711 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

  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256

Signaling

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, the Gateway provides the signaling layer; and when installed on a server with a trusted SSL certificate, LiveSwitch's Gateway uses TLS encryption (HTTPS/WSS). LiveSwitch Gateway also allows you to provide rate limiting, block listing, and allow listing of client connections through a token-based registration model. Managing these registration tokens is an application-level security concern. LiveSwitch recommends 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 such as CloudFlare.

Again, all signaling connections must be secured through 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.

Below is 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, LiveSwitch estimates 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. LiveSwitch recommends 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. This guarantees that clients can't 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 through DTLS and then prepend a TURN header with destination address information. The TURN server can only read the header, as it doesn't have access to the keys necessary to decrypt the payload. For TCP, TURNS provides an additional level of layer of security on top of this 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.