Table of Contents
Since the day of its invention, E-mail has been the main communication tool used on the Internet: its use has increased exponentially year after year, mostly thanks to attachment files, i.e. the well known feature that allows users to "attach" files of any type: PDFs, ZIP archives, images, and even videos (as long as the receiver has enough space in its mailbox).
Unfortunately, the E-mail service poses some major security issues that primarily depend on its underlying architecture: the old and outdated protocols that are still used nowadays for sending and receiving e-mail messages are intrinsically unsafe and do not guarantee the fundamental security criteria (confidentiality, integrity, availability) required by today's standards.
In this post we'll try to summarize the main problems affecting the e-mail service and briefly mention some useful workaround that can be used to mitigate some of these threats.
Why emails are not secure?
Email was designed to be as open and accessible as possible. Such approach made possible to quickly and effectively develop multiple implementation around various devices and/or operating systems, thus allowing people to communicate with each other without limits or restrictions regardless of the technology used. Unfortunately, the chosen approach was not secure, for a number of reasons:
- Email messages are meant to go through potentially untrustworthy intermediate computers (email servers, ISPs) before reaching their destination, and there is no way to verify if they were accessed by an unauthorized entity. Through the process of information being sent from the user's computer to the email service provider, data acquisition is taking place, most of the time without the user knowing. There are certain data collection methods (routers) that are used for data privacy concerns, but there are others that can be harmful to the user. It's worth noting that such problem also affects attached files, regardless of the various transmission formats used by most e-mail clients (including MS Exchange and MS Outlook's TNEF-encoded attachment files). A good workaround for that is to stop to send privacy-sensitive files as e-mail attachments and use more secure alternatives (see our cloud-based or on-premise storage services for more info or that).
- The core email protocols do not have any mechanism for authentication: for example, the identity of the sender is only guaranteed by the STMP server it uses to send the e-mail from. This flaw allows attackers to use email as a way to cause problems in attempt to profit (spam campaigns, malware and phishing attacks, and so on), including the chance to use arbitrary e-mail addresses (forging) or even known ones (spoofing). Such issues can be mitigated using some technical standards specifically designed to supplement SMTP (SPF, DKIM, DMARC): however, their adoption is neither mandatory nor standardized throughout the service providers, which makes them not always effective.
- Email protocols don't natively support encryption. The SMTP protocol (Simple Mail Transfer Protocol), which was developed in 1982, was not designed with data security in mind, therefore it doesn't come with any support for password encrypted messages, symmetric or asymmetric encryptions, or anything like that. Again, such flaw can be mitigated by adopting some of the most common End-to-End Encryption (E2EE) technologies such as OpenPGP, S/MIME, Secure Message Escrow or other methods that can greatly improve the security of email communication: however, they can be tricky to implement and they require senders and receivers to jointly adopt them, which would greatly impact the compatibility and usability of the service.
What about PEC?
The inherent problems of the architecture upon which e-mail is based have long prevented this communication channel from being used as an official notification tool. However, since e-mail messages are still the most widely used method of sending data over the web, many international bodies have struggled to create guidelines to create a secure communication platform based upon the same overall logic (and user experience) used by today's e-mail service.
One of the most promising examples is included in the European Union's Electronic IDentification Authentication and Signature (eIDAS) regulation, a set of rules and guidelines written to provide a common regulatory basis for secure electronic interactions between citizens, businesses and public administrations, as well to increase the security and effectiveness of electronic services and e-business and electronic commerce transactions. Such regulation includes the guidelines for a certified electronic delivery service (SERCQ or SERC) that, if implemented properly, could fix most of the security issues intrinsically present in the e-mail service.
Unfortunately, SERCQ/SERC is still not implemented in most EU countries, including Italy: what we have there instead is a sort of "beta version" called Certified Electronic Mail (PEC), which however does not in any way guarantee the security standards required by the specifications requested by SERCQ/SERC.
Major PEC flaws
The first flaw that comes into view when looking at the PEC implementation against SERCQ specifications is the fact that the former don't give the chance to verify the identity of sender and recipient "out of the box": as a matter of fact, such identification level is only provided withthe joint use of an electronic signature or other secure identification tools, thus providing an additional layer over the standard (just like standard e-mail messages).
This raises an obvious question: if Certified Email (PEC) does not allow to verify the identity of the sender and recipient, how is it different from normal email? The answer, regardless of any judgment of merit, is the following:
- PEC can only be sent and received through a pre-authorized list of known and certified service providers, which are required to adopt some additional security standards.
- PEC gives the sender and the receiver an electronic proof of a documentation exchange thanks to some e-receipts generated by the abovely mentioned certified providers.
That's about it. It goes without saying that these two features are not enough to make the PEC a "secure" channel or to consider this standard adequate to guarantee the fundamental principles of information security, also known as the CIA triad: confidentiality, integrity, and availability. Conversely, it can be said that PEC poses a serious threat on all of them.
More specifically:
- Confidentiality is undermined by the fact that the PEC software is installed and used on the PCs that users normally use, which are inevitably exposed to the risk deriving from spyware and malware;
- Integrity is weakened by the possibility of deleting (or, under certain conditions, modifying) any message or attachment present in the box, including any receipts, both intentionally (e.g. by malicious persons) or inadvertently (e.g. by of the same recipient); the exercise of this right with relative simplicity is a direct consequence of the choice to base the PEC standard on a specific technology (email), in open contrast to the EU specifications (eIDAS) which adopt the principle of "technological neutrality".
- Availability is compromised by two important aspects that have not been appropriately regulated by the Italian legislator: A) the fact that the notification date of the filed file legally coincides with the filing date: this decision entails the need for the subject to regularly monitor their certified mailbox to avoid the expiry of any terms contained in an act which, hypothetically, will be downloaded after a certain period of time; B) problems relating to the capacity of mailboxes, as well as the conservation of messages.
Conclusion
That's it, at least for now: we hope that this analysis of e-mail security issues, as well as the mitigation alternatives we've suggested, will help users and system administrators to find better and most secure ways to transfer their data.
