Security and identity management on WebRTC
2 likes1,962 views
The document discusses security and identity management challenges in WebRTC, including vulnerabilities to VoIP attacks, access issues with devices, and the necessity for secure signaling and media encryption. It emphasizes the importance of employing authentication methods and identity providers to ensure secure communication. Additionally, the document highlights protective measures and compliance with standards, underscoring that while WebRTC offers security features by default, careful consideration is needed for identity management.
Security and identity management on WebRTC
- 1. SECURITY AND IDENTITY MANAGEMENT ON WEBRTC
- 2. Agenda 1. Introduction into WebRTC security - VoIP attacks - WebRTC vulnerabilities - Protection - Identity Management 2.WebRTC, IMS, Security and Identities Víctor Pascual @victorpascual Antón Román @antonroman
- 4. WebRTC. Features Open system, no proprietary implementations ¡No plugins! Multi-platform...
- 5. WebRTC. Features. Multidevice: ○ Desktop and laptops ○ Tablets and notebooks ○ Smartphones ○ Set-Top-Boxes and WebTVs
- 6. WebRTC. Use cases. More information about use cases available here: Corporate: ○ Audio webclients for IMS, NGN, MS Lync, Cisco, etc. ○ Video webclients for conference bridges ○ Click to call (click to video/chat) solutions ○ Contact center solutions Residential: ○ OTT services ○ Audio webclients for residential users ○ Webchats ○ Vertical applications (e-health,...) ○ Extended RCS/Joyn services ○ Online videogames
- 7. WebRTC. Architecture. New elements introduced in the UC networks requires new considerations in terms of security: ○ Web Server ○ WebRTC gateway ○ Laptop/desktop used as endpoint
- 8. Efforts in WebRTC security. RFC Draft: Security considerations for RTC-Web WebRTC inherits part of the potential VoIP attacks and adds new threads: ○ New network elements to be hijacked, etc. ○ Open communications (new open ports, etc.) ○ Privacy issues through access to microphones and cams.
- 9. VoIP attacks
- 10. VoIP attacks. Introduction. Types of VoIP attacks: 1. Denial of service 2. Fraud 3. Illegal interception 4. Illegal control A VoIP attack causes an immediate economic damage for the attacked entity and a direct economic profit to the attacker. This does not occur with other type of attacks. VoIP security
- 11. VoIP attacks. Denial of service. The aim of an attack of DoS is to degrade the quality of the service that perceives the user by means of the massive delivery of messages that require of the use of resources (CPU, BW or memory) in the attacked system. Examples: flood of register requests or calls in a softswitch that can pretend: ■ A simple failure of the service. ■ Attack for telephone fraud. Also other "non intentional" attacks should be taking into account: ■ flood after a power blackout. ■ Bugs in terminals. ■ Viruses.
- 12. VoIP attacks. Fraud. An attacker registers in the system with a valid user (discovers the password, alters an IP, etc.) with the aim to do calls to international numbers. CFCA estimates 40 Billions USD annually. They are not only calls through the network. Sometimes the attacker obtains remote access to a SIP proxy or softswitch that can use to originate illegal calls by console. ● These attacks cause not only economic losses. Sometimes the legitimate user has to pay the bill!! ● In most cases, it's difficult to determine the responsibility (customer or operator) of the attacks.
- 13. VoIP attacks. Illegal interception. Because of the IP nature is simpler to capture signalling and media traffic by potential attackers to obtain information (audio of the call, other information of the call exchanged, etc.) As traditional VoIP SIP traffic is opened, this is more dangerous in Wi-Fi networks where traffic is not ciphered. WebRTC uses ciphered traffic for signalling and media, so interception could only be done in the endpoints or media gateway.
- 14. VoIP attacks. Illegal control. If an attacker achieves the credenciales of an user or an administrator, he has absolute control: ● Can be used to do calls with high costs: causing losses to the service provider and/or end customer. ● Hijacked lines can be used to finish calls of other customers to which the attacker sells services ● For illegal activities, makes more difficult the judicial follow-up of the calls.
- 16. Access to devices. Threats HTML and JS script are executed by the browser as a "sandbox" designed to be isolated from the rest of the computer. However bugs may exist. WebRTC API needs to access physical devices which will provide real-time media information (and files): THREAT: Web pages access to user's camera and microphone without permissions.
- 17. Access to devices. Threats Malicious WebSever Users can potentially being recorded with Javascript code downloaded from a malicious Web Server. Malicious Script SRTP
- 18. Access to screen capture. Threats Malicious WebSever SRTP Malicious Script Security in screen sharing is specially critical as very sensitive information can be stolen.
- 19. Websocket. Websocket (RFC6445): provides a full-duplex socket between a browser and a server. It is just a TCP socket upgraded from an HTTP handshake. Standardized way for the server to send content to the browser without being solicited by the client. Image from http://blog.kaazing.com Image from: http://stackoverflow.com
- 20. Websocket DoS. Threats Browser N Attacked Server websocket Malicious WebSever Websocket allows cross-origin connection. DDoS attacks can be implemented in a Web-oriented way. Browser 1 websocket httphttp Malicious Script Malicious Script
- 21. Websocket cross-protocol attack. Threats ebsocket A malicious script could potentially inject code which is valid in HTTP poisoning HTTP intermediaries (i.e. HTTP proxy). This is avoided natively by WS RFC. http://tools.ietf.org/agenda/80/slides/hybi-2.pdf
- 22. Signaling sent over not TLS connection. By default it implements digest authentication, however it has a number of disadvantages: ● Several security options (like 'qop' for integrity) are optional. ● Vulnerable to man-in-the-middle attacks. Sending the messages in plain-text is not a good idea, it can be authenticated but not privacy and integrity. Signaling traffic can be sent over Websocket: data is sent over a TCP socket without any encryption. Equivalent to SIP over UDP/TCP. Sending all the signaling over TLS is a must!
- 23. Security of TURN server. TURN is necessary in many WebRTC scenarios to establish bi-directional flows. Media relaying is an expensive resource so it is protected with credentials. Those credentials can be long-term, if these credentials are stolen the TURN server can be abused.
- 24. Security in Click-to-call solutions ● Click to call solutions are potentially easy to be attacked. ● The WebRTC Click2Call solution server must implement mechanism to make sure the user is calling from a trusted site and limit the amount of calls from one location. ● Controlling the total amount of calls also will help to minimize DDoS. Web Visitor Contact Center
- 25. Protection
- 26. Signaling over TLS. SIP traffic can be sent over Secure Websocket: data is sent over a TLS socket. Equivalent to SIP over TLS. TLS provides privacy, integrity and authentication. It also provides server authentication, and client authentication if a client certificate is provided. If the client certificate is signed by a Trusted Certification Authority (CA) the real-time communication can have legal value. Using, HTTPS and WSS is necessary when working with WebRTC. For example: Screen sharing only works from HTTPS sites!
- 27. Access to devices. WebRTC standard requires that access to device to be notified to the user. Browser notifies the user that a tab is currently accessing media devices. With a blinking red spot In Chrome.
- 28. Access to devices. Showing own video to the user helps to be aware that the browser is accessing cam and micro. The browser stores the permissions settings for HTTPS sites which valid certificates.
- 29. Access to devices. Screen capture requires to type of permissions: 2. Always active user content 1. Elevated permissions (in practice means installing a plugin once)
- 30. Websocket poisoning. websocket http://tools.ietf.org/agenda/80/slides/hybi-2.pdf Browser Server<Websocket opening handshake string> *u0!GDDD&GIO[[[ONx< [&BM#>;:$MMGGDDDF4xOFDA@E6XU7$&UU<'U<! 4U6UY&0OY X$%CIOCBM#HNXDWBK69E SIP/2.0 200 OK Via: SIP/2.0/WS NO72tU858jVE.invalid; branch=z9hG4bKFhlN824OuTkQrgQl7FD8t1ejvP08 0E;rport=48095;received=46.25.57.69 Browser-To-Server Server-To-Browser
- 31. DDoS. DoS and DDoS protections are pretty similar to the implemented in Web Servers. Attacks can be potentially be launched from thousands of browsers. Signaling is going to be received via TCP/TLS: WS, WSS, REST APIs, etc Typical attack vectors (SYN flood, RESET attack etc) must be stopped as soon as possible to limit resources exhaustion which causes a denial of service. WebRTC Gateways/servers normally will be exposed in Internet listening on well-known ports (443 and 80).
- 32. DTLS-SRTP for media encryption DTLS-SRTP manage the SRTP key exchange within the RTP flow before starting media. This is done using DTLS, a version of TLS based on datagrams. Keys are not exchanged in the SDP protocol. It protects the RTP flow even if signaling is not encrypted. It is mandatory for A fingerprint is included in the SDP to create a security relationship between the SDP and the DTLS-SRTP flows.
- 33. ICE. ICE(RFC5245) allows RTP flows to traverse NAT routers. It finds the best path for RTP/RTCP traffic. STUN is used to find out the paths to send the RTP flow. ICE, includes a handshake designed to verify that the receiving element wishes to receive traffic from the sender. This identifier/password are created by the browser and used during the ICE negotiation.
- 34. Monitoring. It is important monitor all the traffic the same way it is done with SIP traffic. It is possible to gather even more information for WebRTC sessions: ● IP geolocation. ● Host URL. ● Browser info. ● Contextual info.
- 35. ID management
- 36. Identity management. WebRTC does not force any authentication method. WebRTC API exposes an authentication API based on Identity Providers which can be: ● Ad-hoc solutions ● Social networks ● Certification Authorities (private or public) ● Telco authentication IdP protocols: OpenID or BrowserID, Federated Google Login, Facebook Connect, OAuth, WebFinger
- 37. Identity management. OpenID Makes possible to be sure of the identity using a third party New opportunity for operators as Identity Providers: Mobile number as Trusted Identity
- 38. Identity management. +----------------+ | | | Signaling | | Server | | | +----------------+ ^ ^ / HTTPS / HTTPS / / v v JS API JS API +-----------+ +-----------+ | | Media | | Alice | Browser |<---------->| Browser | Bob | | (DTLS+SRTP)| | +-----------+ +-----------+ ^ ^--+ +--^ ^ | | | | v | | v +-----------+ | | +-----------+ | |<--------+ | | | IdP1 | | | IdP2 | | | +------->| | +-----------+ +-----------+ WebRTC API defined by W3C Alice and Bob have relationships with some Identity Provider (IdP) that supports a protocol such as OpenID or BrowserID, Federated Google Login, Facebook Connect, OAuth, WebFinger) that can be used to demonstrate their identity to other parties.
- 39. Identity management. +--------------------------------------+ | Browser | | | | +----------------------------------+ | | | https://calling-site.example.com | | | | | | | | Calling JS Code | | | | ^ | | | +---------------|------------------+ | | | API Calls | | v | | PeerConnection | | ^ | | | MessageChannel | | +-----------|-------------+ | +---------------+ | | v | | | | | | IdP Proxy |<-------->| Identity | | | | | | Provider | | | https://idp.example.org | | | | | +-------------------------+ | +---------------+ | | +--------------------------------------+ v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com a=setup:actpass a=fingerprint: SHA-1 4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB a=identity: ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg== t=0 0 m=audio 6056 RTP/SAVP 0 a=sendrecv WebRTC API defined by W3C
- 40. Identity management. Adds a second factor of authentications because we validate the device (smartphone or PC) and the credentials are introduced ciphered in a SIP signalling packet. Certification Authority Certificate verification Example of Identity Management
- 42. WebRTC access to IMS
- 43. WebRTC access to IMS
- 45. Reference Model WebRTC IMS Client (WIC) P-CSCF enhanced for WebRTC (eP-CSCF) IMS-AGW enhanced for WebRTC (eIMS-AGW) WebRTC Web Server Function (WWSF) WebRTC Authorization Function (WAF)
- 46. Registration and authentication SIP/IMS vs Web Authentication
- 47. WebRTC is signaling agnostic, SIPoWS is just one option
- 48. SIP can be used with Web Authentication
- 49. IMS can be used with Web Authentication
- 50. Authentication of WebRTC IMS Client with IMS subscription using web credentials
- 53. Media security for RTP
- 54. Media Security for WebRTC DataChannels
- 55. NAT traversal In order to traverse restrictive-firewalls one could also use TCP/TLS transport. Some, are even multiplexing that over HTTP-based connections
- 56. Firewall and HTTP proxy traversal
- 59. How is it really deployed in the real world? other existing systems Experience from 100+ field trials/POCs
- 60. Customer Use Case: Service Provider in CALA
- 61. Customer Use Case: Service Provider in EMEA
- 62. Customer Use Case: Service Provider in APAC
- 63. Summary
- 64. What we have learned today ● Legacy VoIP attacks could also be important in WebRTC. ● WebRTC provides security by default (mandatory encryption, access permissions, etc). ● Care should be paid to Authentication and Identity Management
- 65. Planning to be in Barcelona during MWC15? Quobis' booth (#CS60, Spanish Pavilion) will showcase "Sippo WebRTC Application Controller" to service providers and network equipment vendors, showing them how to introduce new value- added WebRTC services to their residential and corporate customers, hiding the complexity behind the different implementation of the standards by web browsers and gateway vendors and providing a complete set of APIs to manage AAA, user provisioning, contact management, policy control and other features. mwc@quobis.com
- 66. Planning to be in Barcelona during MWC15? Register today for this free event at http: //www.meetup.com/WebRTC-Barcelona