17. Security Considerations
This section considers attacks that might be mounted against TURN deployments and discusses how to mitigate these attacks through mechanisms in the protocol or recommended practices in the implementation.
Most attacks against TURN are mitigated by the server requiring requests to be authenticated. For this reason, this specification mandates the use of authentication. The mandatory-to-implement mechanism is the long-term credential mechanism of STUN. Other authentication mechanisms with the same or stronger security properties MAY be used. However, it is important to ensure that they can be invoked in an interoperable manner.
17.1. Outsider Attacks
Outsider attacks are those where the attacker has no credentials in the system and is trying to disrupt the service as seen either by the client or the server.
17.1.1. Obtaining Unauthorized Allocations
An attacker might wish to obtain an allocation on a TURN server for any number of malicious purposes. A TURN server provides a mechanism for sending and receiving packets while hiding the actual IP address of the client. This makes the TURN server an attractive target for attackers who wish to use it to mask their true identity.
An attacker might also simply wish to utilize the services of a TURN server without paying for them. As TURN services require resources of the provider, it is expected that their usage will be accompanied by a cost.
These attacks are prevented through the use of the long-term credential mechanism, which allows the TURN server to determine the identity of the requester and whether the requester is authorized to obtain an allocation.
17.1.2. Offline Dictionary Attacks
The long-term credential mechanism used by TURN is susceptible to offline dictionary attacks. An attacker that is able to eavesdrop on a message exchange between a client and server can determine the password by trying a number of candidate passwords and seeing if one of them is correct. This attack works when passwords are low entropy (e.g., words from a dictionary). This attack can be mitigated by using strong passwords with large entropy. In cases where even stronger mitigation is needed, TLS transport can be used between the client and the server.
17.1.3. Faked Refreshes and Permissions
An attacker might wish to attack an active allocation by sending it a Refresh request with an immediate expiry in order to delete it and disrupt service to the client. This is prevented through authentication of refreshes. Similarly, an attacker wishing to send a CreatePermission request to create a permission to an unwanted destination is prevented from doing so through authentication. The motivations for such attacks are described in Section 17.2.
17.1.4. Fake Data
An attacker might wish to send data to a client or peer as if it came from the peer or client, respectively. To do this, the attacker could send a faked Data indication or ChannelData message to the client or a faked Send indication or ChannelData message to the TURN server.
Because indications and ChannelData messages are unauthenticated, this attack is not prevented by TURN. However, this attack is generally present with IP-based communications and is not significantly worsened by TURN. Consider a normal IP session between hosts A and B that does not use TURN. An attacker can send a packet to B appearing to be from A by sending the packet with A's spoofed IP address. This attack requires that the attacker know the IP addresses of both A and B. With TURN, an attacker wishing to send a packet to the client using a Data indication needs to know the IP address (and port) of the client, the IP address and port of the TURN server, and the IP address and port of the peer (to include in the XOR-PEER-ADDRESS attribute). To send a fake ChannelData message to the client, the attacker needs to know the IP address and port of the client, the IP address and port of the TURN server, and the channel number. This particular combination is slightly easier to guess than the non-TURN case.
These attacks are better mitigated through application-layer authentication techniques. In the case of real-time traffic, the use of SRTP [RFC3711] can prevent these attacks.
In some cases, the TURN server might be situated in the network such that it is able to send to hosts the client itself cannot reach directly. For example, if the server is located behind a firewall that allows packets from outside the firewall to pass to the server, but not to other hosts behind the firewall. In these cases, an attacker might be able to send a Send indication to the server with an XOR-PEER-ADDRESS attribute containing the transport address of one of the other hosts behind the firewall. If the server allows traffic to be relayed to any peer, this would provide the attacker with a way to attack an arbitrary host behind the firewall.
To mitigate this attack, TURN requires the client to establish a permission to a host before sending data to it. Thus, the attacker can only attack hosts that the client has already communicated with, unless the attacker is able to create authenticated requests. In addition, a server administrator can configure the server to restrict the range of IP addresses and ports to which it will relay data. To provide even greater security, a server administrator can require the client to use TLS for all communication between the client and the server.
17.1.5. Impersonating a Server
When a client learns the relayed address from a TURN server, it uses that relayed address in an application protocol to receive traffic. Thus, an attacker wishing to intercept or redirect that traffic might try to impersonate the TURN server and provide the client with a faked relayed address.
This attack is prevented through the long-term credential mechanism, which provides message integrity for responses and authenticates that they are from the server. In addition, an attacker cannot replay old server responses, because the transaction ID in the STUN header prevents this. Replay attacks are further discouraged by changing the nonce value frequently.
17.1.6. Eavesdropping Traffic
TURN is primarily concerned with authentication and message integrity. Confidentiality is only a secondary concern, since TURN control messages do not contain particularly sensitive information. The primary protocol content of the messages is the IP addresses of the peers. If it is important to prevent an eavesdropper on a TURN connection from learning this, TURN can be run over TLS.
The confidentiality of the application data relayed by TURN is best provided by the application protocol itself, since running TURN over TLS will not protect the application data between the server and the peer. If confidentiality of the application data is important, the application should encrypt or otherwise protect its data. For example, for real-time media, confidentiality can be provided by using SRTP.
17.1.7. TURN Loop Attack
An attacker might try to cause data packets to loop infinitely between two TURN servers. The attack proceeds as follows. First, the attacker sends an Allocate request to server A with a source address of server B. Server A sends its response to server B, and for the attack to succeed, the attacker must be able to see or guess the contents of this response so that the attacker can learn the allocated relayed transport address. The attacker then sends an Allocate request to server B with a source address of server A. Again, the attacker must be able to see or guess the contents of the response so the allocated relayed transport address can be learned. Using the same faked source address techniques, the attacker then binds a channel number on server A to the relayed transport address on server B and similarly binds the same channel number on server B to the relayed transport address on server A. Finally, the attacker sends a ChannelData message to server A.
The result is a data packet looping from the relayed transport address on server A to the relayed transport address on server B, then from the transport address on server B to the transport address on server A, then looping again.
The mitigation against this attack is as follows. By requiring requests to be authenticated and/or by randomizing the port number assigned for the relayed transport address, the server forces the attacker to intercept or see responses sent to third parties (in this case, the other server) in order for the attacker to authenticate the request and learn the relayed transport address. Without one of these two measures, the attacker can guess the contents of the response without needing to see it, which makes the attack easier to carry out. In addition, by requiring authenticated requests, the server forces the attacker to have credentials that the server will accept, which makes it an insider attack instead of an outsider attack and allows the attack to be traced back to the client who launched it.
Further mitigation can be achieved by imposing per-username limits on the bandwidth used by allocations belonging to that username for relaying data, to limit the impact of this attack on other allocations. Further mitigation can be achieved by decrementing the TTL when relaying data packets (if the underlying operating system allows this).
17.2. Firewall Considerations
A key security consideration for TURN is that TURN should not weaken the protections afforded by a firewall deployed between the client and the TURN server. It is anticipated that TURN servers will often be present on the public Internet, while clients could often be located within an enterprise network served by an enterprise firewall. If the TURN server provides a "back door" into the enterprise, TURN will be blocked by these firewalls.
Therefore, a TURN server emulates the behavior of a NAT device that implements address-dependent filtering [RFC4787], which is a common property in many firewalls. When a NAT or firewall implements this behavior, packets from an external IP address are allowed to be sent to an internal IP address and port only if the internal IP address and port recently sent a packet to that external IP address. A TURN server introduces the concept of permissions, which provides exactly the same behavior on the TURN server. An attacker cannot send a packet to a TURN server and expect it to be relayed to a client unless the client has first tried to contact the attacker.
It is important to note that the policies of some firewalls are even stricter than address-dependent filtering. Firewalls can also be configured to be address- and port-dependent filtering, or can be configured to disallow all inbound traffic. In these cases, communication with a client would be less restricted than the firewall normally allows, if the client is allowed to connect to a TURN server.
17.2.1. Faked Permissions
In firewalls and NAT devices, permissions are granted implicitly by packets traversing from the inside of the network to the outside peer. Thus, by definition, permissions cannot be created by any entity outside the firewall or NAT. With TURN, this restriction no longer holds. Since the TURN server sits outside the firewall, an attacker outside the firewall can now send messages to the TURN server and try to create permissions for themselves.
This attack is blocked because all messages that create permissions (namely, ChannelBind and CreatePermission) are authenticated.
17.2.2. Blacklisted IP Addresses
Many firewalls can be configured with blacklists to prevent clients behind the firewall from sending packets to or receiving packets from blacklisted IP address ranges. This is accomplished by examining the source and destination addresses of packets entering and leaving the firewall, respectively.
This capability is also present in TURN, as the TURN server is allowed to arbitrarily restrict the range of addresses of peers to which it will relay.
17.2.3. Running Servers on Well-Known Ports
A malicious client behind a firewall might try to connect to a TURN server and obtain an allocation, which it can then use to run a server. For example, the client might try to run a DNS server or an FTP server.
This is not possible with TURN. A TURN server will never accept traffic from a peer for which the client has not installed a permission. Thus, a peer cannot simply connect to the allocated port in order to obtain service.
17.3. Insider Attacks
In an insider attack, the client has legitimate credentials but violates the trust relationship that comes with those credentials. These attacks cannot be prevented through cryptographic means but need to be considered in the protocol design.
17.3.1. DoS against TURN Server
A client wishing to disrupt service to other clients might obtain an allocation and then flood it with traffic, in an attempt to swamp the server and prevent it from servicing other legitimate clients. This is mitigated by recommending that the server limit the amount of bandwidth it will relay for a given username. This does not prevent the client from sending a large amount of traffic, but it allows the server to drop the excess traffic immediately.
Since each allocation uses one port number on the IP address of the TURN server, the number of allocations on the server is finite. An attacker might try to consume all of the allocations by requesting a large number of allocations. This is prevented through the recommendation that the server impose a limit on the number of allocations active at one time for a given username.
17.3.2. Anonymous Relaying of Malicious Traffic
A TURN server provides a degree of anonymization. A client can send data to a peer without revealing its own IP address. Thus, a TURN server could become an attractive tool for attackers to launch attacks at a target without fear of detection. Indeed, a client could chain multiple TURN servers together, such that an arbitrary number of relays were used before the data packet arrives at the target.
An administrator concerned about this attack can maintain logs capturing the actual source IP and port of the client, and possibly even every permission that client installed. This would allow for forensic tracing to determine the original source, if an attack is discovered to be relayed through a TURN server.
17.3.3. Manipulating Other Allocations
An attacker might try to disrupt the service to other users of the TURN server by sending Refresh requests or CreatePermission requests that (through source-address spoofing) appear as if they came from another user of the TURN server. TURN prevents this by requiring that the credentials used in CreatePermission, Refresh, and ChannelBind messages match the credentials that were used to create the initial allocation. Thus, forged requests from an attacker will be rejected.
17.4. Other Considerations
Any relayed address learned via an Allocate request will not work properly with IPsec Authentication Header (AH) [RFC4302] in transport or tunnel mode. However, tunnel mode IPsec Encapsulating Security Payload (ESP) [RFC4303] should still work.