WebRTC Security

66
SECURITY AND IDENTITY MANAGEMENT ON WEBRTC

Transcript of WebRTC Security

Page 1: WebRTC Security

SECURITY AND IDENTITY MANAGEMENT ON WEBRTC

Page 2: WebRTC Security

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

Page 3: WebRTC Security

Introduction into WebRTC security

Page 4: WebRTC Security

WebRTC. Features

Open system, no proprietary implementations

¡No plugins!

Multi-platform...

Page 5: WebRTC Security

WebRTC. Features.

Multidevice:

○ Desktop and laptops○ Tablets and notebooks○ Smartphones○ Set-Top-Boxes and WebTVs

Page 6: WebRTC Security

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

Page 7: WebRTC Security

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

Page 8: WebRTC Security

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.

Page 9: WebRTC Security

VoIP attacks

Page 10: WebRTC Security

VoIP attacks. Introduction.

Types of VoIP attacks:

1. Denial of service2. Fraud3. Illegal interception4. 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

Page 11: WebRTC Security

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.

Page 12: WebRTC Security

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.

Page 13: WebRTC Security

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.

Page 14: WebRTC Security

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.

Page 15: WebRTC Security

WebRTC vulnerabilities

Page 16: WebRTC Security

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.

Page 17: WebRTC Security

Access to devices. Threats

MaliciousWebSever

Users can potentially being recorded with Javascript code downloaded from a malicious Web Server.

Malicious Script

SRTP

Page 18: WebRTC Security

Access to screen capture. Threats

MaliciousWebSever

SRTP

Malicious Script

Security in screen sharing is specially critical as very sensitive information can be stolen.

Page 19: WebRTC Security

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

Page 20: WebRTC Security

Websocket DoS. Threats

Browser N

Attacked Server

websocket

MaliciousWebSever

Websocket allows cross-origin connection. DDoS attacks can be implemented in a Web-oriented way.

Browser 1

websocket

httphttp

Malicious Script

Malicious Script

Page 21: WebRTC Security

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

Page 22: WebRTC Security

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!

Page 23: WebRTC Security

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.

Page 24: WebRTC Security

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

Page 25: WebRTC Security

Protection

Page 26: WebRTC Security

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!

Page 27: WebRTC Security

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.

Page 28: WebRTC Security

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.

Page 29: WebRTC Security

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)

Page 30: WebRTC Security

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 OKVia: SIP/2.0/WS NO72tU858jVE.invalid;branch=z9hG4bKFhlN824OuTkQrgQl7FD8t1ejvP080E;rport=48095;received=46.25.57.69

Browser-To-ServerServer-To-Browser

Page 31: WebRTC Security

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).

Page 32: WebRTC Security

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.

Page 33: WebRTC Security

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.

Page 34: WebRTC Security

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.

Page 35: WebRTC Security

ID management

Page 36: WebRTC Security

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

Page 37: WebRTC Security

Identity management. OpenID

Makes possible to be sure of the identity using a thirdparty

New opportunity for operators as Identity Providers: Mobile number as Trusted Identity

Page 38: WebRTC Security

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.

Page 39: WebRTC Security

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=0o=- 1181923068 1181923196 IN IP4 ua1.example.coms=example1c=IN IP4 ua1.example.coma=setup:actpassa=fingerprint: SHA-1 \4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:ABa=identity: \ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n \dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v \cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs \XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg==t=0 0m=audio 6056 RTP/SAVP 0a=sendrecv

WebRTC API defined by W3C

Page 40: WebRTC Security

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

Page 41: WebRTC Security

WebRTC, IMS, Security and Identities

Page 42: WebRTC Security

WebRTC access to IMS

Page 43: WebRTC Security

WebRTC access to IMS

Page 44: WebRTC Security
Page 45: WebRTC Security

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)

Page 46: WebRTC Security

Registration and authentication

SIP/IMS vs Web Authentication

Page 47: WebRTC Security

WebRTC is signaling agnostic, SIPoWS is just one option

Page 48: WebRTC Security

SIP can be used with Web Authentication

Page 49: WebRTC Security

IMS can be used with Web Authentication

Page 50: WebRTC Security

Authentication of WebRTC IMS Client with IMS subscription using web credentials

Page 51: WebRTC Security

Control plane security

Page 52: WebRTC Security

Media plane security

Page 53: WebRTC Security

Media security for RTP

Page 54: WebRTC Security

Media Security for WebRTC DataChannels

Page 55: WebRTC Security

NAT traversal

In order to traverse restrictive-firewalls one could also use TCP/TLS transport. Some, are even multiplexing that over HTTP-based connections

Page 56: WebRTC Security

Firewall and HTTP proxy traversal

Page 57: WebRTC Security

Additional Considerations

Page 58: WebRTC Security

Specs perspective

Page 59: WebRTC Security

How is it really deployed in the real world?

other existing systems

Experience from 100+ field trials/POCs

Page 60: WebRTC Security

Customer Use Case: Service Provider in CALA

Page 61: WebRTC Security

Customer Use Case: Service Provider in EMEA

Page 62: WebRTC Security

Customer Use Case: Service Provider in APAC

Page 63: WebRTC Security

Summary

Page 64: WebRTC Security

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

Page 65: WebRTC Security

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.

[email protected]

Page 66: WebRTC Security

Planning to be in Barcelona during MWC15?

Register today for this free event at http://www.meetup.com/WebRTC-Barcelona