SIPNOC 2014 - Is It Time For TLS for SIP?

transcript

www.internetsociety.org/deploy360/

Is It Time For TLS For SIP?

SIP Network Operators Conference (SIPNOC) 2014 Herndon, VA, USA June 10, 2014

Dan York Internet Society

Dan York and VoIP/SIP

Mitel Networks, 2001 – 2007 •  Chair, product security team •  Product manager, SIP software, teleworking

Voxeo, 2007-2011 •  Cloud-based SIP operations

Blue Box: The VoIP Security Podcast, 2005-2008 - www.blueboxpodcast.com

Disruptive Telephony , 2006-present – www.disruptivetelephony.com

Author, Seven Deadliest Unified Communications Attacks, 2010 •  www.7ducattacks.com

VoIP Security Alliance (VOIPSA), 2005-present •  www.voipsa.org

Internet Engineering Task Force (IETF), 2006-present •  Active in Real-time Applications and Infrastructure (RAI) working groups

Joined Internet Society in September 2011

About the Deploy360 Programme

The Challenge: –  The IETF creates protocols based on open standards, but

some are not widely known or deployed

–  People seeking to implement these protocols are confused by a lack of clear, concise deployment information

The Deploy360 Solution: –  Provide hands-on information on IPv6, DNSSEC, BGP and

TLS to advance real-world deployment

–  Work with first adopters to collect and create technical resources and distribute these resources to fast following networks

Internet Society Deploy360 Programme

IPv6, DNSSEC, Securing BGP, TLS for Applications knowledge base including tutorials, case studies, training resources, etc.

Content specific to: –  Network Operators –  Developers –  Content Providers –  Consumer Electronics

Manufacturers –  Enterprise Customers

Blog posts

ION conferences, speaking, social media

Time For TLS?

6/10/14

TLS = Transport Layer Security TLS 1.0 ≈ SSL 3.0 RFC 2246 1999 TLS 1.1 RFC 4346 2006 TLS 1.2 RFC 5246 2008 TLS 1.3 draft-ietf-tls-rfc5246-bis

TLS – The Protocol Formerly Known As "SSL"

How many of you currently use TLS in SIP-based

communications?

Why not?

Reasons for not using TLS with SIP

•  Debugging

•  Network Monitoring •  Performance

•  Lack of Device/Application Support

•  Cost

•  Complexity

•  No customer demand

6/10/14

Why am I here at SIPNOC?

Snowden

Tinfoil Hats

6/10/14

https://www.flickr.com/photos/ripper/273262947

Tinfoil Hats Were Wrong – It Was Worse

6/10/14

https://www.flickr.com/photos/ncreedplayer/3210543345/

RFC 7280 - Pervasive Monitoring Is an Attack

"The IETF community's technical assessment is that pervasive monitoring (PM) is an attack on the privacy of Internet users and organisations. The IETF community has expressed strong agreement that PM is an attack that needs to be mitigated where possible, via the design of protocols that make PM significantly more expensive or infeasible."

•  http://tools.ietf.org/html/rfc7258 - May 2014

6/10/14

Not Waiting For New Standards

XMPP (Jabber) Community

•  As of May 19, 2014, over 70 public XMPP operators and developers have agreed to ONLY accept TLS-encrypted connections

•  https://github.com/stpeter/manifesto

•  http://blog.prosody.im/mandatory-encryption-on-xmpp-starts-today/

•  https://xmpp.net/

6/10/14

What can we do as the SIP operator community to

promote greater TLS usage?

Can we create our own manifesto?

A few caveats…

TLS Only Solves Part Of Privacy Protection

6/10/14

SRTP Is Needed For Media Protection

6/10/14

Our Simple Picture…

6/10/14

… Isn't So Simple

6/10/14

TLS Is Only Hop-by-hop, Not End-to-end

6/10/14

And "Unified Communications" Isn't Unified…

6/10/14

Physical Wiring IP

Network

IP-PBX

Voicemail

PSTN Gateways

Mobile Devices

IM Networks

Web Servers

Email Servers

Desktop PCs

Operating Systems

Firewalls

Internet

Directory Servers

CRM Systems

Social Networks

Database Servers

Application Servers

Session Border

Controllers

But…

We Have The Standards…

A partial list:

6/10/14

