After reading Antonio Prado’s Reverse DNS lookup for Italian Government’s mail exchangers post I got intrigued by the idea of checking how many of those Italian Government’s MX mail servers support STARTTLS.
STARTTLS “offers a way to upgrade a plain text connection to an encrypted (TLS or SSL) connection” (Wikipedia) and, when it’s implemented on the MX SMTP server, it allows a STARTTLS-aware user’s outbound mail server to encrypt the traffic toward the recipient’s server.
For this test I used a small bash script that I fed with the same dataset that I already used for my IPv6 adoption in Italy post (whose updated – and almost unchanged – results can be found here).
For each domain I selected all the MX records, then I tested them using OpenSSL (OpenSSL 1.0.1f) s_client command (on Ubuntu 14.04.2 LTS with ca-certificates package version 20141019ubuntu0.14.04.1).
On a total of 73 domain names, 106 unique MX records have been found; 31 of them support STARTTLS, covering 24 unique domains (11 MXes reported a connection error while 64 declared to not support STARTTLS).
This is a comparison with similar data from some EU neighbors (national lavel domains taken from https://devpub.labs.nic.cz/ipv6-smt-new/country/):
Among the 31 hosts which support STARTTLS, this is the distribution of certificates’ key size, verification results and SSL/TLS protocol support:
I didn’t go further into the analysis of ciphers or certificates issues because, in the current state, server-to-server (MTA-to-MTA) STARTTLS support is mostly used in opportunistic mode (that is, connections automatically fallback to unencrypted mode if remote party doesn’t offer it) and, primarily, it is advertised with in-band commands during the initial plain text SMTP setup: to perform a man-in-the-middle attack an attacker can simply strip the STARTTLS support from the initial dialog, instead of exploiting SSL/TLS weaknesses.
Some out-of-band solutions exist and they allow to securely determine whether the remote party is ready and willing to accept encrypted communications (DANE/DNSSEC for SMTP, STARTTLS Everywhere), but until they will be not widely deployed STARTTLS will just remain an opportunistic way to protect confidentiality and integrity of transmitted e-mails.
IMHO, even in an opportunistic-only scenario, a little effort might be spent to improve security of confidential communications such as those toward institutional bodies!
Further reading
– Facebook, The Current State of SMTP STARTTLS Deployment (May 13, 2014): https://www.facebook.com/notes/protect-the-graph/the-current-state-of-smtp-starttls-deployment/1453015901605223
– Facebook, Massive Growth in SMTP STARTTLS Deployment (August 19, 2014): https://www.facebook.com/notes/protect-the-graph/massive-growth-in-smtp-starttls-deployment/1491049534468526
– Google, Email encryption in transit: https://www.google.com/transparencyreport/saferemail/
– IETF, RFC3207, SMTP Service Extension for Secure SMTP over Transport Layer Security: http://tools.ietf.org/html/rfc3207
Latest posts by Pier Carlo Chiodi (see all)
- Good MANRS for IXPs route servers made easier - 11 December 2020
- Route server feature-rich and automatic configuration - 13 February 2017
- Large BGP Communities playground - 15 September 2016
Leave a Reply