This manual is targeted at preventing programs like Filezilla or Firefox to access sites spoofed by secret services. A good introduction about the background of using DANE can also be found at the page of the atea tool. At first I will present a few scripts used to download certificate files and to retrieve the DNS TLSA ResourceRecords of a domain which contain a hash for the certificate file to check against. You can use certificate files for Filezilla. Later on I will show you how to configure them with the Firefox browser.
$ ./dldcert debian.org $ ./drill_TLSA debian.org _443._tcp.debian.org. 600 IN TLSA 3 1 1 5f33491e2b2d267f7bff096ad0dcb4ae5a22c0be19db0ab6728bed942f0719fc $ ./dig_TLSA -q debian.org _443._tcp.debian.org. 600 IN TLSA 3 1 1 5F33491E2B2D267F7BFF096AD0DCB4AE5A22C0BE19DB0AB6728BED94 2F0719FC $ ./shapubkeyofcert good-certs/debian.org.pem 5f33491e2b2d267f7bff096ad0dcb4ae5a22c0be19db0ab6728bed942f0719fc 5f33491e2b2d267f7bff096ad0dcb4ae5a22c0be19db0ab6728bed942f0719fc sha256 matches: good $ ./prncert good-certs/debian.org.pem issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3 subject=CN = debian.org notBefore=Dec 24 01:02:09 2019 GMT notAfter=Mar 23 01:02:09 2020 GMT $ ./shafullcert good-certs/web4.dotplex.de.pem 22572e20232225110713eddd7a2df14405eeec1a011aacea6a1b879fe2c8a7f8
dldcert opens an SSL connection and stores the server certificate. The next thing to do is to get the TLSA DNS record. It contains a hash of the certificate. See for the three initial numbers in the TLSA record which are printed before the hash: 3 1 1. The second number means that the hash is a hash of the public key. A zero would mean that the hash is a hash of the full .pem file. The one in the third number says that the hash is of type sha256. You can paste a certificate at ssl-tools.net/tlsa-generator and select the respective options to generate a TLSA resource record. If you have a secure way to obtain the server certificate you can create a TLSA resource record for your domain. Hosters like dotplex or inwx support that. Do not use the results retrieved via the ssl-tools.net web page because it can be spoofed. Better use the scripts we presented here. Besides enabling DNSSEC to sign the TLSA record this is all you need to do in order to enable DANE for your own domain.
Now let us get back to using these results for client configuration. At first check whether the downloaded .pem file matches the hash in the TLSA resource record. You can do this with shapubkeyofcert (second number is a one) or shafullcert (second number is a zero). We have configured our scripts to generate sha256 hashes which are currently used by all DANE configured domains we know. The shafullcert utility can also be used to generate a certificate hash as Filezilla or Firefox will ask you for in the dialogue to acknowledge a previously unknown server certificate. We have not reviewed the internals of the drill and dig tools. However dig sometimes gives up verifying the DNSSEC signature of the resource record where drill simply returns the record. drill is generally faster but we do not know if it was less secure. However there is a third option to retrieve and verify a server certificate in one step: Our atea tool. Use atea tii-cert debian.org to do so. Here is the web page of the atea tool. atea correctly verifies signatures via libunbound.
It is crucial that the Filezilla ftps program allows you to check the server certificate hash manually. However if the connection breaks down during an upload there will be a file of size zero or a half uploaded file on the server. This can be a problem if the connection yields to be currently slow or unreliable. It would be better to upload under another name and then rename once the upload has finished. To overcome this security issue I plan to extend atea with ftps support. For the moment you will have to suffice with Filezilla.
The most important advantage you can take from using DANE is by preconfiguring Firefox with some .pem-s which you have verified via DANE before. That way I have set up a secure emailing terminal for email@example.com. As it turned out dozens of people who said that they did not receive my emails before, not even in the spam folder, suddenly received and responded upon my emails. I will never know how many emails written to firstname.lastname@example.org before the secure emailing had been set up were lost forever. Obviously intelligence had been censoring my emails! Security related emails are under special scrutiny from intelligence but enviromentalists are also monitored and possibly censored. There were only two people to whom emails did not arrive after setting up the secure emailing, likely because they themselves have a censored account. One of them responded me once, so sending an email multiple times may also help.
The trick about setting up a secure emailing terminal is that first of all your email provider needs to support DANE and supply a secure webmailing (dotplex does). I have disabled images and html messages in my webmailing to stay secure. Secondly you need to drop all certification authorities in Firefox. Many CAs issue rogue certificates for intelligence and that is all the cause why we would so direly need a good DANE support. I am still using Debian 8 for my secure mailing terminal since there you can easily delete or rename the file /usr/lib/x86_64-linux-gnu/nss/libnssckbi.so to get rid of all default certificates. Unfortunately you can not delete all CAs in the GUI dialogue. First of all you need to mark every CA one by one and then after deleting them they re-appear a second later. How taunting! Obviously Firefox developers are paid by intelligence to keep the their browser insecure. The following bug report shows this in greater detail. Unfortunately the situation seems to be hardly better with curl and wget: You can not supply an individual server certificate on the command line; you have to supply a certification authority that may also issue rogue certificates to secret services. However when it comes to solely download files via https you can use the atea tool, the site owner Elmar Stellnberger has programmed for this purpose.
Getting a secure download of Debian 8 may be difficult these days. SHA512SUM verification via tails/tor may not work well since only a very few people will download such an old version. Debian 9 is somewhat newer and it may also work. Basically the atea tool could overcome this issue by direct usage of DANE. It can detect if cdimage.debian.org is spoofed. However there may be no good way out if it is. You could try to use openvpn with vpngate-extract from /software or tor. Previous versions of Debian can be downloaded from http://cdimage.
Once you have a secure boot stick which you will always need to carry with you to prevent unauthored physical access and once you have deleted all CAs you can acknowledge the server certificates you want by comparing the sha256 of the server cert against that one of your local .pem file. Things can even go easier: use insertcert.py to make the certificates in a user supplied directory be acknowledged automatically by Firefox. There are two problems with a current Debian 10 Buster. First of all acknowledging individual server certificates has been disabled for HSTS certificates like the one from mail.dotplex.com. Second you can no more manually acknowledge server certificates once libnssckbi.so has been deleted.
$ ./collect-dane-certs --collect --use-tor using tor renaming elstel.org.pem to elstel.org.pem.old bad: elstel.org.pem verified good: web4.dotplex.de.pem verified good: mail.dotplex.com.pem bad: ssl-tools.net.pem bad: debian.org.pem bad: cdimage.debian.org.pem verified good: packages.debian.org.pem $ ./collect-dane-certs --collect --no-dld using certs in current dir: not downloading anything existing-good: web4.dotplex.de.pem existing-good: mail.dotplex.com.pem checking debian.org.pem verified good: debian.org.pem existing-good: packages.debian.org.pem $ ./insertcert.py -r good-certs/ warning: cert_override.txt does not exist in profiles directory yet. good-certs/mail.dotplex.com-chain.pem: mail.dotplex.com  good-certs/web4.dotplex.de.pem: web4.dotplex.com  good-certs/secure.dotplex.de.pem: secure.dotplex.de  good-certs/packages.debian.org.pem: packages.debian.org  good-certs/mail.dotplex.com.pem: mail.dotplex.com  good-certs/elstel.org.pem: elstel.org  good-certs/debian.org.pem: debian.org 
collect-dane-certs is a bash script that invokes dldcert and drill_TLSA to sort the certificates into the directories good-certs, bad-certs and non-dane-certs.
|dane-v1.1.tar - +SNI (Server Name Indication)|
|dane-v1.0.tar - a script collection|
|libnss3-install.tar - when compiling libnss3 yourself|
|Elmar Stellnberger|| estellnb@|
If you want to experiment with newer Firefox versions and approach a fix on your own I will give you some information in the following:
certutil -A -n elstel.org -t "P,," -d ~/.mozilla/firefox/7ou998j1.default/ -a -i elstel.org.pem certutil -L -d ~/.mozilla/firefox/7ou998j1.default/
The command from above should configure a server certificate for Firefox. Unfortunately this has not been implemented so that you need insertcert.py. The library which is used for certificate management is libnss3. You can compile this library and strip the content of the file lib/ckfw/
git clone https://github.com/nss-dev/nss.git hg clone https://hg.mozilla.org/projects/nspr cd nss git tag git checkout your-revision sed -i 's#-Werror##g' coreconf/Werror.mk coreconf/werror.py cd ../nspr hg heads hg update -r your-revision
The libraries and programs required for compilation are mercurial, git, libc6-dev[-i386], libc6-i386, gyp, zlib1g, ninja-build (names for Debian). If you use the deblive skeleton you will have a secure environment for compilation as long as you do not open a web browser. Use the files from libnss3-install.tar to install the compilation results. If you have selected a compatible version for Firefox you do not need to recompile Firefox.
DANE test sites