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

[Rich Kulawiec]

On Mon, Nov 02, 2015 at 09:13:08PM +0100, carlo von lynX wrote:
[ a bunch of good points and one thing I'd like to expand/elaborate on ]

> Correct. Still it makes no sense for benevolent nodes to fabricate
> false warnings about insecure TLS usage. Question is if it makes
> sense for malevolent nodes to do so, maybe in order to distract
> from something else.. or if it doesn't make sense for them either.
> If it doesn't, then warnings in "Received" headers are useful even
> if they aren't securely delivered.

In the sense that those warnings indicate a "best case", and that
reality might be worse, yes, it does make sense to consider them.

But let me return to the first sentence above.  No, it doesn't make
any sense for benevolent (or let's say, neutral) nodes, to fabricate
false warnings, but those same nodes exhibit broken behavior all day,
every day...thus furnishing us with an ongoing stream of evidence
that we shouldn't trust their expressed opinions on *anything*.

The sad reality is that in the race to the bottom (in terms of
incompetence and negligence) the 500-pound gorillas of the email
world are leading.  (Which is another reason why I counsel everyone
to avoid them: security/privacy aside, they're junk.)  We see
erratic, aberrant, and abusive behavior emanating from these
operations constantly.  So presuming that their "Received" headers
are somewhere between "right" and "fiction" is actually a
pretty good working assumption.

One of the points that I've made for many years is that competently
managed operations do NOT emit abuse on a systemic and chronic basis.
Point problems?  Sure.  Temporary problems?  Sure.  But when the abuse
goes on for years and clearly pervades the operation, we are left with
only two possible conclusions:

1. They're doing it on purpose.
2. They're not doing it on purpose.

If it's (1), then they're malevolent and cannot be trusted.
If it's (2), then they're incompetent and cannot be trusted.

Either outcome has the same operational impact: we can't believe
anything their servers tell us, because it might be correct or might
be a mistake or it might be a deliberate fabrication.  Absent
evidence not available to us, we not only don't know, we can't know.

It's a pity, really, that we've arrived at this situation.  But here
we are, and there is no sign that it'll change -- why should it?

---rsk
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[carlo von lynX]

Thanks for taking on the challenge to discuss things for real.

On Mon, Nov 02, 2015 at 07:11:00AM -0500, Rich Kulawiec wrote:
> 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.)

Certainly the way Windows is systematically imitating the G-Mail success
model by running everything you do and type through advertizement models 
is terrible. Are Android or iOS already sending everything back home?
AFAIK only Microsoft is trying to take back the lead in the race to the
bottom of civility.

As long as those OS's do not systematically send keylogging data back
to their homebases, an attacker doing a targeted attack to get at the
stuff would be visible in the traffic - thus it is not as low hanging 
fruit as bulk sniffing of TLS as seen with BULLRUN.

> 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*.

That's all true, but the bulk of mail traffic is still unencrypted...
And when it isn't, it resides on mail servers that are usually not
so very hard targets. So this is the threat order I would guess:

1. SMTP + X.509
2. your OS, especially if you didn't read the T of Windows
3. the ever luring Web
4. vulnerabilities in GUI mail clients

> > 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.

So Alice sends a mail to her server. That server forwards it
to a mailing list server, adding a header about the fact that
the mailing list server was found to have an invalid certificate.
The mailing list server may forward this header or even delete
it. When Bob picks up his mail, he finds Alice wrote to the
mailing list. No reasonable way to find out, that she got MITM'd.
There may be traces of information in some untrustworthy
"Received" headers, but they could also be intentionally put
in there by the evil mailing list server to cause confusion.
At least that would be the threat model if you say "full stop.
end of discussion."

> Here's an example from this morning, reformatted for readability.

Thanks you for the nice example. I'm sorry you elaborated so much
on this, but I hope some other readers didn't know about these
problems yet and have gained knowledge this way.

> 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.

Correct. Still it makes no sense for benevolent nodes to fabricate
false warnings about insecure TLS usage. Question is if it makes
sense for malevolent nodes to do so, maybe in order to distract
from something else.. or if it doesn't make sense for them either.
If it doesn't, then warnings in "Received" headers are useful even
if they aren't securely delivered.

> The sad reality is Paranoia is
> worse than nothing, because it relies on information that can be
> and quite often is wrong or fabricated.

You're probably right. Sorry, naif.

> > 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.

Revolutions never came out of the IETF. I know. I've been
there, I've worn that t-shirt myself.

The next not so simple mail transfer protocol needs to be
so dramatically different, it doesn't even make sense to
name it similarly:

- 

Re: [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

-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[fauno]

"Fabio Pietrosanti (naif) - lists"  writes:

> - KNOW if emails being received from Mr. X has been in-transit encrypted.

there's a thunderbird addon called "paranoia" that does this

-- 
http://endefensadelsl.org
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[malte]

Quoting Fabio Pietrosanti (naif) - lists (2015-10-31 20:02:21)

> so, the in-transit email encryption problem isn't yet solved.
> 
> The uses of opportunistic encryption with SMTP STARTTLS help, but also
> this is out of the end-user control.

I think mail providers should stop accepting starttls opportunisticly,
but should start requiring it.

mailbox.org does it via the @secure.mailbox.org aliases, I do it in
general (f*ck you Dreamhost, I don't want your shabby unencrypted mail),
others might follow.

For Postfix it's really just setting

smtpd_tls_security_level = encrypt
and
smtp_tls_security_level = encrypt
(instead of "may")

in /etc/postfix/main.cf


Sincerely,

Malte
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[Rich Kulawiec]

On Sun, Nov 01, 2015 at 12:32:37PM -0300, fauno wrote:
> there's a thunderbird addon called "paranoia" that does this

Correction: there's a Thunderbird addon called "Paranoia" that pretends
to do this.  Everyone should know by now that you can't trust any
"Received" headers other than those written by your own MTA.  (They might
be accurate and truthful; they might be partially wrong; they might
be complete fabrications.)

Paranoia's own documentation says:

"Click on the emoticon and you'll see a list of connections
which were made before this message arrived in your inbox,
and state of encryption of each of them."

Which means that Paranoia makes the mistake of trusting headers that
can't be trusted.

---rsk
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.

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

[carlo von lynX]

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.

On Sun, Nov 01, 2015 at 05:39:29PM +0100, ma...@wk3.org wrote:
> I think mail providers should stop accepting starttls opportunisticly,
> but should start requiring it.

Whereas man-in-the-middling SMTP federation connections
(same problem as with XMPP and IRC networks) may be rather
cheap: How do mail servers check certificates? Do they
pin them down? Do they accept anything valid? Do they
ignore certificate validity? What if anything went wrong
during interserver-TLS. Will the end-user ever find out?
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. And then you may bump
into mail providers that use inconsistent certificates
like it happened for us who developed "Certificate Patrol"
to find out that the majority of our potential users can't
handle the frequent amount of questionable https 
connections the industry confronts them with, given such
freedoms in the broken X.509 standard TLS is built upon.

Yes, mail providers should require STARTTLS, but it leaves
a dozen insecurities up in the air which are structural
to the very bad protocol standards we have. It's less work
to design a new mail system from scratch than to reduce
the insecurities of SMTP from 31 to 30.


-- 
  E-mail is public! Talk to me in private using encryption:
 http://loupsycedyglgamf.onion/LynX/
  irc://loupsycedyglgamf.onion:67/lynX
 https://psyced.org:34443/LynX/
-- 
Liberationtech is public & archives are searchable on Google. Violations of 
list guidelines will get you moderated: 
https://mailman.stanford.edu/mailman/listinfo/liberationtech. Unsubscribe, 
change to digest, or change password by emailing moderator at 
compa...@stanford.edu.