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.
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 @220.127.116.11 _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= )
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.
DNSSEC/TLSA Validator in working in Firefox
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.
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!