WebRTC security+more @ KamailioWorld 2018

1. Security, Authentication and Privacy: The WebRTC Challenge Lorenzo Miniero @elminiero Kamailio World May 16th 2018,

2. Before we start... Lorenzo Miniero • Ph.D @ UniNA • Chairman @ Meetecho • Open source believer Contacts and info • http://www.meetecho.com • https://twitter.com/elminiero • https://www.slideshare.net/LorenzoMiniero

5. Nope, not going to talk about Janus, today...

6. Nope, not going to talk about Janus, today... ... but it will reappear before we wrap this up!

7. A bit of history (of evil) • Several security threats • Interception and modiﬁcation • Abuse of Service (fraud) • Interruption of Service (Denial of Service attacks) • Social attacks (SPAM over Internet Telephony) • Hard to take care of them all • Several protocols/components/topologies involved • Completely different attacks (RTP bleed anyone?) Where do you typically start? Securing the protocols themselves with some good ol’ encryption! • SIP/TLS will protect negotiation info too

10. “Think of the media!”

11. Securing RTP • Not as easy as securing SIP • Might use RTP/TLS, but... • RTP is almost always transported over UDP • TCP not suitable for its real-time requirements • Might use RTP/IPsec, but... • Assumes IPsec is available (e.g., in a VPN) • A lot of overhead involved Secure Real-time Transport Protocol (SRTP) https://tools.ietf.org/html/rfc3711 • Extends RTP to make it “secure” • Authentication, integrity, protection against replay

15. Secure Real-time Transport Protocol (SRTP)

16. Key Exchange (1) • SRTP speciﬁes how to encrypt packets... • ... but not how to exchange keys • Several alternatives • MIKEY (Multimedia Internet KEYing) • https://tools.ietf.org/html/rfc3830 • Ticket-Based system • Too complex for VoIP? (but used by 3GPP) • ZRTP (Zimmermann RTP) • https://tools.ietf.org/html/rfc6189 (Informational!) • Focus on end-to-end (no need for PKI) • Difﬁe-Hellman on Media path (no need for encrypted signalling)

20. ZRTP (Zimmermann Secure RTP)

21. Key Exchange (2) • SDES-SRTP (Secure Description) • https://tools.ietf.org/html/rfc4568 • Simple, widespread • Exchanges keys in SDP (requires secure signalling) • DTLS-SRTP (Datagram Transport Layer Security) • https://tools.ietf.org/html/rfc5763 • Exploits DTLS, which is “like TLS” but for UDP • SDP transports certiﬁcate ﬁngerprints (keys exchanged in DTLS) Hot topic in the IETF (RTPSEC BOF was a long time ago, March 2007) • http://www.ietf.org/proceedings/68/rtpsec.html

24. Secure Description (SDES) • Simple mechanism to negotiate parameters • Negotiation in SDP as additional a-line a=crypto:<tag> <crypto-suite> inline:<key||salt> [session-parms] • Supported crypto-suites (AES/SHA1 variations, GCM, ...) • AES_CM_128_HMAC_SHA1_80 • AES_CM_128_HMAC_SHA1_32 • F8_128_HMAC_SHA1_32 • ... • Master key and salt provided inline • Concatenated and base64 encoded • Secure only if no one has access to the SDP...

27. Secure Description (SDES)

28. Datagram Transport Layer Security (DTLS) • Recent standard, favourite in the IETF • But not very deployed up to very recently... • SRTP keys exchanged over DTLS • https://tools.ietf.org/html/rfc5764 • Ad-hoc extensions for SRTP keys (use_srtp) • Media still SRTP! (DTLS not used as a transport) • SDP still used for negotiation, but does not contain keys • Cryptographic handshake done in-band (à-la ZRTP), over media channel • Basically TLS over UDP • Handshake authenticated via certiﬁcate ﬁngerprint • Fingerprint is what is exchanged via SDP • Some additional parameters related to DTLS and roles

33. Enter WebRTC/RTCWEB... • Standard effort to build real-time communications integrated in browsers • Re-uses pre-existing standards, with some enhancements, and adds others • SDP, SRTP, ICE, and others (but not SIP) are all there, “on steroids” • Strong emphasis on security and privacy • https://tools.ietf.org/html/draft-ietf-rtcweb-security • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch • Media security is mandatory • https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage • MUST implement DTLS-SRTP (with ECDHE+ECDSA) • NULL ciphers and SDES-SRTP MUST NOT be supported • In browsers, HTTPS mandatory as well (to avoid messing with ﬁngerprints)

37. The WebRTC “trapezoid” (hey, it looks like SIP!)

38. It really isn’t SIP, though... • Negotiation (Signalling completely agnostic!) • Javascript Session Establishment Protocol (JSEP) • Session Description Protocol (SDP) adaptation • Connection Establishment and NAT Traversal • Session Traversal Utilities for NAT (STUN) • Traversal Using Relay NAT (TURN) • Interactive Connectivity Establishment (ICE) • Media Transport and Control • Real-time Transport (and Control) Protocol (RTP/RTCP) • Secure Extensions to RTP (SRTP) • Datagram Transport Layer Security (DTLS) • Multimedia codecs • Opus audio codec (MTI, Mandatory-to-implement) • VP8 and H.264 video codecs (MTI, Mandatory-to-implement) • Generic Data • WebRTC Data Channels (SCTP)

39. The WebRTC protocol suite

40. WebRTC Security Architecture • Basic concept: trust no one but yourself (as in “your browser” is the TCB) • ... well, and the webserver if HTTPS is veriﬁed (SDP goes there)... • ... and other users if we can verify them too! • Steps that WebRTC endpoints must take care of 1 Consent to access local devices (only UIs) 2 Media consent veriﬁcation (ICE) 3 Secure exchange of crypto keys (DTLS) 4 Secure delivery of media packets (SRTP) 5 “Content freshness” (STUN keepalives) Proposed Standard (learning more) • https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch

50. Does WebRTC “RTP bleed” too? • RTP bleed is a well known issue, now • https://www.rtpbleed.com/ • https://fosdem.org/2018/schedule/event/rtpbleed/ • Basically caused by so-called “media latching” RTP servers often do • Rather than sending to negotiated address, they send to who last sent them media • Simple trick to help with NATs (you don’t need ICE), but terrible for security • Any session can be highjacked or disrupted by just sending stuff to the right port Thanks to its architecture WebRTC is typically NOT affected, though • Media is always encrypted, and connectivity paths are authenticated with ICE • https://www.rtpbleed.com/#so-is-webrtc-also-vulnerable

53. What about “Man in the Middle” attacks? https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks/

54. What about “Man in the Middle” attacks? https://webrtchacks.com/webrtc-and-man-in-the-middle-attacks/

55. The proposed solution: Identity Providers! • All certificates in WebRTC are self-signed • How can I trust a user/verify the fingerprint? • Identity Verification via Identity Providers • PeerConnection generates fingerprints • User authenticates at IdP and sends info • IdP generates Identity Assertion (to be put in SDP) • Peers validate each other against IdPs Playing with Identity Providers • Client side currently only available in Firefox • http://w3c.github.io/webrtc-pc/#sec.identity-proxy • Hackaton at latest IETF101 for Identity Services • http://webrtcbydralex.com/index.php/2018/03/22/

59. Example of Identity Assertion (IdP) { "fingerprint": [ { "algorithm": "sha-256", "digest": "4A:AD:B9:B1:3F:...:E5:7C:AB" }, { "algorithm": "sha-1", "digest": "74:E9:76:C8:19:...:F4:45:6B" } ] }

60. Example of Identity Assertion (SDP) v=0 o=- 1181923068 1181923196 IN IP4 ua1.example.com s=example1 c=IN IP4 ua1.example.com 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: eyJpZHAiOnsiZG9tYWluIjoiZXhhbXBsZS5vcmciLCJwcm90b2NvbCI6ImJvZ3Vz In0sImFzc2VydGlvbiI6IntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5vcmdc IixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIsXCJz aWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9 a=... t=0 0 m=audio 6056 RTP/SAVP 0 a=sendrecv ...

61. What about privacy? • You may have heard this many times... • “This site uses fake datachannels to locate me!” • “WebRTC leaks my real IP address even behind a VPN/proxy!” • Four speciﬁc modes for WebRTC behaviour 1 Enumerate all addresses (best media path, but most info disclosed) 2 Default route + associated local addresses (typically same route as HTTP trafﬁc) 3 Default route only (quality implications) 4 Force proxy (reduced quality if proxy doesn’t support UDP) • Mode 1 only used in case of user consent, otherwise fallback to Mode 2 • What is consent, though? (using getUserMedia for that would be terrible...) • Hot debate the past few weeks on the RTCWEB mailing list WebRTC IP Address Handling Requirements • https://tools.ietf.org/html/draft-ietf-rtcweb-ip-handling

65. Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) • Media security works “great” for peer-to-peer • What if I want to join a media conference, though? • Several approaches to conferencing • Full-mesh (everybody connects to everybody) • Multi-point Control Unit (MCU) → server! • Selective Forwarding Unit (SFU) → server! • Going through an SFU or MCU, you “see” the server, not the users Private Media Requirements in Privacy Enhanced RTP Conferencing (PERC) https://datatracker.ietf.org/wg/perc/charter/ • Ensure end-to-end conﬁdentiality/authentication • No need to “trust” elements on the media path

69. Selective Forwarding Unit (SFU) https://webrtchacks.com/webrtc-beyond-one-one/

70. Double Encryption with PERC Lite https://www.slideshare.net/alexpiwi5/perc-webrtc-e2e-media-encryption-with-sfu

71. Prototyping PERC Lite with Janus http://www.meetecho.com/blog/meetecho-and-cosmo-strike-again-perc-lite-integration-in-janus/

72. What else can PERC help with? • PERC originally conceived for multimedia conferencing • Double encryption to preserve end-to-end encryption properties • The same concept can be reused in other contexts, though • e.g., what about multimedia streaming and DRM via WebRTC? • Encrypted content can only be played if you have the right key • Played a bit with this in the Janus Record&Play feature • PERC Lite integration to preserve end-to-end encryption properties • Recording contains end-to-end encrypted RTP packets in .mjr ﬁle • Replay needs to happen in PERC Lite session with the original key • Ad-hoc tools to decrypt/encrypt recordings on the server side • Useful for having different keys for different sessions

76. Encrypted recordings with Janus+PERC Lite https://ieeexplore.ieee.org/document/8169749/

81. An interesting use case: SHINE • Secure Hybrid In Network caching Environment • Security and Content Rights Management • Satellite-assisted In Network Caching Systems https://artes.esa.int/projects/shine-secure-hybrid-network-caching-environment

82. An interesting use case: SHINE • Secure Hybrid In Network caching Environment • Security and Content Rights Management • Satellite-assisted In Network Caching Systems https://artes.esa.int/projects/shine-secure-hybrid-network-caching-environment

83. Thanks! Questions? Comments? Get in touch! • https://twitter.com/elminiero • https://twitter.com/meetecho • http://www.meetecho.com

WebRTC security+more @ KamailioWorld 2018

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie WebRTC security+more @ KamailioWorld 2018

Ähnlich wie WebRTC security+more @ KamailioWorld 2018 (20)

Mehr von Lorenzo Miniero

Mehr von Lorenzo Miniero (14)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

WebRTC security+more @ KamailioWorld 2018