The Fallacy of "Secure Email"

We're having a rollicking good time lately working with emails that are coming to us using some form of "secure" delivery platform, as an alternative to actually encrypting email end-to-end, which everyone knows is not fun.

Some background...companies big and small are increasingly offering some sort of secure email feature, especially if you use cloud providers like Symantec, Mimecast, Microsoft's Office365, etc.

It sounds great - you don't have to do all of that pesky server configuration, etc., and you like your provider, so it'll be awesome, right?  The thing is, they don't actually encrypt email delivered via SMTP.  Which means, things are about to suck.

Set aside for a moment the fact that "secure internet email" is an oxymoron of nearly biblical proportions - if you don't host your own email, someone else is reading all of it; if you do host your own email, someone else is still reading all of it, but you at least know who that someone else is;  if you send email over the internet, someone else has read it - whether their geopolitical beliefs, conscience, and motives fit yours or not is scarcely relevant to the question of security.  Email isn't secure.  Never has been.

So naturally, if a company starts selling a solution to an impossible problem, someone is going to give it a shot.  After all, nobody ever went broke by underestimating the intelligence of the average consumer, blah blah blah.

How then, do you solve this impossible problem?  Simple, you lie.

When you compose and send a secure message through one of these platforms, the recipient doesn't actually get your message.  They get an email containing a link informing them that a secure email message with subject such-and-such is ready for them to view.  If they click the link, the friendly website will "securely" show them the sensitive contents.

....

Yes, you got it.  The recipient has to create an account the "secure email delivery" service's system.

Yes, they have to use the email address at which they received the message as their login ID.

Yes, they get to create their own password.

No, you don't get to make that password policy match your own.

No, you don't get to do single sign-on between their service and your authentication system.

No, you don't get to control how long those messages are stored on their service.

No, you don't get to lock out that account when the employee leaves your company.  Yes, if that person gets fired, they can still - potentially forever - get to the sensitive information that was sent to them, at the email address belonging to your company.

Yes, if an attacker had already compromised the recipient's mailbox or credentials, they would also have the ability to control the account at these services and gain unfettered access to this sensitive information.


Lots of unpleasant and colorful terms spring to mind as descriptors of what systems like this really are.

The recipients don't know any of this, and shouldn't have to.  They just need the information to do their jobs, so naturally they aren't very receptive to information security lectures by IT.  But we can't just roll our eyes and sigh and 'fix it' - this isn't fixable.  Using these stupid services wasn't our decision.  We have no control over it, we just know it is an absolutely terrible idea, is totally unsupportable, opens up dozens of new areas of risk, and adds zero value for all the effort.

There are, or may be, some services that bypass this patently idiotic system of creating additional attack vectors for identities altogether.  One interesting method is that the email is printed to a PDF, secured with a password, and delivered directly to the recipient.  The recipient would need to contact the sender for the password.  It's a far, far better idea - no third party websites or accounts to worry about managing, no transmission of information in clear text, an attacker with mailbox access wouldn't be able to see the contents without the password (transmitted by phone in-person), and even sysadmins wouldn't reasonably be able to see the contents on either side.

This would be a viable solution, but Microsoft doesn't offer this service to O365 customers (or anyone).  Their one redeeming quality, if you happen to be an O365 customer already, is that through Azure AD and Dirsync configuration, you can at least - sort of - do single sign-on management of login accounts used by recipients.  That of course assumes the recipient knows not to create a new Live ID when they receive an email, and have been trained on the (as of this time undocumented) steps to login with their company-managed account.

Many other banana-headed services that have barraged us lately don't offer secure PDF delivery either, unknowingly victimizing plenty of well intended but utterly ignorant companies buying the latest flavor of silicon snake oil.

And to think, there's so much opposition to teaching critical thinking skills in our public schools...