RFC 5280 X.509 Certificates and CRLs RFC 5922 Domain Certificates in SIP RFC 5923 Connection Re-use in SIP RFC 6072 Certificate Management System for SIP

RFC 3711 Secure Real-time Transport Protocol (SRTP) RFC 4568 SDP for SRTP RFC 5763 Using SRTP with DTLS RFC 6347 Datagram TLS (DTLS – "TLS for UDP")

We Have A Specification…

SIPconnect 1.1 requires TLS

www.sipforum.org/sipconnect

Caveat: Focused on SIP PBX to Service Provider connection

6/10/14

We Have The Tools…

TLS support can be found in most: •  IP-PBXs •  Softphones •  IP phones •  SIP applications

(But often simply not enabled)

6/10/14

One more caveat: Can we trust the

certificates?

1,500-ish CAs Any of whom can sign

for any domain

A Quick Overview of DANE Can it add more trust to TLS-based communication?

6/10/14

The Typical TLS (SSL) Web Interaction

Web Server

Web Browser

https://example.com/

TLS-encrypted web page

DNS Resolver

example.com?

10.1.1.123 1

6DNS Svr example.com

DNS Svr .com

DNS Svr root

10.1.1.123

The Typical TLS (SSL) Web Interaction

Web Server

Web Browser

TLS-encrypted web page

DNS Resolver

10.1.1.123 1

6DNS Svr example.com

DNS Svr .com

DNS Svr root

10.1.1.123

Is this encrypted with the

CORRECT certificate?

example.com?

Problems?

Web Server

Web Browser

https://www.example.com/ TLS-encrypted web page with CORRECT certificate

DNS Server

www.example.com?

1.2.3.4 1

Attacker (or firewall)

https://www.example.com/

TLS-encrypted web page with NEW certificate (re-signed by attacker) Log files

or other servers

DNS-Based Authentication of Named Entities (DANE) •  Q: How do you know if the TLS (SSL) certificate is the

correct one the site wants you to use?

•  A: Store the certificate (or fingerprint) in DNS (new TLSA record) and sign them with DNSSEC.

A browser that understand DNSSEC and DANE will then know when the required certificate is NOT being used.

Certificate stored in DNS is controlled by the domain name holder. It could be a certificate signed by a CA – or a self-signed certificate.

Web Server

Web Browser w/DANE

https://example.com/ TLS-encrypted web page with CORRECT certificate

DNS Server

10.1.1.123 DNSKEY RRSIGs TLSA

2Attacker (or firewall)

TLS-encrypted web page with NEW certificate (re-signed by attacker) Log files

or other servers

DANE-equipped browser compares TLS certificate with what DNS / DNSSEC says it should be.

example.com?

The DANE Protocol

•  DANE defined in RFC 6698 •  https://tools.ietf.org/html/rfc6698

•  TLSA record contains either a certificate or the public key of a certificate

•  Four modes of certificate usage: •  0 – "CA constraint" – limits which CA can be used for certificates •  1 – "service certificate constraint" – specifies exact CA-signed

certificate •  2 – "trust anchor assertion" – allows use of a new trust anchor (such

as a CA not included in the browser list) •  3 – "domain-issued certificate" – use of self-signed certificate

6/10/14

DANE – Not Just For The Web

•  DANE defines protocol for storing TLS certificates in DNS

•  Securing Web transactions is the obvious use case

•  Other uses also possible: •  Email via S/MIME

•  VoIP

•  Jabber/XMPP

•  PGP

•  ?

6/10/14

DANE Resources

DANE and SIP:

•  http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip

DANE and email: •  http://tools.ietf.org/html/draft-ietf-dane-smtp •  http://tools.ietf.org/html/draft-ietf-dane-smime

DANE Operational Guidance:

•  http://tools.ietf.org/html/draft-dukhovni-dane-ops

Other uses: •  http://tools.ietf.org/html/draft-wouters-dane-openpgp •  http://tools.ietf.org/html/draft-wouters-dane-otrfp

DANE Resources

DANE Overview and Resources:

•  http://www.internetsociety.org/deploy360/resources/dane/

IETF Journal article explaining DANE:

•  http://bit.ly/dane-dnssec

RFC 6394 - DANE Use Cases:

•  http://tools.ietf.org/html/rfc6394

RFC 6698 – DANE Protocol:

•  http://tools.ietf.org/html/rfc6698

Next Steps

Resources

Deploy360 Programme:

