Security

WebRTC in general is very secure and IceLink follows the WebRTC spec. Here we discuss implementation specifics of IceLink's 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 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.

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.

Encryption

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

  • 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

Signalling

P2P 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. It is strongly recommended to use a signalling technology, like WebSync, that allows TLS encryption (HTTPS/WSS) to a server with a trusted SSL certificate. WebSync also allows you to customize who can access the server through the use of a BeforeConnect event that validates client metadata (like a token or cookie). In this way application developers can provide rate limiting, black listing, and white listing of client connections. For DDoS protection, we recommend using a third-party service like CloudFlare.

Again, all signalling connections must be secured via TLS to make security guarantees.

TURN Traffic Concerns and Secure TURN (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.

DNS

Because TURNS bindings require a certificate, a TURNS server must be pointed to via domain (DNS). You cannot simply point to your TURNS server using an IP address in the same way that you can with a regular TURN server.