Efail: can email be saved?

[anon28219805]

I was trying to use short-hand terms for categories that are already admittedly not clearly-defined.

I have no idea what this means.

The “personal email protocol” would be standard MIME stuff overlaid with the personal password information and any encryption.

Or this, and what does it do if it finds a “man-in-the-middle attack” that does “match your provider’s online encryption protocols”?
And if this extra scanning is possible why is it not done on all incoming mail?

Then the provider has a problem, because that could mean a user is doing the attacking. We would hope that the email provider is regularly vigilant. Presumably, there would be a heuristic that reduced the scanning load for pre-approved emails.

What? I know of a few generic sandboxing technologies, but non I would consider user friendly enough for general users.

Which is why the sandboxing would be handled by your AV and malware programs based upon the infiltration threat-level. Do you individually set the heuristic for your AV program, outside of PUP lists or other blacklists? No, the signatures come with the database update.

I ask some basic questions, and you act like your mind is blown by my ignorance, when I already told you that I was providing a descriptive list open to modification.

Look, is what I am describing too technical or too broad?

All I’m trying to outline is a way for email accounts to screen for approved versus non-approved emails, based upon a temporary approval to receive emails from people who you give your email account to. This would potentially allow breaches to be traced.

[moortaktheundea]

The company was Lavabit.

[anon72705028]

That is it. All I could think of is hushmail.

[Medievalist]

I’m having difficulty parsing your proposal. It sounds like a form of greylisting, though, with the usual problems of complexity and delay known to those techniques.

@anon28219805

1. Each website or person to whom you initially provide your email address also needs to use a temporary password.

Who creates this password, and how does it become known to people who need to use it?

@anon28219805

The website or person sends a confirmation email to you that includes your personal email protocol and the temporary password.

?? What does personal email protocol mean - can you give examples?

@anon28219805

The password flags your email provider to scan your email with extra security screening (looking for man-in-the-middle attacks that don’t match your provider’s online encryption protocols).

How does your email provider (which in my case, is me) know this flag is present?

Can you give an example of a “man-in-the-middle attack that doesn’t match an online encryption protocol?”

@anon28219805

When the email arrives in your account, it attempts to establish variable sandboxing tied to your offline AV and malware programs, which scan the email prior to approving it.

All email is already scanned in a modern infrastructure, so that’s clearly doable, but what is variable sandboxing and what do you mean by offline AV and malware programs?

@anon28219805

7. Accepted messages could also use encryption keys that are exchanged between email accounts themselves (not users), but are processed using one-time encryption “software pads” (refer to OTAC or PGP).

Email is moved like this: my mua → mta → mda → your mua.

MUA means mail user agent (that’s something like Outlook or Thunderbird) and MTA means mail transfer agent (that’s a mail “hub” that normal users never see, that acts like a central post office sorting and routing mail) and MDA means mail delivery agent (that’s like a postman who delivers mail to your house - it takes the bits that make up the mail message and puts them in a file or folder “mailbox” where the recipient’s MUA will be looking to find them).

Sometimes the boundaries are blurred - sendmail can do all three jobs, but typically is only used as an MTA, and Microsoft Exchange is both MTA and MDA, and gmail hides all this complexity behind a web interface. However, these are functional requirements of globally scalable network mail - there have to be user interfaces, routing hubs, and delivery agents.

As you can see, there is no direct communication between the mail program that sends the message and the mail program that reads the message. In theory there can be hundreds of MTAs in there, but nowadays, most of the time there are only two or three at most.

TLS can protect each leg of the journey, but if you are passing 1-time-pads around over a multi-hop network, they will unfortunately be readable at each hop and thus not very secure for the same reason email isn’t.

[dreamrnj]

While I agree with most of this, there is more wrong than the 800 pound gorillas.

When the protocol was first developed, the Internet was mostly colleges and research institutions. Each server receiving email expected the sender to be a rational actor. When it was opened to commercial traffic, that assumption was no longer valid. We were able to check for the more obvious things like open relays, but there are just too many ways to take advantage of a system based on trust. You can trivially spoof every header, for example. I’ve lost track of the number of “Received:” headers I’ve looked at where the chain of servers the email supposedly passed through made absolutely no sense.

We need a protocol with distrust at it’s core. I don’t see that happening, though. The embedded base is too big.

[Medievalist]

@dreamrnj

When the protocol was first developed, the Internet was mostly colleges and research institutions. Each server receiving email expected the sender to be a rational actor.

That’s not how I remember it. In the original article, you remember the mention of emails from God and from Santa Claus? I can categorically state I was not in any way responsible for the Santa Claus ones.

@dreamrnj

You can trivially spoof every header, for example.

