[liberationtech] The missing awareness: SMTP Security Indicator in Email|WebMail clients

[Rich Kulawiec]

> An email users, using a desktop, mobile or webmail client, doesn't have
> any way to know if his email messages, already received or going to be
> sent, will be encrypted in-transit with SMTP STARTTLS.

If you're serious about email security, do not use a webmail
client or a webmail service.   Do not use a mobile client.  Do not
use Windows, MacOS, or Android.  Do not use a GUI client.  Because if
you make these very poor choices, then you will not be rescued from
their adverse consequences by TLS.  I recommend using mutt on OpenBSD;
this provides a combination of a highly attack-resistant, fast,
full-featured client (that's really quite superior to GUI clients)
with one of the better-hardened operating systems.

Anyone who will not make the *minimal* effort required to equip themselves
with a reasonably secure mail client/OS combination is going to completely
undercut any external security that's in place anyway, thus there is
no point in even attempting to help them.

> We are missing the ability for end-user to:
> - KNOW if emails being received from Mr. X has been in-transit encrypted.
> - KNOW if emails he's going to send to Mr. X are likely going to be
> in-transit encrypted

While a mail client can discern whether mail submission is done
over an encrypted connection, it can't tell whether mail transmission
is or isn't.   Once a mail client hands off mail to a server for queueing
and delivery, the connection is terminated and the client has no visibility
into the ensuing outbound connection made by that server.  Similarly,
a client on the receiving side which is accesssing mail (say, via IMAPS)
can certainly ensure that the connection it's currently using is encrypted,
but it can have no visibility into whether or not the connection used to
deliver mail to that mailbox was encrypted.

Yes, in the second case, a client *could* perform header analysis,
and if the MTA software in play is such that it notes the use of encryption
in the "Received" headers, it could parse those and report their state.
However, (a) this is after-the-fact: that is, the message has to be
received in order to do this (b) the message may have passed through
multiple MTAs (c) any of which could have sent it over an unencrypted
connection and (d) any of which could simply fabricate the headers should
they be configured to do so.  (d) is quite familiar to all experienced
email practitioners, as spammers have been using it for many years in
order to create partially or entirely fake headers in attempts to
confound analysis.  But it also turns up in misconfigured or broken
mail systems, which are very common.

And (e) if any of the MTAs used in transit has been compromised or if
the host they're running on has been compromised or if they're in the cloud,
then all bets are off.  This is also quite common, unfortunately.

Moreover, past history is not indicative of future performance: even
if we draw the entirely unjustified conclusion that a message *was*
encrypted during each transmission hop (based on what we see in the
headers at the receiving MUA) there is no guarantee that a second message
sent a minute later will also be, or that a reply will be.  Encryption
negotation might fail.  A certificate might expire.  A different
receiving MX or sending system might be used.  A configuration error
may occur.  And so on.

In other words, what you're asking for is impossible in a MUA, because
it can neither observe (with high confidence) nor influence what goes
in between MTAs.

Encrypting message content, of course, provides some insulation against
this.  But it still facilitates traffic analysis and I presume that
everyone here is painfully well aware that metadata is often as revealing,
sometimes more so, than data.  (This is one of many reasons to assiduously
avoid freemail/webmail/cloud-based services, as there can be little
remaining doubt that they divide into two categories: those which have
already been quite thoroughly compromised, and those which are going to be.)

In case it's not clear, I'm not arguing against increased email security.
But until people stop making the obvious and major mistakes I outlined
in the first paragraph, there is little point in applying any effort to
it...since efforts like trying to assure encrypted transport throughout
merely wallpaper over the underlying problems and don't address them.

---rsk