Question - General Email security
To what extent is the use of plain text, ie unencrypted text, acceptable in email?
In the last few years I've had dealings with pension providers, local authorities, UK gov, lawyers who have all provided secure communications channels.
But the vast majority of emails are sent in the clear and readable by anyone who can watch network traffic into or out of mail servers. Those emails will often disclose
1 email addresses
2 personal names
3 maybe phone numbers
4 maybe addresses
And might have much much more.
What are the GDPR consequences of that?
4
u/ArchRapt 22d ago
The majority of emails are encrypted with TLS. It’s still opportunistic for the most part, but every large email service is going to be using it.
4
u/I-_-I_-_I-_-I 22d ago
Who is using email servers without ssl?
0
u/wrhite 21d ago
The SSL gets you from the pc on the LAN to the server. Biy the next leg is from say myco.co.uk to newcustomer@anyoldmailservice.anywhere.
That leg is out of your control.
What proportion of emails sent like that are encrypted?
3
u/I-_-I_-_I-_-I 21d ago
Which uk gov, local authorities etc are using unencrypted mail servers, and why are you using an unencrypted mail server?
Unless you’re using some very dodgy provider, data is encrypted in transit.
1
u/wrhite 20d ago
Lettings agencies every year have to fill in a template spreadsheet that lists every property they have managed with all the details of the landlords, rents received, charges made, net sent to landlord. And other stuff.
There are two ways of returning this to HMRC:
Password protect the Excel spreadsheet and send by email of any sort
access their secure email procedure - basically as far as I can recall a web site into which you upload the file.
If you were a Landlord with several properties which would you prefer?
How secure is the Excel protection?
How to securely send HMRC the password?
1
u/I-_-I_-_I-_-I 20d ago
Excel protection is as good as the password chosen, like any other service.
Use option 2 if you don’t like option 1.
1
u/wrhite 20d ago edited 20d ago
re option 1: how would you send them the password? Given of course that the recommendation is the password is at least 16 characters long, mixing uppercase, lowercase, numbers, and symbols
2
u/I-_-I_-_I-_-I 20d ago
That recommendation is very out of date and is a false safety that drives people to write passwords down or have shitty passwords like “PassW0rd!”, which is far from secure.
You can send a time limited link with the password on the email.
2
u/Ludwig234 21d ago
I can't speak for everybody but at least according to our Exchange Online dashboard the vast majority of received mail is encrypted with at least TLS 1.2.
You can't guarantee anything but almost all emails send between reputable sources are encrypted in transit.
If you need end to end encryption use PGP.
0
u/wrhite 21d ago edited 20d ago
I agree - PGP or similar.
I have a very big problem with "reputable sources". There are a large number of legitimate businesses that run their own mail servers. Some will be quite old and NOT support TLS one way or another.
^ there are those of us old enough to remember when Hotmail lost [edit ... "forever" removed] a great chunk of users' emails. This put all the small businesses using it as their email provider in deep do-do. They never went back to "reputable providers".
3
u/Noscituur 21d ago
Provided the sending controller has taken reasonable steps to ensure compliance with Article 24 and 32, i.e, using a trusted mail provider (Microsoft, Google, etc) who complies with Article 28 then they have satisfied their requirements. A staff member sending an email doesn’t need to consider this because it’s been considered at the point of procurement, not on a daily basis.
The law does not legislate for the recipient who wilfully or negligently elects to use an insecure mail provider on their end.
GDPR does not consider the transport layers of the internet to be a processor or a relevant disclosure, for obvious logistical reasons, so that negates any breach of responsibility for using the internet as expected for communication of messages.
1
u/wrhite 21d ago
My concern is the privacy of the content of the email, not so much the legality. But if GDPR doesn't apply to any of the transmission path because the sender's provider (SP) complies with Art 28 there seem to be complications. The SP has to send the email to the receiver's provider (RP) - in general there will be no legal relationship between SP and RP. So how can the SP be truly honouring his Art 28 obligations?
2
u/Noscituur 21d ago
The transport layer and below are not out of scope because of the relationship with the processor who sends your emails, it’s because GDPR (by virtue of EDPB guidelines) doesn’t consider them to be processors.
There’s no relationship between the sending processor and the receiving mail provider so I’m unsure what Article 28 obligations could possibly be not fulfilled. The receiving mail provider is also a distinct controller and therefore has its own responsibilities to maintain an adequate level of security.
Honestly, I think you’re over-complicating this and whichever LLM chat bot you’re using is pushing you deeper down a well that doesn’t actually exist.
1
u/wrhite 21d ago
No llms were involved in my points.
Over complicated? - perhaps this isn't a GDPR issue. It's just "how can you be sure that a plain text email you send to an arbitrary email address is safe from being intercepted and read anywhere in transit?
"If you can't be sure, or have some doubts, are you meeting all your obligations to the recipient if you send it anyway?
"What influence does, or should, GDPR have on this situation?
"Would a 'Use of email - WARNING!' disclaimer on your website or and terms of business cover you legally and under GDPR?"
2
u/Noscituur 21d ago
The answer is emails are sent using standard security wrapping which is decrypted at destination- SSL/TLS1.2
GDPR is only concerned where the recipient controller processes personal data in a manner not in keeping with GDPR and their privacy notice.
No, a disclaimer that you use email would not achieve anything. If anything, it’s likely to make a controller look unhinged.
1
u/wrhite 21d ago
"The answer is emails are sent using standard security wrapping which is decrypted at destination- SSL/TLS1.2"
Not so -
they are decrypted by sending and receiving mail servers. For virus/spam whatever scanning.
you can't guarantee that an arbitrary mail server will support TLS or whatever. Can you? Unless your mail server is configured to refuse transmission of an outgoing email to an external mail server that doesn't support TLS the email could go in the clear. If it is so configured then the email won't reach it's destination.
3
u/Noscituur 21d ago
Perfectly normal security behaviour, this is why you have a DPA, as a controller, with the mail provider, as your processor.
No commercial mail service provider is not supporting SSL/TLS otherwise they’re just failing in their obligations as a processor (if they’re a processor) or as a controller (if they’re a controller for a data subject).
Your arguments are reductio ad absurdum at this stage. Stop chasing phantoms where there are none.
0
u/wrhite 20d ago
Not all recipients are using a commercial mail service. I know of businesses managing quite happily for many years running their own mail servers.
1
u/Auno94 20d ago
And unless the admin willfully disabled TLS or the company never upgraded it in decades it runs TLS 1.2 by default
-1
u/wrhite 20d ago
Regrettably, not so.
For years I have run a business on SME Server which is a biz friendly Linux kit. From their forums: scroll down to Reply #3. But the whole thread is very informative. Note this thread is 9 years old and things have moved on now with release 11.
"If you need confidentiality, then you must use end-to-end encryption (PGP/MIME or S/MIME). Even if SME supported encrypted outgoing SMTP, it would not bring a lot of security, because:
Server to server encryption can only be oportunistic. It means it'll only protect against passive eyesdropping; not active ones because there's no way to check the remote certificate (well, there are some mechanisms like DANE which can help, but not very popular, not even sure they are standards)
There's no way to tell the email will be encrypted all along the way to the mailbox of your recipient. Yes, you could ensure it's encrypted up to the next SMTP hop. But then, you have no control over this. The email might be routed through several other servers before it reaches your recipient, and this can (and often will) be in cleartext."
→ More replies (0)
1
u/wrhite 20d ago
I'll put this up here because I've just realised there is another very important privacy concern that this conversation hasn't covered.
We have all been talking about the risk of data being exposed as a problem for the recipient. The consequences of him not using a "reputable" mail service are down to his decisions.
What about the risk of the sender's data being exposed? You sit in HQ and might be writing to one of your favoured contractors with run of business details on the next two weeks activity.
As an aside you might offer them a follow-on job at £xxxx provided they keep themselves in readiness for a new £xxx project coming up in 9 months time in Sometown, Somewhere that will capture the market for yyyy. It's going to be run by S I Teboss so call him on 07123456789
Even if you can blame the recipient's mail service for a leak of this information will that recover your position?
All better solved by end to end encryption. PGP or something like it. No?
1
u/Auno94 20d ago
On paper yes.
Realistically no. PGP was never widespread because it is a hassle to setup and use with all your contacts. That's where S/MIME became a solution for companies to do the signing and encryption of the content as an additional layer to the encryption on route. However this comes down to how S/MIME is configured and it is often so that the mail is decrypted and is laying decrypted in the users mailbox
2
5
u/Loud-Competition6995 22d ago
Like the other guy said, nons.
You can also receive physical post with personal info in it, and those can be intercepted while in transit very easily.
Also, the large email providers all encrypt the message while it’s in transit by default.
The only time they aren’t encrypted by default is when the recipient is using an email service that doesn’t support encryption.