WEBRTC: APIS, PROTOCOLS AND SECURITY CONSIDERATIONS – PART II

In part 1 of this post I described how the proposed WebRTC specification enables the development of real-time communication over browser-based peer-to-peer (P2P) connections that can support useful things like live video communication, Content Delivery Networks, screen casting and others without the need for third-party plugins. However, it’s not necessarily all smooth sailing with WebRTC and in this follow-up, I look at threats to some of the WebRTC components and what you can do to protect your software development against them.

First let’s turn a critical eye on WebRTC-enabled End-points. Threats include:

 

- Unauthorized access to local devices: Unrestricted access to local devices from arbitrary website is a big concern for WebRTC-enabled end-points.Furthermore, unwanted calls initiated by malicious peers using websites authorized by the target end-point could pose privacy concerns and negatively impact the user experience.
- Unauthorized access to private networks: NAT traversal capabilities are essential for establishing a WebRTC peer connection. Malicious calling services or peers could exploit misplaced trust relationships and use the NAT traversal capabilities to gain unauthorized access to restricted nodes inside a private network.

 

 

The spec addresses this by proposing the use of device access permissions.To prevent unauthorized access to devices, the WebRTC specification implements an Origin-based permissions model that requires explicit device access consent from the user and mandates UI notifications to signal that the device is being accessed.

What secure development best practices can you apply to manage this possible threat? Use peer identity management and ensure strong trust relationships between peers by allowing identity verification based on either third-party identity assertion providers or using X.509 certificates.

Next, let’s look at the calling service. A calling service hosted on a web server deploys JavaScript to the end-point to enable WebRTC-based communication and provisions the signaling channel. Threats include:

 

- Denial-of-Service attacks: If a calling service uses insecure cross-domain policies it could be exposed to distributed DoS attacks by other malicious calling services (using an army of peer nodes).
- Call forging: Loading content from the calling service over a non-secure channel could allow attackers to forge a call on behalf of the target user using iframe injection attacks.

 

As a developer, you can address these issues by carefully reviewing the cross-domain policies employed by the calling service (for example, via HTML5 CORS or WebSockets) and deny requests from an unknown origin. You should also always use a secure channel to deploy client-side code used for establishing WebRTC connections and avoid serving mixed content in HTTPS pages.

Next up, it’s threats to signaling and connectivity establishment. Attackers often target the signaling channel as a stepping stone for compromising the confidentiality and integrity of the media plane. I’ve listed some of the attack techniques used to accomplish this below:

 

- ICE candidates poisoning: Attackers can use a number of attack techniques to manipulate the results of STUN connectivity checks and trick a victim peer into connecting with malicious nodes.
- Location privacy: An attacker can initiate calls with a target end-point to trigger ICE negotiation and obtain the victim’s IP address which in turn can offer the attacker clues about the victim’s location.
- Signaling interception: An attacker can obtain valuable information such as ICE username fragments and passwords used to ensure the integrity of STUN connectivity checks.
- Known protocol vulnerabilities: Choosing signaling mechanisms with known vulnerabilities could expose a WebRTC-based application to various attacks. For instance, various forms of Denial-of-Service attacks have been demonstrated against two popular signaling protocol choices – SIP and WebSockets.

 

Of course, there are some built-in security provisions designed to address these threats. The ICE protocol enables message integrity for STUN connectivity checks using the short-term credential mechanism. Also, the WebRTC specification suggests holding off the ICE negotiation until the user accepts the call to prevent the IP address from being revealed to untrusted peers.

If you’re developing, it is imperative that you ensure that a secure channel is used for signaling (for example SIPS or WSS).

Finally, we come to threats against the media plane. The end-to-end encryption offered by the Secure RTP profile (mandated by RTCWEB) guarantees confidentiality and integrity of the media exchange. One threat, however, includes:

 

- Insecure key exchange: The RTCWEB standard mandates the implementation of a DTLS key exchange mechanism. However, it also allows support for other key management protocols including SDES. Key exchange using SDES is done in clear text via SDP messages. If an attacker intercepts this exchange and obtains the key used for encrypting the SRTP traffic, the encryption is rendered completely useless.

 

My secure development best practice recommendation in this case is to choose a secure key exchange mechanism. Developers must use the DTLS-SRTP key exchange mechanism whenever possible. If you can’t avoid using SDES, then the signaling must be conducted over a secure channel.

The RTCWEB Working Group has done a commendable job of incorporating the security by default principle while drafting the specification. It is also, however, flexible enough in letting developers make key deployment choices to allow them to leverage any existing communication infrastructure (for example, the signaling mechanism and key exchange). If the developers fail to carefully consider the security implications of these choices, the safeguards mandated by the specification will not be enough to guarantee the security of their WebRTC-based applications and the users.

Comments
pjagdale | ‎09-19-2013 02:18 PM

Encouraging news from the Google Chrome team regarding the default use of DTLS-SRTP keying mechanism and the deprecation of the less secure SDES in future versions - Migration to DTLS-SRTP: https://groups.google.com/forum/#!topic/discuss-webrtc/67W4zrTmoNs

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Featured


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.