Not if the current relevant standards are being used. If you’ve got DKIM, SPF, and eSMTP STARTTLS all properly configured, you can’t spoof the envelope, and if the message headers don’t match the envelope, you can throw the mail away.

Essentially, all the problems are solved, and the solutions are available for free - but people aren’t implementing the solutions.

[cheem]

@HMSGoose

Except that this is an open standard as well (iCal). Isn’t that the way to security? Agree on a standard, and then that’s the only content that can be included. I don’t mean to make it sound simple, but it’s not like calendar invites are some mysterious commercial interloper into the email standard.

Actually, there are two types of calendar invites: iCal and Exchange. Exchange predates iCal, but is Microsoft proprietary. There have been moves to make the two types of invites compatible or at least transparent to each other, but you still have old codgers using Outlook 2003 or something sending calendar invites and screwing stuff up.

[Medievalist]

Microsoft Outlook is the objectively worst thing that ever happened to email.

It actively trains users to Do the Wrong Thing™ which feeds into a textbook illustration of software stockholm syndrome.

PS: Old codgers use elm!

[CapnCrunch]

@Medievalist

It actively trains users to Do the Wrong Thing

Can you elaborate?

[Medievalist]

Well I don’t want to get off on even more of a rant, so how about one example.

The delimiter between two email addresses is a comma. And since that’s a standard, after all, (RFC5322 I think) that’s what you train your fingers and brain to do.

Except in Outlook, which uses semicolons; the program literally translates them to commas on both outgoing and incoming mail. So you train wrong.

There’s a setting that changes it to comma, in recent versions of Outlook. If you’re on a large corporate network and have a deathwish, you can use a GPO or login script to change it enterprise-wide. Then see if you can make it to the parking lot alive!

[Anselm]

@Medievalist

Essentially, all the problems are solved, and the solutions are available for free - but people aren’t implementing the solutions.

This is in part because some of the “solutions” break things that have been working since time immemorial (like mailing lists). Also, some of the “solutions” are misused by 800-pound gorillas like AOL or Yahoo! to address issues they were never meant to address. STARTTLS is pretty uncontroversial, mostly because between servers it is largely optional, but DKIM and in particular DMARC are definitely two-edged swords.

[HMSGoose]

I recently encountered DKIM and SPF when Zendesk asked us to make records allowing Zendesk servers to send mail from our domains. I took that to be a sign of progress if they’re using them tp tale care about mail reaching its destination with a trusted envelope…

[FGD135]

… but the Lego dumpster fire pic was worth the clickthrough.

[fuzzyfungus]

The survival or death of email seems largely orthogonal to the email issue(though it was a pretty nasty one; conceptually simple, went through multiple common configurations like a hot neutrino with a switchblade through butter; and embodied the worried-about-but-generally-invisible “storing your ciphertext in case a vulnerability becomes available is really quite cheap” problem.):

Efail has much more in common with the Signal and Telegram exploits that dropped around the same time despite using email rather than the completely different transports of the other two: not a cryptographic problem specifically but a “if you want secrecy correctness is even more important than usual and if you want pretty formatting and meme gifs and stuff that complexity is going to be an enemy of corrctness” problem…