•  http://www.internetsociety.org/deploy360/tls/

Olle Johansson:

•  http://www.slideshare.net/oej/presentations

•  http://www.slideshare.net/oej/morecrypto-sip

Three Requests For Network Operators

1.  Require TLS for all SIP connections where possible

2.  Support industry efforts to increase TLS usage

3.  Help promote support of DANE protocol •  Allow usage of TLSA record. Let vendors and others know you want to

use DANE. Help raise awareness of how DANE and DNSSEC can make the Internet more secure.

york@isoc.org www.internetsociety.org/deploy360/

Dan York, CISSP Senior Content Strategist, Internet Society

Thank You!

Background: A Quick Overview of DNSSEC

6/10/14

A Normal DNS Interaction

Web Server

Web Browser

web page

DNS Resolver

10.1.1.123

DNS Svr example.com

DNS Svr .com

DNS Svr root

10.1.1.123

example.com NS

.com NS

example.com?

Attacking DNS

Web Server

Web Browser

web page

DNS Resolver

10.1.1.123

DNS Svr example.com

DNS Svr .com

DNS Svr root

192.168.2.2

AttackingDNS Svr example.com

192.168.2.2

example.com NS

.com NS

example.com?

A Poisoned Cache

Web Server

Web Browser

web page

DNS Resolver 1

192.168.2.2

Resolver cache now has wrong data:

example.com 192.168.2.2

This stays in the cache until the Time-To-Live (TTL) expires!

example.com?

A DNSSEC Interaction

Web Server

Web Browser

web page

DNS Resolver

10.1.1.123 DNSKEY RRSIGs

DNS Svr example.com

DNS Svr .com

DNS Svr root

10.1.1.123

example.com NS DS

.com NS DS

example.com?

Attempting to Spoof DNS

Web Server

Web Browser

web page

DNS Resolver

DNS Svr example.com

DNS Svr .com

DNS Svr root

SERVFAIL

AttackingDNS Svr example.com

example.com NS DS

.com NS DS

example.com?

The Two Parts of DNSSEC

Signing Validating

Enterprises

Applications

DNS Hosting

Registrars

Registries

DNSSEC Signing - The Individual Steps

Registry

Registrar

DNS Hosting Provider

Domain Name Registrant

•  Signs TLD •  Accepts DS records •  Publishes/signs records

•  Accepts DS records •  Sends DS to registry •  Provides UI for mgmt

•  Signs zones •  Publishes all records •  Provides UI for mgmt

•  Enables DNSSEC (unless automatic)

DNSSEC Signing - The Players

Registries

Registrars

DNS Hosting Providers

Domain Name Registrants

Registrar also provides DNS hosting services

DNSSEC Signing - The Players

Registries

Registrars

DNS Hosting Providers

Domain Name Registrants

Registrant hosts own DNS

Signing Can Be Simple

DNSSEC Resources

Deploy360 Programme:

•  www.internetsociety.org/deploy360/dnssec/

DNSSEC Deployment Initiative:

•  www.dnssec-deployment.org/

DNSSEC Tools:

•  www.dnssec-tools.org/

DNSSEC and VoIP:

•  www.internetsociety.org/deploy360/resources/dnssec-voip/

Three Requests For Network Operators (ISPs)

1.  Deploy DNSSEC-validating DNS resolvers

2.  Sign your own domains where possible

3.  Help promote support of DANE protocol •  Allow usage of TLSA record. Let browser vendors and others know you

want to use DANE. Help raise awareness of how DANE and DNSSEC can make the Internet more secure.

3 More Requests For SIP Network Operators

1.  Think about how and where DNSSEC and DANE could be potentially used

2.  Experiment with the early implementations like Jitsi and Kamailio

3.  Share the ideas…

•  Directly with me ( york@isoc.org ) or via email lists, online forums, etc.

•  http://www.internetsociety.org/deploy360/dnssec/community/

(or let's make a new place for DNSSEC and VoIP)

Helping Accelerate DNSSEC Deployment

https://elists.isoc.org/mailman/listinfo/dnssec-coord

Public mailing list, “dnssec-coord”, available and open to all:

Focus is on better coordinating promotion / advocacy / marketing activities related to DNSSEC deployment.

Monthly conference calls and informal meetings at ICANN and IETF events.

SIPNOC 2014 - Is It Time For TLS for SIP?

Technology