October 4, 2012 archive

Oct 04

DANE Test Sites

The following sites support the DANE protocol by publishing TLSA records. If you are developing software that supports the DANE protocol, you can visit these sites to test your DANE support.  Note that we use the term “TLS certificate” here for what is commonly referred to as a “SSL certificate”.

 HTTP – Valid TLSA Record With Valid CA-signed TLS Certificate

The following sites use a valid CA-signed TLS certificate, but the CA is CAcert, a free CA that is not commonly configured in web browsers:

The following site has a valid TLSA record and a valid CA-signed TLS certificate, but the domain is not tied into the global DNSSEC chain-of-trust, i.e. there is no DS record for huque.com in the .COM TLD:

HTTP – Valid TLSA Record With Valid Self-signed TLS Certificate

HTTP – Valid TLSA Record With Invalid CA-signed TLS Certificate

HTTP – Invalid (Broken) TLSA Record

HTTP – Valid TLSA Record With Invalid DNSSEC Signature

SMTP

The following sites support using DANE for email by publishing TLSA records associated with MX records:

  • jhcloos.com
  • nlnetlabs.nl (for ports 25, 465, 587)
  • nlnet.nl (for ports 25, 465, 587)

XMPP / Jabber

The following sites support using DANE for TLS connections to their XMPP/Jabber server:

  • jabber.nlnetlabs.nl

Adding More Sites

If you support DANE with your site and would like to add it to this list, please contact us. Eventually, of course, we would like to hope that DANE is so widely deployed that this list of test sites will no longer be needed.

Oct 04

RFC 6698 – The DNS-Based Authentication of Named Entities

For anyone interested in how to better secure the Internet, the DANE protocol (“DNS-Based Authentication of Named Entities“) provides a mechanism for using DNSSEC to specify precisely which SSL/TLS certificate you want people to use to connect to your web server or other Internet service.  This provides a mechanism for ensuring that you are in fact using the correct certificate and your connection is not being intercepted by anyone in your network path.  DANE is defined in RFC 6698 at:

The abstract is:

Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain’s TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software.

Please view our page on the DANE protocol for more information about how the protocol can be used and how it helps make the Internet more secure.

Oct 04

The DANE Protocol – DNS-Based Authentication of Named Entities

If you connect to a website using a “secure” connection over TLS/SSL, how do you know you are using the correct TLS/SSL certificate?

You may see the “lock” icon in your web browser, but are you sure that you are connecting all the way to the website using the correct TLS certificate?  It is in fact quite possible – and quite common – for a firewall or other device in your network path to terminate your TLS connection with a website and then re-create a TLS connection from the device to your browser.  You think you have a secure, encrypted connection to your bank, for instance, but in fact your connection has been intercepted and the firewall or other device is able to see, and potentially record, all your interaction with the web site.

With DNSSEC now being deployed, a new protocol has emerged called “DANE” (“DNS-Based Authentication of Named Entities“) that allows you to securely specify exactly which TLS/SSL certificate a browser should use to connect to your site.  If a web browser supporting DANE detects that it is NOT using the specified certificate, it can warn you that your connection is insecure… even though you see a “lock” icon.

DANE is defined in RFC 6698 and over the next few months we will be adding more tutorials and document to this site to help you understand both how DANE helps make the Internet more secure and also how you can get started either publishing TLSA records for your domain – or using DANE within your application.  Note that DANE is not just for websites. People are already looking at how DANE can be used to secure email, VoIP and other web services.

For an explanation of the DANE protocol, watch this interview with Warren Kumari, co-chair of the DANE Working Group within the IETF:

[Additional screencast to be inserted here explaining how DANE works.]

Another good introduction to DANE is an IETF Journal article published in October 2011 titled “DANE: Taking TLS Authentication to the Next Level Using DNSSEC“. In the article, Richard Barnes explains why DANE is needed, outlines how it works, digs into some of the challenges with DANE implementation and provides a good number of links for more information.

Content Providers

[This section will explain to website owners/operators and providers of other services how they can publish TLSA records to make their sites more secure.]

Application Developers

The following libraries are in the process of adding support for the DANE protocol:

  • dnspython – the development version of dnspython found on Github has had support for TLSA records added to the code base. This is not yet available in a formal release.
  • ldns – an upcoming release of ldns will provide support for DANE (this page will be updated when the release occurs).

Other resources for developers:

  • DANE Test Sites – If you are adding DANE support to your application and wish to test out how well it works, the sites on this page are early supporters of the protocol and can be used in your testing.

Getting More Involved

If you would like to get more involved in the development of the DANE protocol and supporting documentation, you can: