How can I make my WebRTC solution secure?
In one of my previous posts I have mentioned about Security threats to WebRTC Solution . It includes mainly 4 ways in which WebRTC Solution Providers and Users are vulnerable . It includes Identity Management , Browser Security , Authentication and Media encryption. Since I have already covered these topics here( https://altanaitelecom.wordpress.com/2014/10/03/security-for-webrtc-applications/ ) I will not repeat the same here. This post is about making WebRTC secure so that they can be used inn area which require sensitive data to be communicated and need to be secure enough to withstand and hacks and attacks.
In the recent months everyone has been trying to get into the WebRTC ” kool space ” but at the same time fearing that hackers might be able to listen in on conferences, access user data, or even private networks. Although development and usage around WebRTC is so simple , the security and encryption aspecets of it are in the dim light.
So does existing WebRTC model offer security ?
We know that the forces behind WebRTC standardization are WHATWG, W3C, IETF and strong internet working groups . WebRTC security was already taken into consideration when standards were being build for it . The encryption methods and technologies like DTLS and SRTP were included to safeguard users from intrusions so that the information stays protected.
WebRTC media stack has native built-in features that address security concerns. The peer-to-peer media is already encrypted for privacy . Figure below:
For WebRTC to transfer real time data, the data is first encrypted using the DTLS (Datagram Transport Layer Security) method. This is a protocol built into all the WebRTC supported browsers from the start (Chrome, Firefox and Opera). On a DTLS encrypted connection, eavesdropping and information tampering cannot take place.
Other than DTLS, WebRTC also encrypts video and audio data via the SRTP (Secure Real-Time Protocol) method ensuring that IP communications – your voice and video traffic – can not be heard or seen by unauthorized parties.
What is SRTP ?
The Secure Real-time Transport Protocol (or SRTP) defines a profile of RTP (Real-time Transport Protocol), intended to provide encryption, message authentication and integrity, and replay protection to the RTP data in both unicast and multicast applications.
Earlier models of VOIP communication such as SIP based calls had an option to use only RTP for communication thereby subjecting the endpoint users to lot of problem like compromising media Confidentiality . However the WebRTC model mandates the use of SRTP hence ruling out insecurities of RTP completely. For encryption and decryption of the data flow SRTP utilizes the Advanced Encryption Standard (AES) as the default cipher.
What is DTLS ?
DTLS allows datagram-based applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the stream-oriented Transport Layer Security (TLS) protocol .
Together DTLS and SRTP enables the exchange of the cryptographic parameters so that the key exchange takes place in the media plane and are multiplexed on the same ports as the media itself without the need to reveal crypto keys in the SDP.
Today the browser acts as a TRUSTED COMPUTING BASE (TCB) where the HTML and JS act inside of a sandbox that isolates them both from the user’s computer.
A script cannot access user’s webcam , microphone , location , file , desktop capture without user’s explicit consent. When the user allows access, a red dot will appear on that tab, providing a clear indication to the user, that the tab has media access.
Figure depicting browser asking for user’s consent to access Media devices for WebRTC .
Figure depicting Media Capture active on browser with red dot .
we know that XMLHttpRequest() API can be used to secretly send data from one origin to other and this can be used to secretly send information without user’s knowledge . However now , SAME ORIGIN POLICY (SOP) in browser’s prevents server A from mounting attacks on server B via the user’s browser, which protects both the user (e.g., from misuse of his credentials) and the server B (e.g., from DoS attack).
What is SOP ?
SOP enables webpages and scripts from the same origin server to interact with each other’s JS variables, but prevents pages from the different origins or even iframes on the same page to not exchange information.
WebSockets use masking technique to randomize the bits that are being transmitted , thus making it more difficult to generate traffic which resembles a given protocol , thus making it difficult for inspection from flowing traffic .
In-spite of all this the security challenges with Web Server based WebRTC service are many for example :
1. If the both the peers have WebRTC browser then one can place a WebRTCcall to callee anytime this might result in denial of service .
2. Since the media is p2p and also can override firewalls settings through TURN server , it can result in unwanted data being send to peer .
3. One may secretly make calls to users through website and extract information .
4. Threat from screen sharing, for example user might mistakenly share his internet banking screen or some confidential information.
5. Giving long-term access to the camera and microphone for certain sites is also a concern . for example : since next time you visit a site that has access to your microphone and camera , they can secretly be viewing youe webcam and microphone inputs .
6. Clever use of User Interface to mask a ongoing call can mislead the user into believing that call has been cut while it is secretly still ongoing.
7. Network attackers can modify an HTTP connection through my Wifi router or hotspot to inject an IFRAME (or a redirect) and then forge the response to initiate a call to himself.
8. As WebRTC doesn’t yet have an congestion control mechanism , it can eat up a large chunk of user’s bandwidth.
9. By visiting chrome://webrtc-internals/ in chrome browser alone , one can view the full traces of all webRTC communication happening through his browser . The traces contain all kinds of details like signalling server used , relay servers , TURN servers , peer IP , frame rates etc .
Ofcourse other challenges that arrive with any other webservice based architecture are also applicable here such as :
1. Malicious Websites which automatically execute the attacker’s scripts.
2. User can be induced to download harmful executable files and run them.
3. Improper use of W3C Cross-Origin Resource Sharing (CORS) to bypass SAME ORIGIN POLICY (SOP) .
Best practices to make your VOIP Solution more secure
A simple WebRTC architecture is shown in the figure below :
By following the simple steps described below one can ensure a more secure WebRTC implementation . The same applies to healthcare and banking firms looking forth to use WebRTC as a communication solution for their portals .
1. Ensure that the signalling platform is over a secure protocol such as SIP / HTTPS / WSS .
2. User’s that can participate in a call , should be pre registered / Authenticated with a registrar service. Unauthenticated entities should be kept away from session’s reach .
2. Make sure that ICE values are masked thereby not rendering the caller/ callee’s IP and location to each other through tracing in chrome://webrtc-internals/ or packet detection in Wirehsark on user’s end.
3. Also since media is p2p , the media contents like audio video channel are between peers directly in full duplex. Thus
4. As the signalling server maintains the number of peers , it should be consistently monitored for addition of suspicious peers in a call session. If the number of peers actually present on signalling server is more that the number of peers interacting on WebRTC page then it means that someone is eavesdropping secretly and should be terminated from session access by force.
5. It is observed these days that users simply agree to all permissions request from browser without actually consciously giving consent . Therefore user’s should be made aware of API in websites which ask for undue permissions . For example permission to :
6. To protect against Man-In-The-Middle (MITM) attack the media path should be monitored regularly for no suspicious relay.
7. Third party API should be thoroughly verified before sending their data on WebRTC DataChannel.
8. Before Desktop Sharing user’s should be properly notified and advised to close any screen containing sensitive information .
What happens if your VOIP solution is on the verge of being compromised ?
As the media connections are p2p , even if we restart the signalling server , it will not affect the ongoing media sessions . Only the time duration ( probably 3 – 4 minutes ) it takes to restart the server , is when the users will not be able to connect to signalling server for creating new sessions .
Most browsers today like Google Chrome and Mozilla Firefox have a goof record of auto-updating themselves withing 24 hours of a vulnerability of threat occurring .
If a call is confirmed to be compromised , it should be within the power of Web Application server rendering the WebRTC capable page to cut off the call .