More DANE / DNSSEC / TLS Testing From Go6lab – Internet Society

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 🙂
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:
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:
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:
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:
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…
Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.
We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,…
Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map…
It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a…

source

About The Author

admin

See author's posts