Why You Need Email Encryption?
It may come as a shock to learn that as a standard: emails are not encrypted.
Emails are delivered in plain text, which means that when your email bounces from your email provider’s server to the email provider of your recipient, it can be read, intercepted and changed before it completes its journey.
This is the equivalent of sending postcards to people instead of securing the letter with an envelope. It is especially true for emails sent over public Wi-Fi networks, where security is often lacking but it can also be true for encrypted networks like those in an office building or in an educational setting.
Even backed up or saved emails in programs like Microsoft Outlook are vulnerable. If a hacker gains access to your device, your emails are readable and potentially sensitive or personal content could be leaked.
For an institution like a school, this presents all kinds of data protection issues. Information about students and parents can be sold on the dark web, encrypted by hackers and put on ransom or even destroyed by viruses and malware. These acts could cause harmful damage to an educational institution both reputationally and financially (in the form of fines like GDPR).
Email encryption has been historically difficult, primarily because the email is sent through multiple servers, landing on devices and being read by humans – all of these elements create an opportunity for a hacker to read, intercept or change the email before it reaches its next destination. That’s why it’s recommended that you encrypt:
- the connection to your email provider
- each email before you send them
- email archives and saved emails
Encrypting the Connection To Your Email Provider
The first step in securing email connections is server to server. If a business or educational institution is using GSuite for emails, then you will be sending emails from Google Mail Servers. Let’s say you’re sending an email to someone with an Outlook account, then Google Mail Servers will be communicating with Microsoft’s email servers.
The most commonly used communication protocol between mail servers is known as SMTP (Simple Mail Transfer Protocol). Just to give you an idea of how old and outdated SMTP is, it was published in November 1981!
By the time the industry realised the importance of email encryption, SMPT was being used all over the world to send emails and the job of encrypting retrospectively became a technical nightmare. In the end, a version of SMTP known as SMTPS (the additional S standing for “secure”) was created.
I will endeavour to explain SMTPS in more detail in another blog but in short, your device and your email server still communicate in SMTP but the SMTP communication is now wrapped in an additional layer known as TLS (Transport Layer Security). This happens when the connection is established before any data is exchanged.
There are two options when establishing a TLS encryption for email:
- Opportunistic – an email client (your device) will tell an email server that it wants to communicate securely but if the attempt fails it will proceed in plain text.
- Forced – an email client will demand that it communicates privately with the email server and the email server must reply to tell the client whether that arrangement is possible or not. If it’s not compatible with the version of TLS used by the client, doesn’t support TLS at all or the connection fails, the transmission will be stopped and the email won’t be moved any further.
Most email providers (including GSuite and Microsoft) are set to opportunistic meaning that if there is no way to encrypt the email, it will be sent automatically in plaintext and therefore susceptible to reading, intercepting and changing by any hacker capable of accessing an SMTP server.
Encrypting the Emails Before You Send Them
The above method does have one caveat; it cannot protect the message as it travels from the user’s client (device) to the server. That’s where end-to-end encryption is useful.
End-to-end means the message is encrypted on the user device with a TLS Certificate. It travels from server to server with this encryption on it and is only decrypted when it lands on the recipient device, provided the recipient has the public key to decrypt the message.
You might have heard the term “end-to-end” encryption as it has increased in popularity and been brought to the forefront of many popular internet services such as Facebook, WhatsApp, Google and more. When encrypting at the server level, email providers and mail server hackers can read your messages, when end-to-end encrypted, even Google cannot read your emails.
There are still possible attack vectors for hackers with regards to end-to-end encryption. The difference is, instead of hacking the email server, a cybercriminal turns to a user’s end-device and tries to get access to the TLS Certificate. A more difficult task but not impossible; if the user is flippant with passwords or not careful when using public Wi-Fi it becomes easier for a hacker to get access to that sensitive data.
Another possible area of attack is the email meta-data. While the email is encrypted, its meta-data (i.e. the identity of the sender, the identity of the receiver, the subject line and the time sent) are all available to be read and can, if analysed, expose a wealth of information about an educational institution.
End-to-end encryption also poses a problem when it comes to spam and phishing emails since there is no way for an email server to scan emails and decipher what is spam and what isn’t. One way to get around this is to send a whitelist of emails that you want to receive emails from but this poses another security risk as the whitelist can be read by cybercriminals.
Encrypting Archived Messages
If, for compliance reasons, you’re keeping an archive of emails, a problem for IT administrators arises on keeping the emails secure and readable while they’re archived. Using the above example of TLS Certificates to encrypt archived emails becomes a problem very quickly when you have to keep track of many TLS Certificates, ensuring they remain valid and keys are not lost.
Another sensible option is to decrypt all the emails before archiving them and then store them in a secure location encrypting the entire file or storage area, rather than each individual email. Using this method puts a spotlight on why organisations or educational institutions who need to protect their data should encrypt emails both at the server level and end-to-end. End-to-end is great but once you start storing archived emails on a server, you open yourself up to attack again.
Secure Email For Educational Institutions
One way to get around some of the outlines of the challenge above is to implement a secure email gateway solution like Pie Security. Pie Security works with Exchange and Outlook to provide additional security layers and automatically encrypt emails within the educational institution’s internal network. Where encryption is needed outside of the network (like with parents), this can be easily set up.