E3-1 Protecting Yourself in a WebRTC World...WebRTC-SIP Gateways Will be Used –Are Required! Often...
Transcript of E3-1 Protecting Yourself in a WebRTC World...WebRTC-SIP Gateways Will be Used –Are Required! Often...
Protecting Yourself in a WebRTC World
Moderator
Lawrence ByrdTechnology Evangelist, Altocloud@LawrenceByrd@altocloud
Speakers
• Mykola KonradVP and GM, Cloud Business & Strategic Alliances
Sonus
• Karl StahlCTO and ChairmanIngate Systems
Moderator: Lawrence Byrd @LawrenceByrd
4
5
WebRTC can be the Wild West
6
Two Broad Use Cases Have Different Security Concerns
WebRTC GW
Browser1
TURN Server
Browser2
TURN Server
Browser
TURN Server
Policy DB
WebRTC GW
Carrier
IMS Core / PSTN
7
What Do You Need To Worry About With WebRTC?
Should be handled by the server
and http firewall
Still need a “traffic cop”
control function for authentication,
overload protection and signaling interworking
Malformed Signaling Packets are possible
- You will need to Inspect, monitor,
and act upon signaling packets
(call setup, teardown)
8
WebRTC Authentication
3GPP
SIP Registrar
IMS core
Enterprise
LDAP Active
Directory PBX
SIP Registrar
Custom
Solutions
Web
OAuth2.0
OpenID
9
Authentication Using Web ID
CarrierCustomer
TURN Server
Policy DBWebRTC GW
Identity Provider
10
Hosted UC
TURN Server
Policy DBWebRTC GW
Authentication Using Enterprise ID
CarrierCustomer
11
Large Enterprise Service Provider
Single Instance Sonus WRTC Gateway SWe Multi-Instance
Sonus WebRTC Gateway
Sonus WebRTC Gateway
• Web to SIP
• SDK
Signaling
SonusSBC 5100
Media
Interworking
SonusSBC 5200
Media
Interworking
Sonus SBC SWe
Media Interworking
12
• WebRTC provides a lot of good security
building blocks
• WebRTC diverse use cases foster diverse
identify & authentication schemes
• Thought needed about how to combine into
end-to-end security approach
• How do you want to identify your users
and bring them into your network?
Get free WebRTC dummies guide here
• http://info.sonus.net/webrtc-dummies-
snet-new
In Conclusion
Karl StahlCTO and ChairmanIngate [email protected] [email protected]
Ingate’s SBCs do more than POTSoIP SIP. They were developed for standard compliant end-to-end multimedia SIP connectivity everywhere.
WebRTC is just aligned – Ingate adds Q-TURN telepresence quality and the WebRTC & SIP Companion Gateway brings all WebRTC features to the enterprise PBX/UC Solution/call center and to the service provider next generation telephony.
Merged Intertex Data AB and Ingate Systems AB
WebRTC “Protection”– More or less challenging?
Should we be concerned?
Cannot even decline video…
And HTTPS only asks first time…
Firewalls and SBC won’t help. They don’t do (cannot do) these things. – They allow or not!
Is there a “security difference” compared to soft clients and Webex-like screen sharing applications?
Not much! But…
The big difference is that the browser is “always available”, used and we now have to trust the browser to provide the basic protection.
Can my screen be viewed also?
WebRTC & VoIP Security (and SBCs) – Confusing it is…
What is meant by “securing WebRTC”, “managing security” etc.? Says who?
• User: Privacy, confidentiality would be nice
• Carrier: Theft of service, DoS/Overload, don’t crash our systems
• Enterprise data department: Don’t send malicious packets into our LAN, don’t leak our information.
• Enterprise PBX / UC department: Make it work - always and everywhere, but keep our resources and information to ourselves.
And it is quite different:WebRTC in itself and integrated with the
“Enterprise PBX / UC social network”
WebRTC in Itself has Excellent Privacy
• Media is always encrypted between the endpoints. With DTLS-SRTP, only the browsers know the key.
• Signaling is not standardized and is most often over https (i.e. encrypted)
But that will not always be maintained when calls are gatewayed into other worlds
• VoIP Service Providers seldom use encryption anywhere
• Enterprise PBX / UC / call centers are hiding behind a firewall or an SBC Encryption is rarely used in the
current PSTN and VoIP carrier world
WebRTC in Itself is Quite Secure, but Consider…• Turn server needs DoS protection
• Does not traverse restrictive enterprise firewalls: ICE firewall traversal assumes it is open from the inside. Proposed media tunneling through open TCP 80 (http) or 443 (https) ports destroys quality. Data department may not want to open more.
• Quality on data-crowded pipes: WebRTCuses the Internet, where the access pipes are crowded with data traffic. No QoS since firewalls are unaware of real-time traffic, which ICE/STUN/TURN assumes.
LAN
CompanyWeb Server
Q-TURN RESOLVES
A Novel View on ICE – Q-TURN
Knock-knock; Give my Media a Quality Pipe
• Regard ICE as a request for real-time traffic through the firewall. Interpret the STUN & TURN signals in the firewall
• Have the STUN/TURN server functionality IN the firewall and set up the media flows under control
• Security is back in the right place - The firewall is in charge of what is traversing
• Enterprise firewall can still be restrictive
Q-TURN Enables QoS and More:
• Prioritization and Traffic Shaping
• Diffserv or RVSP QoS over the Net
• Authentication (in STUN and TURN)
• Accounting: Quality gigabits measured
WebRTC-SIP Gateways Will be Used – Are Required!Often Built on Top of SBCs – Do such SBCs Protect?
• An enterprise wants to have the WebRTC benefits into their PBX / UC / Call Center infrastructure. That is where their Auto attendant, Call Routing, Queues, Conference Bridge etc. are.
• and an enterprise UC solution of course benefits from browser-based clients, locally and remotely
• so do the IMS/VoLTE/RCS emerging networks
Such WebRTC – SIP Gateways require SBC functions like security, interoperability fix-ups and NAT/firewall traversal
LAN
CompanyWeb Server
SIP
WS
media
Q & A
• Mykola KonradVP and GM, Cloud Business & Strategic Alliances
Sonus
• Karl StahlCTO and ChairmanIngate Systems
Moderator: Lawrence Byrd @LawrenceByrd
23
Personal
Intuitive & Collaborative
Presence Enabled
Real Time
Bandwidth Intensive
Intelligent Delivery LayerSession Architects
Security, Signaling,
Scale, Interworking
Policy, Enable
Network Monetization
Programmable Network Layer
Routing
CompaniesLayer 2/3 Gateways
Mobile Social CloudApp Layer
Sonus Strategically Positioned at Intersection of Programmable Network and Application Layer
WebRTC Architecture
24
WebRTC Attacks
Browser to Browser
(Signaling plane still done in the core, even over secure web socket)
• Open Internet
• Browser to Enterprise (click to communicate)
Browser to Back-End
• Protect the border between SIP and WebRTC?
• Authentication issues
(Wild west of the web into your secure locked down environment)
Mobile Device Security
May be more secure if it is an application vs a java script being sent down
(may be an end user security issue because the app may show things
- more of an end user issue)
Secure Access
Rights and privileges to trusted connections for WebRTC browsers/users
(Google, Active Directory)
Data Channel Applications
………….