For such purposes it seems to me that it would be nice to have a carefully defanged proper subset of HTML for “needs more than plaintext formatting; Must Not chat with the outside or screw this up” cases. That might be wishful thinking in our grim era of “rich content” this and “engaging consumer experiences” that; but it is a case that would have a number of uses(and if a proper subset of HTML could borrow the effort that goes into renderers for it; which get a lot of love, on basically all the platforms, compared to most alternatives. You’d want at least enough formatting to do RTF-like stuff; but with things like “loading anything from outside the context of the message is impossible”; no JavaScript, etc.

As for email, it has its unfortunate aspects; but it’s also on the last survivors of reasonably standards based federated communication options. That is not something to be sacrificed to some walled garden lightly, be it ever so neatly manicured.

[Medievalist]

@Anselm

This is in part because some of the “solutions” break things that have been working since time immemorial (like mailing lists).

True. And although solutions are available for that breakage, there are people who insist that since they have done something in the past under one version of the rules, it is their God-given right to never do any work to conform to the new rules. (This is not a problem restricted to the Internet - how dare society demand pollution controls on cars, how dare we demand that people who look or act different be treated equally, how dare we make any progress that makes me expend mental or physical effort on change!)

@Anselm

Also, some of the “solutions” are misused by 800-pound gorillas like AOL or Yahoo! to address issues they were never meant to address.

Hmmm… I’m not aware of any specific instances of that, but I find it quite easy to believe! My experiences dealing with these organizations (also, Comcast and Verizon) is that they see the Internet as something to be exploited at minimum cost to themselves, and they see standards compliance and customer service primarily as obstacles to profit.

[orenwolf]

@Boundegar

Email works fine for me and is an important tool. Maybe I am fooling myself.

You’re fooling yourself.

• How many of your friends and family have - despite your best efforts - managed to click on a spoofed email? - How much third-party spam detection has to take place just so that you can see your inbox?
• How much of what you read in your email tracks you when you open it, what you looked at, and sent it back to a third-party news provider, without you even realizing it?
• How many important documents are still only possible in-person, or… ugh… via fax because email is “insecure”?

The answer to all of these questions is troubling.

• Most of my family have managed at some point over the years to either accidentally click on an email containing a trojan that mailed out a copy of itself to their address book, or at the very least, was forwarded to “someone who could tell if this was real or not”.
• Massive amounts of heuristics and other automated and manual mechanisms are involved in keeping your mailbox spam-free. The messages you get in your “spam” folder represent perhaps 10% of the actual spam that would have arrived without these tools in place. There are few other online communication mediums where the signal-to-noise ratio is that high.
• Most mailing lists or emails from corporations contain beacons that track you. The most invasive kind send over far more events than most websites do. And worse, a bad actor just has to get you to open the email for you to send data.
• There is NO PATH today for email to be a reliable communications channel safe enough for your private data to be sent securely. S/MIME and GPG would have worked with more universal adoption, but now these tools have also been shown to be ineffective. And they were our best shot. We can barely validate that a sender is legitimate, let alone ensure that only you receive your banking or medical info at the destination.

As someone who has run email servers professionally since 1996 and personally since 1998 (and also being responsible for the firehose that is Cory’s email!), I can see the trajectory here. Email is less useful than it used to be, and that reduced usefulness is coming at the cost of increased effort on the part of those delivering it to you.

[Medievalist]

@orenwolf

The messages you get in your “spam” folder represent perhaps 10% of the actual spam that would have arrived without these tools in place

On my servers, I reject known open relays and other bad players at the TCP SYN, so I can’t get real figures - each of those connections might have sent to more than one recipient. But if I count those as one email each, we are rejecting a lot more than 90% of incoming email. More like 96% the last time I looked, although it fluctuates constantly.

@orenwolf

There is NO PATH today for email to be a reliable communications channel safe enough for your private data to be sent securely.

There is a technical path, it is known. Unfortunately people refuse to implement the necessary technology because it would mean hiring people at least as technically competent as you and I, and that would be expensive, and because it would mean shutting down all communication with known bad players (including AT&T, Verizon, Comcast, AOL, Microsoft, and so forth) until they came into technical compliance. The leadership caste is too arrogantly spineless for that.

@orenwolf

I can see the trajectory here. Email is less useful than it used to be, and that reduced usefulness is coming at the cost of increased effort on the part of those delivering it to you.

This is absolutely true. And while it could be fixed, I don’t see it happening soon, because of the aforementioned spinelessness. “I can’t email the patient her test results because she’s on Verizon” would not fly with the executive class, they haven’t got the guts to do hard things.

[csilvest]

@Medievalist

Well I don’t want to get off on even more of a rant,

For the record, I {heart} your rants.

[Medievalist]

I’ve heard there’s no accounting for taste!

[fuzzyfungus]

@orenwolf

There is NO PATH today for email to be a reliable communications channel safe enough for your private data to be sent securely. S/MIME and GPG would have worked with more universal adoption, but now these tools have also been shown to be ineffective. And they were our best shot.

When you say “have been shown to be ineffective” do you mean in the “GnuPG adoption on track to never crack the single digits before the heat death of the universe” sense; or are you referring specifically to the email issue?

I’d be the first to agree that actually encrypting email seems to be on a deeply tepid trajectory; but would say that efail, while elegant and dangerous, certainly didn’t spell the death of email encryption anyore than heartbleed the end of SSL.

As for the other problems noted, they are definitely nonfalse; but only the SNR issue seems particularly email specific (and, while the walled garden options have an easier problem in that they bless every prospective sender they still tend to have an SNR lousy enough to bother, and sometimes threaten, the noob user(and generally less mature tools for dealing with the problem). The rest (tracking bugs, phishing, legitimacy verification) sound pretty much identical to what you get on the web; in no small part because email is just being used to shovel HTML, so capabilities are similar.

The odds that a site is delivered SSLed are higher than those of seeing S/MIME in the wild; but with the ongoing “yeah, any CA can sign a cert for any domain, that’s fine” problem still not worked out; and the tendency of large, nominally respectable, entities to burst open and spill their guts all the time the experience isn’t all that much different (and the odds that email has at least enjoyed in-transit encryption, of roughly SSL calibre, have gone up markedly; though end-to-end is still unlikely).

The tendency to incorporate all the dangerous parts of the web with even less attention to security is not a good one; but it isn’t primarily a fault of email that you can deliver a malicious webpage with it and clients will merrily render the result.