In September of this year, we activated DNS-based Authentication of Named Entities (DANE) for our main web services, including www.ripe.net, the LIR Portal, RIPE Atlas and RIPE Labs.
Because the RIPE NCC already used DNSSEC to sign the .ripe.net zone, this was an easy extra step to take to augment the security of our websites. Our main concerns in deploying DANE were with software support and potential incompatibility, as well as the added complexity and maintenance burden on certificate rollovers that occur periodically. The implementation went well, but we'll keep an eye on developments in this field to ensure everything continues to go smoothly.
Implementation
Using the excellent " hash-slinger " tools created by Paul Wouters from RedHat, it was easy to generate the TLSA record from the website certificate:
$ tlsa --create --output rfc --usage 3 --certificate ripe.net.crt www.ripe.net _443._tcp.www.ripe.net. IN TLSA 3 0 1 6aef0c821fb98e13aa74bff193e9c3841403884d482a93acbc946157bb4a805c
N.B.: You may need to change the name field of the record and/or add a time-to-live field.
We then performed the changes in our zone and re-signed it. The result can be easily tested with dig:
$ dig +dnssec +noall +answer +multi _443._tcp.www.ripe.net. TLSA @193.0.9.6 _443._tcp.www.ripe.net. 300 IN TLSA 3 0 1 ( 6AEF0C821FB98E13AA74BFF193E9C3841403884D482A 93ACBC946157BB4A805C ) _443._tcp.www.ripe.net. 300 IN RRSIG TLSA 5 5 300 ( 20151212100803 20151112090803 35970 ripe.net. QhQG9QMjqaWUABCupsb0dPXf6uggf/rI8IeFkapR+RqE dzDVp5C65nciVqUm7E0UCBpiS8OLNVLYyRomxHBDOSCH sY9KxT2Du9uSB5Z6MBAgU7I3IG5FrvSh6/JKRm9H4vmN v7XZaS7VvxT6F0E1hHZtDFpKtME1fUO+EJTrnaY= )
Validation tools
In order to validate the DANE records and actually make use of their added layer of authentication, there are a number of tools we can use. From the command-line, the aforementioned tlsa command also performs verification (however, note that it does not understand the wildcard notation in the hostname):
$ tlsa --verify www.ripe.net WARNING: Name on the certificate (Subject: /C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=*.ripe.net, SubjectAltName: DNS:*.ripe.net, DNS:ripe.net) doesn't match requested hostname (www.ripe.net). Caution: name on the cert does not match hostname SUCCESS (usage 3): The certificate offered by the server matches the TLSA record WARNING: Name on the certificate (Subject: /C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=*.ripe.net, SubjectAltName: DNS:*.ripe.net, DNS:ripe.net) doesn't match requested hostname (www.ripe.net). Caution: name on the cert does not match hostname SUCCESS (usage 3): The certificate offered by the server matches the TLSA record
No browser supports DANE validation natively yet, but there is an add-on available for all major browsers: DNSSEC/TLSA Validator . During our testing the extension worked well, but it did increase browser instability when enabled (at least for Firefox). We hope that browser vendors will start supporting DANE validation by default and make it a standard feature as its use expands.
Certificate rollover
In order to make sure that no validation errors would occur during certificate renewal and rollover, we have documented and applied the following system:
- The new SSL certificate is generated one month before the old SSL certificate expires.
- A new TLSA record for the new SSL certificate is added to the DNS zone file, keeping the old TLSA record as well.
- During the following months, either certificate will be considered valid by the browser.
- We perform the rollover and replace old SSL certificates.
- A week after the old SSL certificates have been replaced, the old TLSA records are removed from the DNS zone file.
Going forward
DANE is a new technology and many details still have to be worked out. We will keep track of developments in the field and update our set-up as improvements are implemented. Are you deploying DANE for your websites? Do you have any tips or suggestions for improvement? Please leave a comment and let us know!
Comments 9
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Marco Davids •
Nice post! ldns-dane also works nice: http://manpages.ubuntu.com/manpages/utopic/man1/ldns-dane.1.html And here's a nice DANE-checker: https://check.sidnlabs.nl/dane/ (there are others as well, but this one is ours)
Mihnea-Costin Grigore •
Thank you for the additional links, Marco, they are quite useful. The SIDNLabs checker looks very good!
Stéphane Bortzmeyer •
How do you monitor it? Is there a monitoring plugin for Nagios-compatible programs? I ask so because I really fear that people may update the certificate but forget about the DNS (it is typically two different teams). Procedures are OK but monitoring is better.
Hide replies
Mihnea-Costin Grigore •
Thank you Stéphane, you bring up a good point. Like everything surrounding DANE, monitoring is also a bit experimental at the moment so we're testing various approaches. There is a Nagios/Icinga plugin available: https://exchange.icinga.org/debfx/check_dane -- we're currently investigating it with the aim of production deployment.
Hide replies
Stéphane Bortzmeyer •
This article describes in detail the use of debfx with Icinga 2 to monitor DANE : https://www.d7031.de/content/checking-dns-and-dnssec-with-icinga2/
Drewbert •
Until the major browsers support DANE straight out of the box, DANE is a lame duck. I can't see any sign of them doing so. The duck is not looking well. Google is insisting on https. The CA's are smelling profit in the air. Can't ICANN's SSAC do something about it?
Drewbert •
Evidence of the browser writers distain... Searching https://wiki.mozilla.org/ for DANE gets you 7 results. The latest one ( https://wiki.mozilla.org/MOSS ) mentions DNSSEC/DANE Chain Stapling https://wiki.mozilla.org/SecurityEngineering/WorkingSessions/09-18-13-NetworkTeam gives their 2013 opinion of Dane: #### DANE? I think we all agree it's not the right way forward And slow #### and in https://wiki.mozilla.org/NSS:BurnDownList ... #### DANE is in the "Needs Definition / Prioritization" List (Needs further definition, discussion, design, or prioritization before an engineer can implement it.) Level of effort: To be determined Notes: "Nice to have, but doesn't solve all the problems, and there is no commitment that a majority will use it." #### So it's agreed then. Mozilla aren't interested? How about Google Chrome? https://bugs.chromium.org/p/chromium/issues/detail?id=50874 Some brave soul was an optimist at the start: #### "i think it would be usefull to start implementing DNSSEC validation. there are libraries for this. For example: libval from http://dnssec-tools.org/ and minimalistic libldns from http://www.nlnetlabs.nl/projects/ldns/ (which i can really suggest to you)." #### agl@chromium.org hammers the first nail into the coffin... #### "We are considering our position with respect to DNSSEC. DNSSEC validation of A records and the like isn't useful and doesn't warrant any UI indication. DNSSEC validation of certificates may, but it would be premature to submit patches for that at this time." #### Our optimist tries again... #### It will be super-awesome if chromium will manage to get DANE support as technology-leading browser. DANE is really big step forwards for internet security... #### someone else who had their account deleted tried to back him up... #### Have there been any changes in the plans to include DNSSEC and DANE support in Chromium? It seems like this feature has been dead for a while now, given that DANE was standardized in RFC 6698 in 2012. It's been a few years and it seems like everybody has stalled in providing support for it. I can't find a reference atm, but I believe that it was the ISC that said that some 45-50% of SSL certs used in the wild are self-signed; widespread support and deployment of DANE/DNSSEC would go a long way of providing security to the users of those 45-50% of SSL certs. I would love if Chrome would lead the world in providing production-quality client support for DNSSEC and DANE. #### Then the nail is hammered home... #### Closing this out as WontFix, as there are no plans. The ISC number is not accurate for what real world users experience, and is biased by crawls that have a number of experimental limits. DNSSEC and DANE (types 2/3) do not measurably raise the bar for security compared to alternatives, and can be negative for security. DNSSEC+DANE (types 0/1) can be accomplished via HTTP Public Key Pinning to the same effect, and with a much more reliable and consistent delivery mechanism. While not desiring to stifle discussion, we've continued to evaluate the security and usability benefits and costs of DNSSEC and DANE, and will continue to do so, but for now, this is neither something we plan to implement nor would support landing. #### So is the status for FireFox and Chrome still this? If so, all the hard work put into DANE and ICANN's implementation of DNSSEC seems to have all been a waste of time?
Chris •
All of this has not aged well. The linked Browser Add-On is no longer developed or support because WebExtensions, Browsers have removed drawn support for Public Key Pinning and not replaced it with DANE, and www.ripe.net's DANE record has been invalid for months now (but not labs.ripe.net).
Hide replies
Mihnea-Costin Grigore •
Chris, you are sadly correct about the poor adoption of DANE during the past six years. The technology is still sound and very much needed, unfortunately it ran against the interests of major enterprises (as it brakes SSL snooping tools) which meant it would never be implemented by the FAMANG group. As Chrome is developed by Google, it's not surprising that they moved away from it, however one would have hoped to see Firefox pick up the task, which they also didn't. The fact that not even Apple is pursuing this technology, despite their alleged focus on privacy and security, makes the case that it may be a losing battle. All the focus seems to now be on Certificate Transparency (https://certificate.transparency.dev/) -- though that covers a different, complementary issue in my opinion. When it comes to the RIPE NCC website itself, the problems is that they're using CloudFlare as a CDN (including their certificates), which means the TLSA records should also be updated in conjunction. Labs is not on the CDN for the time being. I'm not sure what options they have for managing TLSA records within the CloudFlare tools, but maybe a note to webmaster@ripe.net will provide more info?