Italian Government mail servers STARTTLS support

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.

STARTTLS User to MX mail 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).

STARTTLS support on MX hosts

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/):

STARTTLS Comparison

Among the 31 hosts which support STARTTLS, this is the distribution of certificates’ key size, verification results and SSL/TLS protocol support:

Certificates status

Protocols 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

The following two tabs change content below.
Italian, born in 1980, I started working in the IT/telecommunications industry in the late '90s; I'm now a system and network engineer with a deep knowledge of the global Internet and its core architectures, and a strong focus on network automation.

Latest posts by Pier Carlo Chiodi (see all)

Leave a Reply