After we successfully implemented DANE for email server in Go6lab – we thought of doing a small experiment. Who else on the Internet is using DANE for email servers and is verifying the TLS certificate hash using the TLSA DNS record?
Let’s find out.
As we don’t have all existing domain names in a handy database, we thought of using Alexa 1 million top domains list for this test. So we wrote a script that fetches the top 1 million in Alexa list in text file and creates a “target” email addresses database, consisting of “test-dane@[domain]”, but written in a way that we can just execute it and mail will be sent through “mail” linux command.
Next thing that we needed was a postfix server with DANE capable smtp sender and local name daemon resolver, capable of verifying DNSSEC. After putting all that together, we were ready to test. Executing the batches of “send email to 100.000 email addresses with mail command” and clearing up the mail queue in between took us some time, but we got some results at the end.
To make the whole thing faster we set smtp sender of postfix in “dane-only” mode, so it started the smtp session just if there was a verified TLSA record in the DNS system. Running DNS resolver on localhost also speeded the whole process up a bit.
So, you are wondering what the results are?
After doing grep “Verified TLS” /var/log/maillog | awk ‘{print $11}’ | cut -d”[” -f1 | sort | uniq – we got a list of mail servers that actually has the TLSA DNS record and their published TLS hash matches the TLS certificate offered by actual mail server. The list of results counts 105 entries, and here it is 🙂
box.occams.info box.sibillo.com das-labor.org elenski.switch.ch eugeni.torproject.org fnatte.skatteverket.se freenetproject.org freeshell.de gatekeeper.spacenet.de goedel.dlitz.net jail.internet.nl kamx.sidn.nl knatte.skatteverket.se liselle.bunkus.org mail01.allsecur.de mail01.ipfire.org mail02.allsecur.de mail3.iki.fi mail9.knipp.de mail.abuse.ch mail.bayern.de mail.cgi.br mail.cmsrv.org mail.fobos.de mailgate2.intershop.de mailgate2.uni-kl.de mailgate.intershop.de mail.greensec.de mail.ietf.org mailin2.mx.speedkom.net mail.laukas.lt mail.netbsd.org mail.nethuis.nl mail.nic.br mail.nic.cz mail.remote.sx mail.samba.org mail.state-of-mind.de mta.openssl.org muffat.debian.org mx01.nausch.org mx01.xworks.net mx02.mail.de mx02.posteo.de mx0.lepartidegauche.fr mx-10.mil.se mx1.bund.de mx1.core-networks.de mx1.denic.de mx1.freebsd.org mx1.mailbox.org mx2.bund.de mx2.jpberlin.de mx2.lepartidegauche.fr mx2.nabber.org mx2.o11.net mx2.uni-kl.de mx3.xs4all.nl mx4.unitybox.de mx.dotplex.de mxg.eu.mpssec.net mx.xelerance.com open.nlnetlabs.nl postrelay1.lrz.de postrelay2.lrz.de prime.gushi.org redisdead.crans.org relayn.net4sec.com smtp-1.httrack.com smtp4.rz.tu-harburg.de SMTP.EU.ORG smtpgate1.restena.lu smtpgate2.restena.lu smtp-good-in-1.t-2.net smtp.terryburton.co.uk smtp.trashmail.com uhura.unitymedia.de vocal.dk-hostmaster.dk vspampx2.mvnet.de w1.tutanota.de
Another interesting point is, that 28 of them comes from Germany (.de) 🙂
This quick test inspired us to do another experiment that would reveal also other parameters in email world – this time we got interested in:
- how many domains out of Alexa top 1 million had the MX record?
- how many times we’ll be able to establish the TLS encryption when trying to deliver email to artificial addresses on all those domains?
- how many of those TLS connections would be Anonymous (opportunistic TLS), Untrusted (peer certificate not signed by trusted CA), Trusted (peer certificate signed by trusted CA) and Verified (verified with TLSA by DANE)?
We were also curious about what is the distribution of domains per mail server (some mail servers handles thousands of domains) and what does all of the above mean for securing the email delivery transport.
We modified the test script and alse reconfigured the mail server from “dane-only” to “dane”, so it would actually try sending emails even if domain MX record does not have a TLSA record to verify it and level of required encryption was “may”.
After about 30 hours of experiment running time (mail server needed to establish nearly 1 million SMTP connections in a sequence) we got the data in maillog file. After some magic with sed/awk/cut/grep we got some results.
Out of 1 million domains,992.232 of them has MX record and mail server.
We were able to establish a TLS connection (of any kind) in 687.897 sessions (nearly 70%). The rest of them were unencrypted.
TLS established connections ratios are:
- Anonymous: 109.753
- Untrusted: 167.063
- Trusted: 410.953
- Verified: 128
Quite impressive number of Trusted connections and well done to all that enabled DANE.
1.382 of connections where remote mail server announced TLS capability failed with “Cannot start TLS: handshake failure”
Interestingly enough, just around 1% of the sessions were established over IPv6, despite the fact that quite some of remote mail servers had IPv4 and IPv6 enabled.
In our curiosity we went further and tried to figure out the distribution of domains across mail servers and after looking at the log files we spotted few ones, that showed up quite oftenly and here are the results of some log parsing:
- Google.com mail servers handles 125.422 domains and all of them were detected with Trusted TLS state.
- Secureserver.net mail servers handles 35.759 domains, some of them with Trusted TLS, some of them with no TLS at all
- qq.com mail servers handles 11.254 domains and has no TLS at all
- yandex.ru mail servers handles 9.268 domains and has Trusted TLS
- ovh.net mail servers handles 8.531 domains with majority of them establishing Trusted TLS, just their redirect server having no TLS at all (redirect.ovh.net)
- emailsrvr.com mail servers handles 8.262 domains and has Trusted TLS
- zohomail.com mail servers handles 2.981 domains and has Trusted TLS
- lolipop.jp mail servers handles 1.685 domains and has no TLS at all
- kundenserver.de mail servers handles 2.834 domains and has Trusted TLS
- gandi.net mail servers handles 2.200 domains and has Anonymous TLS
- registrar-servers.com mail servers handles 2.808 domains and has Trusted TLS
- dreamhost.com mail servers handles 3.440 domains and has mostly Anonymous TLS, but 2 of servers has no TLS at all.
For enabling DANE the prerequisite is that their domain is DNSSEC signed and also MX record resides in domain, that is DNSSEC signed. We checked for all above mail servers domains and none of them are DNSSEC signed, so even though if domains that are pointing their MX records would be signed and have a TLSA record for DANE – it would not work as the actual MX records are not secured with DNSSEC.
Somebody would say “well, they mostly have Trusted TLS, that means that their certificate was signed by trusted authority (CA)…”. That is true, but we need to understand that certificate fo every domain can be signed by any CA, so there can possibly be different signed certificates from different trusted CA agencies for (for example) secureserver.net. In this case we are just verifying the validity of the signature in the certificate that is presented to us and we have to trust that the host presenting this certificate is the right one. With DANE verification the whole thing becomes even more secure, as a hacker would have to infiltrate a server with false signed certificate in the middle and also hack the domain name server, forge the TLSA record and sign it with correct DNSSEC key – and that rises the bar for this sort of behaviour very high.
During this experiment we contacted 473.088 different mail servers that are handling mail for all those domains. 372.936 (79%) of contacted mail servers has TLS capability and the distribution of TLS verification type is as follows:
- Anonymous TLS: 68.048
- Untrusted TLS: 151.242
- Trusted TLS: 153.330
- Verified TLS: 105
- Bad TLS (TLS connection started but failed due to bad TLS certificate): 211
Conclusions: Nearly 70% of all attempted SMTP sessions to Alexa top 1 million domains MX records were encrypted with TLS, making the inspection of the content of the session by 3rd party in the middle much harder to do – and that’s quite an impressive result. Majority of TLS connections (60%) were established with trusted certificate and that is also a very good result.
What about DANE and DNSSEC? Kudos to all mail operators from the above DANE enabled and secured mail servers – and the message to all others: DNSSEC can be done and it’s not lethal and when you sign your zone with DNSSEC and publish the DS keys – DANE becomes very easy to do – so please go ahead and do it. You’ll collectively make the Internet a bit better and more secure place.
P.S. Want to set up DNSSEC and DANE for your email servers? Please visit our Start Here page to begin…