Having listened to the past two episodes made me think some more about email in a professional context, particularly legal practice. Email messages and attachments are not, by default at least, encrypted. This doesn’t overly matter if both sender and recipient are running their own IMAP servers on their own hardware because all legs (sender’s email client to sender’s server, sender’s server to recipient’s server and recipient’s server to recipient’s email client) use encrypted tunnels. However, the messages sit on the servers (for some period if POP and indefinitely if IMAP) as unencrypted data. Even if the mail service has superlative security that prevents a bad actor from accessing it, that data is subject to legitimate subpeona. Further, there is strong argument that as it’s in the hands of a third party, it’s no longer privileged (that may not be the case in the US, but I don’t practice there!).
Has @macsparky (or anyone else) any thoughts? Do you just not use email for potentially privileged communications? iMessage/ Whatsapp/ Telegram would be fine (as long as you don’t backup to iCloud) as there messages are encrypted end-to-end. Using and email service that provided some form of full disk encryption (like Filevault) would also work, providing you (not the service provider) could generate the key.
A non-technical response: lawyer codes of professional conduct require taking certain actions to protect their client’s information, including preventing or limiting disclosure of confidential information or information protected by attorney-client privilege so the use of technology led lawyers back in the days of fax to amend confidentiality disclaimers in the ultimate hope that a reviewing judge will agree that the lawyers have taken reasonable steps to protect confidential information. This is a fig leaf, but an accepted one, and is used nowadays for everything from asserting confidentiality in emails to disclaiming liability in sending a virus by email.
If you taken minimal secure practices (no matter how poor in practice) you may be seen to have appropriately addressed confidentiality and privilege.
Yes, the code of professional conduct can be met by taking all reasonable steps, but I’ve never really had to think about them other than in the context of working in a large law firm and subsequently in-house. In both circumstances all email went through on premise mail servers so the ability to protect privileged communications was never in doubt. Now I’m out of that I was wondering how best to manage client emails. Fastmail was presented as a good host for mail servers, but there was no discussion of its security limitations (which I suspect are no better or worse that iClioud mail) or of alternatives.
If anyone has suggestions of a secure email service, I’d be grateful. I’ve come across ProtonMail and a swift search throws up a number of others in Germany, however I’ve nothing to differentiate between them.
Anyone know if they ever passed the Email Privacy Act? As late as 2018 law enforcement didn’t even need a warrant to get a copy of emails older than 180 days.
It seems like requiring email to be encrypted to be considered confidential would be holding it to a much higher standard than, say, physical mail or telephone conversations (both of which are vulnerable to interception or legal processes).
Let me start by saying that I’m by no means a security expert. I do know a bit about mailservers though, and what you’re stating here is definitely not true. First of all since there is no such thing as direct communication over the internet. Even if both sender and recipient run their own mailserver (define: own mailserver…) this absolutely doesn’t imply the message takes a straight line. Actually, there is not such thing as a straight line on the internet.
Besides, TLS is not encryption. It protects the headers, not the content. Regular a-mail, by definition, is insecure. Your e-mail is like a postcard. It can be read by everyone with access to any of the points it is passing through.
If you want confidentiality you need to encrypt you message. Either yourself, or by using a secure mail service. The recipient does need a way to decrypt that message then. Which is one of the reasons encrypted email never took off in a big way.
(In an ideal world) a secure way to share private documents is hosting them (encrypted) on a server you own and control and granting your “recipient” a secure access to that server (e.g. a shared “client folder”). edit: of course this solution is subject to all the risks of having something accessible from the internet.
In the real world everybody uses email.
If you (lawyer, company etc) comply to all the regulations that states what is “secure” once the communication left your own domain you’re ok, it should be someone else liability.
I am by no means an email expert, but I do manage information security for my employer and have more than a passing familiarity with networking Your remarks have me a bit curious:
TLS absolutely does encrypt the body of your email message between client and server, unless TLS for email behaves radically differently than for every other application that runs over it. If that’s the case, I would be very interested to know.
And, while it’s true that no packet travelling between hosts over the Internet is going from one endpoint to the other directly, the end to end encryption provided by TLS between email client and server can be though of as being effectively a direct connection that it not feasibly possible to intercept.
What may happen between email servers and with email residing on servers are entirely different things though and absolutely should be of concern for someone who is attempting to conduct confidential business.
My best (free) advice to the OP is to consult your regulating body for guidance around this, and if they can’t provide something concrete then I think it’s highly advisable to pay someone reputable who understands both the technology and the regulations under which you operate to give you advice.
Like I said, no expert on this topic. Just my common understanding. However, if TLS encrypts your body, why are there secure mail services and add-ons like PGP?
Because secure encrypted mail is guaranteed to only be seen by the recipient, it proves who it came from, and if mail is accidentally sent to the wrong recipient they won’t be able to read it.
And commercial mail services and products can access email if they choose for informational and advertising purposes, as can rogue employees, hackers and governments - because email is encrypted during transmission but typically stored in clear text.
Obviously that isn’t a compelling enough reason for more than a tiny percentage to use it, though.
Another website mentions this, which is/was also my understanding of the topic:
For example, with end-to-end encryption, a plaintext message that you sent gets encrypted at your end and gets decrypted only after reaching the recipient’s device. However, in TLS, a plaintext message gets encrypted at your end and decrypted at the server. The message further gets encrypted depending on whether or not the recipient is also using TLS.
Anyway, long story short (and my final comment on this) if you want/need to be absolutely sure your mail can’t be read by third parties E2EE must be used. TLS is not sufficient. Of course TLS or any variation on that theme should be the standard for mailservers by now.
TLS encrypts traffic between two endpoints. It’s end to end, but the endpoints in question are the client and their mail server, not the sender and recipient (in the case of email). As I said, once it’s gotten to the sever, the protection of TLS vanishes. The data at rest on the servers is accessible by whoever manages them and there is not guarantee that email passed between servers will be encrypted.
I’m not at all disagreeing with your assertion that email is like a postcard (great way of putting it), only about how TLS works and what it does.
That also answers your question about why PGP and the like exist, as bowline pointed out; it provides encryption that persists from sender to recipient.
Whether PGP is sufficient to address the OP’s concerns is unknown to me. If the knowledge that email has been exchanged between parties is potentially compromising then it is not.
I think close, but: server<->server may not be encrypted either, and using encryption (like PGP) encrypts the contents of email end-to-end, but does not hide the fact that email was sent (so whether you want to characterize that as E2E depends on your definition of that term, or whether or not you work in marketing )
Good point. So how would somebody determine which paths are encrypted?
For example, on my iPhone I see that “Use SSL” is turned on for “incoming settings” on an exchange and gmail account. I don’t see anything available for the iCloud account.
Theoretically I can only control my path to the server unless I do E2EE
I’m pretty sure that iCloud connections are encrypted by default, with no option to turn it off.
As far as determining which paths beyond between your endpoint and the server to which it’s connecting are encrypted? For email you really can’t. If you’re looking for confidentiality for your email then further encrypting it with something like PGP is necessary.
The one (kind of) exception to that is if it’s all being handled by a single email system (like your work Exchange), you can be fairly sure that email exchanged between two users of that system will be encrypted when in transit, though it will still likely be in plaintext on the server and potentially visible to anyone who has access (legally or otherwise) to that server.
Your remarks have me a bit curious:
)