ION Cape Town, 8 September 2015 - If you connect to a “secure” server using TLS/SSL (such as a web server, email server or xmpp server), how do you know you are using the correct certificate? With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“), which allows you to securely specify exactly which TLS/SSL certificate an application should use to connect to your site. DANE has great potential to make the Internet much more secure by marrying the strong integrity protection of DNSSEC with the confidentiality of SSL/TLS certificates. In this session, we will explain how DANE works and how you can use it to secure your websites, email, XMPP, VoIP, and other web services.
Integration and Automation in Practice: CI/CD in Mule Integration and Automat...
ION Cape Town - DANE: The Future of Transport Layer Security (TLS)
1. DANE: The Future of Transport Layer Security
(TLS)
ION Cape Town, South Africa
September 8, 2015
Michuki Mwangi
Regional Development Manager
Internet Society
mwangi@isoc.org
2. TLS vs SSL
Secure Sockets Layer (SSL) originally developed by
Netscape in the mid-1990s
"Transport Layer Security (TLS)" evolved from SSL 3.0,
although "SSL" remains commonly used term
TLS version 1.3 in active development:
• https://tools.ietf.org/html/draft-ietf-tls-tls13
• https://github.com/tlswg/tls13-spec
9/8/2015
1996 SSL 3.0 RFC 6101
1999 TLS 1.0 RFC 2246
2006 TLS 1.1 RFC 4346
2008 TLS 1.2 RFC 5246
2014/15? TLS 1.3 draft-ietf-tls-tls13
3. TLS – Not Just For Web Sites
TLS / SSL originally developed for web sites
Now widely used for many other services, including:
• Email
• Instant messaging
• File transfer
• Virtual Private Networks (VPNs)
• Voice over IP (VoIP)
• Custom applications
4. What Does TLS Do?
• Creates an encrypted tunnel between two applications
• Protects from eavesdropping
• Can be used in client/server or peer-to-peer
• Uses TCP (DTLS uses UDP)
App 1 App 2
App 1 App 2
With TLS
Without TLS
5. TLS and Certificates
• How do you obtain the encryption keys?
• Typically uses PKIX / X.509 certificate
• Certificate signed by a Certificate Authority (CA)
• The client application initiating the connection checks
the certificate:
• Does the certificate match the site/service being visited?
• Does the app trust the CA who signed the cert?
6. The Problem With Certificate Authorities
• There are too many of them!
• Apps like web browsers may “trust” 1,300 Cas
• Any CA can issue a certificate for any domain
• Attackers can trick a CA into issuing a certificate
• “Middleboxes” can issue certificates to intercept
traffic
• Ex. Gogo inflight WiFi service
• Several different solutions being explored
8. The Typical TLS (SSL) Web Interaction
Web
Server
Web
Browser
https://example.com/
TLS-encrypted
web page
DNS
Resolver
example.com?
10.1.1.1231
2
5
6
DNS Svr
example.co
m
DNS Svr
.com
DNS Svr
root
3
10.1.1.123
4
9. The Typical TLS (SSL) Web Interaction
Web
Server
Web
Browser
https://example.com/
TLS-encrypted
web page
DNS
Resolver
10.1.1.1231
2
5
6
DNS Svr
example.co
m
DNS Svr
.com
DNS Svr
root
3
10.1.1.123
4
Is this encrypted
with the
CORRECT
certificate?
example.com?
11. DANE
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
1
2
Firewall
(or
attacker)
https://example.com/
TLS-encrypted web page
with NEW certificate
(re-signed by firewall)
Log
files or
other
servers
DANE-equipped browser
compares TLS certificate
with what DNS / DNSSEC
says it should be.
example.com?
12. 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.
An application 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.
13. DANE RR Format – RFC 6698
The DANE DNS Resource Record value is “TLSA”
The TLSA RR has no special TTL requirements
TLSA RDATA format has 4 fields
Certificate Usage
( 1 octet)
Selector
(1 octet)
Matching Type
(1 octet)
14. DANE – Different operation modes
("certificate usage" field)
• 0 – CA specification
• The TLSA record specifies the Certificate Authority (CA) who will provide TLS
certificates for the domain. Must be a valid CA included in browser/app.
• 1 – Specific TLS certificate
• The TLSA record specifies the exact TLS certificate that should be used for the
domain. Note that this TLS certificate must be one that is issued by a valid CA.
• 2 – Trust anchor assertion
• The TLSA record specifies the “trust anchor” to be used for validating the TLS
certificates for the domain. Allows for the use of a CA not included in
application.
• 3 – Domain-issued certificate (“End-Entity Certificate”)
• The TLS record specifies the exact TLS certificate that should be used for the
domain, BUT, in contrast to usage #1, the TLS certificate does not need to be
signed by a valid CA. This allows for the use of self-signed certificates.
15. DANE – TLSA Selector Field
Specifies which part of the TLS certificate presented
by the server will be matched against the association
data
0 – Full Certificate: The certificate binary structure
1 – SubjectPublicKeyInfo: DER-encoded binary structure
16. DANE: TLSA Matching Type
The matching type specifies how the certification
association data defined in the Selector Field is
presented
0 – Exact match on selected content
1 – SHA-256 hash of selected content
2 – SHA-512 hash of selected content
17. DANE: TLSA Certificate Association Data Field
This specifies the “certificate association data field”
to be matched
This is where either the Full Certificate or the
SubjectPublicKeyInfo as defined on selector field and
matching type field options (raw data or hash) is stored.
18. TLSA RR Examples
An example of a hashed (SHA-256) association of a PKIX
CA certificate:
_443._tcp.www.example.com. IN TLSA (
0 0 1 d2abde240d7cd3ee6b4b28c54df034b9
7983a1d16e8a410e4561cb106618e971 )
App host
FQDN
Full CA
certificate
hash
Application
Port
Transport
protocol
19. DANE – Not Just For The Web
• DANE defines protocol for storing TLS certificates in DNS
• Securing Web transactions is an obvious use case
• Other uses also possible:
• Email
• VoIP
• Jabber/XMPP
• PGP
• ?
20. DANE Success Stories
SMTP
360+ SMTP servers with TLSA records
http://www.tlsa.info/ - testing service
XMPP (Jabber)
255 servers
client-to-server & server-to-server
https://xmpp.net/reports.php#dnssecdane
Advertisements!
21. 3 Steps To Use DANE On Your Server / Service
1. Use TLS on your application/service!
2. Generate and publish a TLSA record in DNS
Separate TLSA record for each specific service. For example:
– _25._tcp.example.com.
– _443._tcp.example.com.
Tools available (ex. hashslinger) to help generate records
3. Sign your domain with DNSSEC
22. 2 Steps To Use DANE In Your Client Application
1. Have access to a DNSSEC-validating DNS resolver
Security of DANE relies on DNSSEC validation
DNSSEC validation can be easily enabled on BIND, Unbound or
Windows Server
Some developers have performed validation within actual application
2. Use a DNS application library that supports DNSSEC
GetDNS API – http://getdnsapi.net/ - C, python, node.js and java
http://www.internetsociety.org/deploy360/resources/dnssec-developer-
libraries/
23. 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
24. DANE Resources
DANE and email:
• https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane
• http://tools.ietf.org/html/draft-ietf-dane-smime
DANE Operational Guidance:
• https://tools.ietf.org/html/draft-ietf-dane-ops
DANE and SIP (VoIP):
• http://tools.ietf.org/html/draft-johansson-dispatch-dane-sip
• https://tools.ietf.org/html/draft-ietf-dane-srv
Other uses:
• https://tools.ietf.org/html/draft-ietf-dane-openpgpkey
• https://tools.ietf.org/html/draft-ietf-dane-rawkeys
26. Reasons For Deploying DNSSEC/DANE
• TRUST – You can be sure your customers are reaching
your sites – and that you are communicating with their
servers.
• SECURITY – You can be sure you are communicating
with the correct sites and not sharing business information
with attackers, ex. email hijacking.
• INNOVATION – Services such as DANE built on top of
DNSSEC enable innovative uses of TLS certificates
• CONFIDENTIALITY – DANE enables easier use of
encryption for applications and services that communicate
across the Internet
27. Email Hijacking – A Current Threat
• CERT-CC researchers have identified that someone is
hijacking email by using DNS cache poisoning of MX
records
• Could be prevented by DNSSEC deployment
• CERT-CC (Sept 10, 2014):
– https://www.cert.org/blogs/certcc/post.cfm?EntryID=206
• Deploy360 blog post (Sept 12, 2014):
• http://wp.me/p4eijv-5jI
29. Start Here Page
http://www.internetsociety.org/deploy360/start/
Easy method of finding resources for
specific audiences, including:
• Network operators
• Content providers (ex. web site
owners)
• Developers
• Governments
• Consumer electronics vendors
• Enterprises and campus networks
• Registrars
• Internet exchange points (IXPs)
30. The Two Parts of DNSSEC
Signing Validating
ISPs
Enterprises
Applications
DNS
Hosting
Registrars
Registries
31. 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)
32. DNSSEC Deployment Maps
• DNSSEC deployment maps:
• http://www.internetsociety.org/deploy360/dnssec/maps/
• Mailing list to receive weekly maps:
• https://elists.isoc.org/mailman/listinfo/dnssec-maps