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

[Rich Kulawiec]

On Sun, Nov 01, 2015 at 06:42:23PM +0100, carlo von lynX wrote:
> Let's frame the threat models. Bulk collection probably does 
> not include using OS backdoors so the suggestion to use mutt
> on BSD isn't wrong, but not necessary to move a step forward.

And why not?  If the endpoints aren't reasonably secure, then what happens
in the middle doesn't matter.  We *could* completely re-architect SMTP
from scratch, design and build in as much security as we possibly can,
but if someone foolishly insists on using Windows or a smartphone to
send/receive mail, it won't matter a bit.  (I trust everyone is aware
that Windows 10 is spyware pretending to be an OS.  It doesn't *have*
to be backdoored en masse, it ships that way from the factory.  And
"smartphone security" is essentially an oxymoron.)

So at this moment -- without a completed, peer-reviewed, implemented
replacement for SMTP globally deployed -- the single biggest things that
end users can do are (a) use a hardened OS (b) use a hardened email client
(c) do not use webmail (d) do not use freemail providers.  These are easy
steps well within everyone's reach.  They don't solve all the problems
(and they don't try to) but they tackle the obvious/easy ones.  They raise
the bar for attackers and they only require using things *that already exist*.

> Do the new "Received" headers really reflect such info
> and how would you explain what certain headers mean to
> the end user?.. given the "Received" headers are accurate,
> as questioned in previous mail.

I'm not questioning them, I'm pointing out that the hard cold
reality is that you CANNOT trust any that weren't put in place
by your own MTA.  Period, full stop, end of discussion.

Here's an example from this morning, reformatted for readability.
This was an obvious phish sent as part of a spam run:

	Received: from
	cloud.3ms.ca (cloud.3ms.ca [69.167.135.45])

	Received: from
	cpc3-nmal18-2-0-cust792.croy.cable.virginm.net ([94.174.7.25] helo=HMRC.gov.uk)

The first one was added by my local MTA (that is: running on my system),
therefore it can be trusted.  The second may be accurate: it may be that
this message really did originate from on a possibly-zombie'd end-user
system connected via cablemodem that decided to HELO to cloud.3ms.cas as
hmrc.gov.uk.  Or it may be that this message was never anywhere near the
virginm.net network operation, that it originated on cloud.3ms.ca itself.
There is absolutely no way to know which *unless* you have access to
the logs on cloud.3ms.ca.  (And if it's compromised, well, then those
logs are worthless anyway.)

So before we even get to the question of whether or not that putative
prior hop was via TLS, we have to answer the question of whether or
not that hop *even existed*.  And we can't, because we are not in
possession of the information necessary to do so.

Anyone who actually works with mail servers sees this sort of
thing all day, every day.  This is common knowledge among everyone
with more than novice-level skills.  Sometimes the Received headers
are reasonably sensible; sometimes they're obviously fiction.  It takes
a combination of experience and research to determine which are
plausible -- and that's as far as it goes.  We can never make
definitive pronouncements *unless* we have access to the relevant
logs present on the system(s) that handled the hop(s) in question.

So while it's possible to write code that does what the "Paranoia"
addon does, the results are just about entirely worthless.  (Doubly
so given that most end users do not run their own MTA: thus they
can trust *no* Received lines.)  The sad reality is Paranoia is
worse than nothing, because it relies on information that can be
and quite often is wrong or fabricated.

> It's less work to design a new mail system from scratch
> than to reduce the insecurities of SMTP from 31 to 30.

If you want to write a draft for SMTPv2 (or whatever it's going to
be called) and submit it to the IETF, I commend your efforts.

---rsk