Posted 12 months ago
Various people have been declaring the death of email for years now. Not only has it not died, but if anything, email is going stronger than ever in 2020. There is simply no better way to communicate asynchronously with business associates.
The frictionless nature of communicating via composed messages, similar to the hand-written letters that preceded the technology, is a big part of what’s led to the nearly universal acceptance of email as the way we communicate now. The road to email ubiquity is a longer one that many people realize, seeing as how in the early days it was relegated to military and academic audiences only.
In 2001, email celebrated its 30th birthday and nearly every business on the planet was using it to communicate both internally and with outside partners. From there, the 2007 release of the first iPhone ushered in the mobile email revolution. Yes, it’s true that other mobile devices existed before the iPhone, but none caught on as well, or as fast.
Along with the rise of email came a concurrent rise in its use by malicious actors looking for quick paydays. Phishing and spam were just the beginning, leading to the adoption of email encryption by those capable of navigating the often complex and convoluted systems necessary. Thankfully, today automation is becoming nearly as ubiquitous as email itself, rendering many of these issues a thing of the past.
In 2015 it was estimated that over 200 billion email messages were being sent every day. Far from being on its deathbed, email is alive and very well indeed. Of course, such widespread success comes with some issues. And in the case of email, those issues revolve around one primary aspect of the technology—it was designed to be easy, not secure.
In short, the protocols that underpin email don’t allow for ready encryption. These protocols date back to ARPANET, which was only used by select military and academic institutions and had no connection to the broader world. There was no public access, so there was no way for phishing, worms, viruses, or other malware to make its way into the closed ecosystem that was the internet.
Back in the day, this wasn’t a problem since the environment email was operating in had an inherent sense of trust: everyone using it already knew everyone else who had access, so trust wasn’t a problem and the protocols were never changed. This means that even today, encryption has to be a layer on top of the email and whatever data it contains, rather than something that comes standard.
This inherent trust continued into the early days of the public internet until 1988, when the players of a particular multi-user dungeon game began flooding their rival’s servers with unwanted email messages in attempts to crash their servers and win matches by default. This was the beginning of both spam emails and DDOS attacks. The name “spam” wasn’t applied to emails of this type until 1993, however, when someone decided to apply the name of their favorite Monty Python sketch to these unwanted intrusions.
By 2019, over 4 billion phishing emails were being sent every day.
That statistic about phishing emails brings us to the problem inherent with modern email systems: they’re still based on the same protocols developed in the cloistered environment of ARPANET and are simply not able to keep up with scammers and other malicious players on the internet to keep your data safe and secure.
The development and defining of SMTP (Simple Mail Transfer Protocol), which was intended to simplify email protocols, in effect added to the list of problems by allowing open fields. For example, under SMTP, the from and reply-to fields don’t have to match. This one decision is responsible for the ease with which fraudsters can spoof legitimate email addresses by simply falsifying the from field while using their own address as the reply-to.
Obviously, the rise of phishing emails made it obvious that some protection for sensitive emails was necessary. This led to the rise of PGP, which was released as the first solution to provide end-to-end encryption of emails and their attachments. PGP (which stands for Pretty Good Privacy) is itself a set of algorithms used to encrypt and decrypt emails, attachments, and even entire storage volumes using the open-source encryption standard RFC 4880. In reaction to perceived shortcomings in PGP, S/MIME was brought to market soon thereafter as an alternative aiming at wider adoption of end-to-end email encryption and digital signing.
The first true attempt at securing a commercial email system was in 1995 and came in the form of AOL implementing security measures trying to halt what were the beginnings of phishing scam emails (though they weren’t called this yet). Shortly thereafter, in 1998, STARTTLS added much-needed security to existing implementations of SMTP. The major stumbling block encountered was the lack of compliance since on the user’s end this process often still involved manual interventions and/or advanced technical knowledge.
And finally, in 2005 the first anti-spam programs were released, verifying server identity in order to weed out emails that were coming from known bad actors or being bounced around in an attempt to hide the true origins of the message. Around this same time, Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) went into widespread use to assist with spam and malware intrusions.
As you can see, it’s not like the industry was just sitting back watching these problems develop. Progress was being made, it was just slower than that made by the hackers and other malicious fraudsters. For every step made in preventing malware, malicious actors made 3 steps in a different direction and simply sidestepped these prevention measures. And all of this leaves out the problem of Man In The Middle attacks (MITM), malware attachments, and other attack vectors. Not to mention the simple idea of secure communication being lost in the fray. What is a company to do when they need to send sensitive financial records to their accounting firm or client data to an upstream partner when everything they send is right there in the open for anyone to see?
Here’s a scenario for you to consider. Your company employs ~500 people located in offices spread across 4 countries and 2 continents. You’re using a hosted Exchange server that your teams access via Outlook, and you have PGP installed and active on all accounts. Yet, somehow, last month the company reported that because of a BEC attack over $100,000 was lost before the fraudulent account was discovered.
Some things to consider when debriefing this situation. Do you have a protocol in place for key swaps, and do all employees know what that protocol is? Can you audit your key server to see whose keys are in danger of expiring? How about when people are remote or otherwise out of the office (or working from home due to the pandemic), what application are they using to correspond and do they have your corporate encryption solution installed on their personal devices?
You can see where we’re going, it’s one thing to have encryption installed, it’s another entirely to ensure it’s being used. In all likelihood your post-mortem will uncover that the attack started with a spoofed account, made easier to access due to someone not using encryption on their smartphone.
Encryption is only effective when everybody uses it, every time.
We’re not disputing that PGP and S/MIME revolutionized email security because it’s simply a fact that they did. We do however want to highlight a caveat—users need a high level of technical acumen to use them successfully. And in order for security and encryption to be effective, users have to actually use it.
By automating many of the key aspects of E2E email encryption, this caveat can easily be overcome. Taking things like key and identity management out of the user’s hands, encryption becomes frictionless and that much more likely to be used for all communications. The next generation of E2E email encryption tools is doing just that. For example, p≡p offers an intuitive user interface that hides advanced automation of all management aspects of the encryption process.
Perhaps the single most frustrating part of using encryption is keeping track of your public keys. They need to be stored securely, changed out every so often, and only shared with communication partners so as to establish secure connections. p≡p takes all of that and automates it. Users never even see their key. This management is decentralized so there’s no key server to maintain either. Everything is device-based.
When a p≡p user opens their email app, whether on PC, Mac, or mobile device they see a clear and easy to understand color-coded indicator light on every message in their inbox. If they see a green indicator, they know that the message is both secure and from a trusted partner. A yellow light means the message is properly encrypted, but the sender is not yet trusted. No color in the indicator means the message is either not encrypted or that encryption is subpar. And last, a red indicator means the message has been flagged as mistrusted.
We mentioned above that a message can be from a “trusted” sender. This is part of p≡p’s automated identity management protocol called Trustwords. Users can follow a simple procedure known as a Handshake to establish a trusted connection by comparing a series of words, presented in plain language both parties understand. Once this handshake is accomplished, all email communication between them will be both encrypted and trusted. This ensures that not only is the data secure, but so is the integrity of that data.