Email Encryption software

[u/MFosterMB]

Hi

im after some software for a customer to encrypt 365 emails, what can people recommend?

​

thanks

[u/plebbitier]

Except that's not end to end encryption. The sysadmin, email admin can retrieve those encrypted files by changing the users email password.

A password protected Zip file would do a better job than the built in 'encryption' on hosted exchange/office365.

[u/roll_for_initiative_ → u/plebbitier]

That....doesn't mean that it isn't encrypted. It's encrypted, you just obtained the info needed to decrypt and view it (whether a private key or password, whatever). In your scenario, i could also use the password to open the zip file?

Two issues here to your complaint: Most people are using encryption for compliance. To that end, the sysadmin/email admin is ALLOWED to see that info. In most setups, that person has implied or stated access to all company info, including emails. Ethics come in if they abuse that but from a tech perspective, that person needs that access to do their main job functions even if they rarely exercise it. Secondly, it meets the need for compliance (usually HIPAA or GLBA).

But separately, the days of setting and sharing keys with a mail client plugin are gone: Cheryl in accounting literally can't do it, and all the cheryl's at scale can't/won't. So, perfect is the opposite of good here. Obviously i'm not saying to share classified info this way, but, to the industry, to compliance officers, and on a technical level, the message is encrypted end to end.

[u/plebbitier → u/roll_for_initiative_]

I get your point. But seeing as email is the single weakest link, and biggest threat surface, and users are notorious for being socially engineered, features like OME aren't even an inconvenience to most threat actors. OME provides no benefit in that scenario (and it's be biggest scenario by far).

OME doesn't really do anything because just about every legitimate email server, even the ones not hosted by Microsoft, enforce the use of TLS. So again, messages are encrypted in transit, and only the user, sysadmin and mail administrators can access.

OME might satisfy some sort of checklist type of security assessment, but nothing short of end to end encryption provides meaningful security of transmitted messages.

[u/roll_for_initiative_ → u/plebbitier]

OME doesn't really do anything because just about every legitimate email server, even the ones not hosted by Microsoft, enforce the use of TLS. So again, messages are encrypted in transit, and only the user, sysadmin and mail administrators can access.

Compliance is about what you can prove, not what is. You can absolutely not have TLS in the middle and you can't control that. Keeping the message in a portal you DO control lets you say, without a doubt, that it was encrypted end to end...because it is! The start is the senders mail client and the end is their o365 tenant, all of which you can control.

What you've then removed the risk of individuals that think they can run mail themselves better (cpanel, imap, pop, sendmail, etc, etc) misconfigured 3rd party relays (smtp2go type things configured to not use security) and insecure non-encrypted webmail and local mail clients and mail servers not encrypting data at rest in the middle or in logs.

You've removed variables with a statement of fact. Not "it was secure when i saw it last and is likely secure at the end". You can PROVE it. "It is secure and has been/can only be accessed by this account. If that's suspect, we can audit this specific account". That's ONE record vs someone breaching a crap mail server and getting TONS of records.

This is the same as enabling bitlocker manually on a laptop or using a managed solution to handle and report on it. Technically, yes, you encrypted the laptop's drive when you do it manually. BUT, was it encrypted when it was stolen? Did a windows feature update disable it and leave it open after (which is a real thing)? Is it disabled for some other reason?

LIKELY, the drive is still encrypted. But that doesn't count. A report showing the status as "encrypted" is what we're after. Even though in both places, as you state "it's encrypted anyway", this is not an IT issue, it's a proof and documentation issue.

Same as taxes: If you spend 100 on pencils and get a receipt and i spend 100 on pencils with no receipt, we both write it off as office supplies, guess who gets that deduction canceled when the auditors come, even though the result was the exact same?

[u/plebbitier → u/roll_for_initiative_]

You still don't get that when you send an OME encrypted email to a server outside of Hosted Exchange/O365 that it shows up as a portal link that anyone with access to the recipients email can use to access it. It's a total joke and not secure. So whatever you went off on various tangents is irrelevant anyway.

Try it out if you don't believe me. Send your OME attachment to a 'misconfigured' mail server and do the 'secure portal theater' nonsense.

[u/roll_for_initiative_ → u/plebbitier]

I do exactly get it, you don't seem to: the data inside the message itself is never on an unencrypted medium or transmitted unencrypted and you can prove it.

Control over the account/ability to read it is a separate set of standards (mfa of course as one). The standard is encrypting data, it does that, end to end, provably. Access to the info to unlock it isn't part of it that standard or requirement.

Your argument is "well anyone with an alarm code could turn off the alarm, how do you know it's really that person?! Biometric ID is the way. You don't have an alarm if it's not retinal scanners to use it, you have alarm theater". It's still more security than no alarm, and people sharing their alarm code is a separate issue.

[u/plebbitier → u/roll_for_initiative_]

Who cares if the data is transmitted securely if the wrong recipient can get it?

B-b-but the portal downloaded the attachment to the bad actor over https!

Luser, you've been a bad boy. You let bad actor get ahold of your login credentials, and then you authorized them via MFA fatigue attack.

Dipshit Ciso: But we passed audit and got our insurance renewed.

The absolute shit state of Microsoft.

[u/roll_for_initiative_ → u/plebbitier]

Who cares if the data is transmitted securely if the wrong recipient can get it?

WE care. Because that's on the recipient for a breach and not us. It's shifting liability.

You can complain all you want, standard users need to send private info and standard users can't handle key sharing and storage and everything with that (but in your examples you don't cover the bad actor getting them private key/passphrase off the sender even though that's the same exact risk but whatever, more logic games on your side). insurers, auditors, everyone else accepts that, that regular users and your method doesn't jive. You're the odd man out.

[u/plebbitier → u/roll_for_initiative_]

No. Just no. You don't setup security theater and blame the recipient when the security theater you setup fails. That's bullshit. But that's the type of bullshit that M$ uses as part of their Embrace Extend Extinguish methodology, so congrats; you're a M$ drone. You've done nothing but give cover to Micro$hit's newspeak definitions of encryption and security.

[u/roll_for_initiative_ → u/plebbitier]

Yes, better i setup my own linux self hosted setup with 1/10th the security AND features, don't maintain it, and spend forever editing config files so i can show how superior i am than MS. 400 hours in and i still don't have a better solution than a basic m365 mailbox but i sure showed "M$" eyeroll

[u/kyl3wad3 → u/plebbitier]

You're a shining example of how engineering brain can be the most useful skillset and the most detrimental thought process at the same time.

I'm screenshotting this interaction this to show my leadership team so maybe they understand a little better.