MIX Assistance - Security [EN]

Dokumentation auf Deutsch

WebRTC in general is very secure our WebRTC Server follows the WebRTC spec. Here we present implementation of our security measures, as well as covering basic network related configuration.

Network Configuration and Required Ports

  • 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 firewalls. 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 application 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 5379 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 (i.e. 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 run a TURN server that listens on port 80 for STUN/TURN and 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 signalling in the SDP blobs, so it is imperative to ensure security at the signalling layer.

Connection Security 

  • 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.

Cipher Suites Used for DTLS



The connections are extremely secure once established, provided the signalling layer is also secure. Since the certificate fingerprints must be signalled in the SDP offer/answer blobs, a weakness in the signalling layer allows the possibility of a man-in-the-middle attack. For our solution, it is the Gateway that provides the signalling layer, and when installed on a server with a trusted SSL certificate, the Gateway uses TLS encryption (HTTPS/WSS). The Gateway also allows you to provide rate limiting, black listing, and white listing of client connections through a token-based registration model. Managing these registration tokens is an application-level security concern. Therefore, we have a authenticated API endpoint on our own authentication server to generate and deliver registration tokens to the client securely at runtime as requested. For DDoS protection, we could integrate third-party services like CloudFare.

All signalling connections are secured via TLS to make security guarantees, so the Gateway is running on a server with a trusted SSL certificate, and all traffic to the Gateway is configured to use secure connections.