[liberationtech] The status of SMTP security in email communication infrastructures

[Moritz Bartl]

>   - which of them offer SMTP/TLS when sending email?
>   - which of them accept SMTP/TLS when receiving email?

One of the problems with the current configuration of mail servers
(STARTTLS) is that any active attacker can modify the STARTTLS command
and turn the session into plaintext without anyone noticing.

We should also analyze what ciphers are used for TLS sessions. For
example, Fabios mail, sent via Google, did not use a perfect forward
secret cipher:

Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com
[74.125.83.52])
	(using TLSv1 with cipher RC4-SHA (128/128 bits))
	(No client certificate requested)
	by mailman.stanford.edu (Postfix) with ESMTPS id C360820074D

Whereas the connection from the stanford list mailserver to my
mailserver used a modern TLS connection and a perfect forward secret cipher:

Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by mail.headstrong.de (Postfix) with ESMTPS id 5107C1C0013B

Does anyone have contacts at Gmail, Fastmail, or any other large mail
provider that would be interested in conducting a study? At least
Postfix logs TLS information to mail.log by default, and can be
configured to add the above TLS information to mail headers.

To advance mail server security, I think the following would be
beneficial: Configure your mail server to accept old ciphers and non-TLS
sessions (from a cursory analysis of my inbox, this is sadly necessary;
not even Facebook or Twitter use TLS), but, at least for non-TLS
sessions, email both the sender and postmaster at senderdomain and inform
them about their deprecated setup (and point them to relevant guides).
Maybe even for non-PFS ciphers.

Technically, my idea was to set recipient_bcc_maps in Postfix and
deliver a copy of every incoming mail to a local script. The script then
parses Received-headers for TLS information, keeps a hashed database of
sender domains and senders around to not spam senders too much, and
sends out notifications.

Anyone interested in contributing such a script?

Also, we could use someone to simply parse mail.log and generate some
statistics from that. We're not aware of any such statistics.

--Mo