As we’ve explained in previous posts, WebRTC is starting to make inroads, with use cases cropping up that make good sense for enterprise and SMB customers. But before we find ourselves surrounded by new applications chatting away from our Web browsers, it’s a good idea to examine the security implications of WebRTC.
WebRTC, for Real-time Communications, promises to enable audio, video and data communications in a peer-to-peer fashion from directly within a web browser, without the need for a phone, IP-based PBX, UC server or any other infrastructure. Given that, it seems a natural to enable all kinds of unified communications capabilities for just about any company.
On the other hand, WebRTC is an open protocol, currently available on nearly two-thirds of all Web browsers in use (pretty much all but Safari and Internet Explorer). That, I would think, makes it a tremendously attractive target for nefarious types looking for yet another way to break into your network.
To learn how to keep the bad guys at bay, I talked to Cary Hayward, Sr. Director of Product Management at Sonus Networks. Sonus makes session border controllers (SBCs) and software defined networking (SDN) network control platforms, which are crucial lynchpins in providing security (and many other functions) for real-time communications sessions.
As it turns out, Hayward, too, thinks WebRTC is a pretty attractive target. “The exposure is much greater because WebRTC is everywhere,” he says. “Just under 2 billion people now have a WebRTC-enabled browser.”
Hayward sees three keys to securing WebRTC sessions:
1. Encrypt signaling and real-time media
2. Police for denial of service (DOS) and bandwidth theft
3. Use a highly reliable, resilient platform to provide security
Encrypting WebRTC Signaling and Payload Data
With respect to encryption, it’s not just the payload of a WebRTC session that needs to be secured but the signaling data that tells where packets should go, Hayward says. If a hacker can intercept signaling data, he may be able to reroute sessions for malicious reasons, or scramble them just to wreak havoc.
Of course the payload – meaning the conversation taking place between two end points, be it audio, video, instant messaging or the like – also has to be protected. That’s especially true for a business UC environment, where such conversations may be sensitive in nature.
In both cases the remedy is encryption, typically using two forms of the Datagram Transport Layer Security (DTLS) standard: DTLS Secure Real-time Transport Protocol (SRTP) for audio and video, and DTLS Stream Control Transmission Protocol (SCTP) for data. Various sorts of devices can perform the encryption, including switches, routers and gateways. But Hayward says the function is a natural for SBCs.
Customers typically need the SBC anyway to provide signaling, security, interworking and transcoding for other SIP-based real-time communications sessions. Having the SBC perform encryption as well typically just means adding a software module to it, Hayward says.
Protecting WebRTC Against DOS, Bandwidth Theft and More
WebRTC is also subject to DOS and distributed DOS (DDOS) attacks, just as any server is. And it’s another way for intruders to potentially compromise network and IT resources. If an intruder succeeds in getting credentials from an authorized user, a WebRTC session could provide an avenue into the IT infrastructure, enabling the intruder to potentially “steal” bandwidth between servers. An intruder could also steal CPU cycles, using the servers to do his own bidding.
Protecting against such activity means being able to identify such attacks when they’re happening. That requires software that can recognize malformed packets, for example, that are typically used in a DOS or DDOS attack as well as attempted break-ins.
While a traditional firewall could detect such attacks for data sessions targeting IT servers, protecting real-time communications sessions requires a device that can understand SIP – which brings us back to the SBC. As we’ve discussed previously, an SBC is far better suited for real-time communications than a firewall.
WebRTC Security Requires a Hardened Platform
Whatever security option you choose to protect your WebRTC sessions, make sure it’s running on a hardened platform, Hayward says. “By that I mean a battle-tested platform, of the sort used in air traffic control towers and other mission critical applications,” he says.
Such platforms have fault-tolerant, self-healing capabilities such that if one component goes down – say, the SBC – another is in active stand-by mode and can immediately take its place. That’s important because anytime your security solution is unavailable, you are at risk of a breach.
The solution also has to be scalable, given that multiple WebRTC sessions could be running on each browser.
“The notion of a hardened, network resilient, scalable security offering for WebRTC is rare,” Hayward says. Sonus SBCs fit the bill on all of those fronts, he notes – and in that the company may be unique.