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 area in the late '90s; I'm now a system and network administrator with a deep knowledge of the global Internet and its core architectures.

One Comment

  1. Another very strong and powerful post I’ve read some of your previous posts and finally decided to drop a comment on this one. I signed up for your newsletter, so keep up the informative posts!

    Office 365 Migrations

Leave a Reply