In 🔗 Part 1, we explained how end-to-end encryption, which is an example of what’s often called encryption in transit or encryption in flight, differs from encryption at rest.
“Encryption at rest” is a fancy way of saying that data kept in storage, such as on laptop hard disks or phones, on removable USB drives, or in cloud buckets, is protected against misuse if your files are stolen.
This an important part of our digital lifestyle these days, given that laptops are often lost, and mobile phones stolen, sometimes by opportunistic thieves taking advantage of a moment of inattention, but increasingly commonly by organized and determined gangs of phone snatchers.
If your laptop was shut down when you left it at the airport or in a cab, or if your phone was locked (with a decent lockcode, not with something easily guessed such as 000000 or 123456) when it was grabbed, you’re probably OK if the device was protected with FDE, short for full disk encryption, as we explained in Part 1.
FDE means that there’s a master password that locks up all (or at least most of) the data on the device while it’s not in use.
So, even a criminal who grafts your hard disk into a computer of their own, or desolders the storage chips from your mobile phone and connects them to specialized low-level chip-reading hardware, will struggle to make sense of the raw data.
Importantly, even if you have individual files on your device that you’ve encrypted for additional security, FDE provides an extra layer of cryptographic comfort:
Everything gets encrypted, whether it’s a cat video, your latest tax return, or a confidential log file that you didn’t know was there.
The problem with data that’s only encrypted at rest, of course, is that it’s not protected while it’s in transit.
Even if you trust the person at the other end of your data’s journey to lock it up safely once it’s arrived, what about the journey itself?
With full-disk encryption, for example, most documents that you send along with emails will be decrypted automatically at the moment you attach them, and most files backed up into the cloud or on to removable drives will be decrypted simply by virtue of being read in for the copying process.
Whether those files are re-encrypted at the other end or not, it’s important that they’re shielded automatically while they’re “in flight”, for the entire duration of the journey.
That’s because data flowing across the internet can easily be sniffed out and snooped on, given that it typically takes numerous “network hops” along the way.
These hops typically include network switches, company firewalls, ISP routers, network backbone equipment, and (in some countries) government-mandated firewalls and filters implemented for a wide variety of reasons.
Although the data is typically broken up into packets or fragments, even modest routers can easily collect and store the raw traffic going to or from anyone of interest, and stitch it back together to scouring it for its hidden secrets later.
In Part 1, we described how end-to-end encryption protocols shield the data we send and receive, aiming to prevent the sniffing out of our online lifestyles in the way that the text of Gulliver’s Travels was sniffed out packet-by-packet above.
The best-known example of an end-to-end encryption protocol is almost certainly HTTPS, which puts the padlock into your address bar to keep your data secure as it travels to and from the websites you use.
We showed a real-world example in Part 1, using a DNS request (looking up the IP number for solcyber.com) that we intercepted without HTTPS, and then again using end-to-end encryption in the form of DNS-over-HTTPS.
In the unencrypted exchange, the entire process was laid bare:
But with HTTPS in use, there was nothing useful for a snoop to intercept:
With all this in mind, and with end-to-end encryption widely implemented and used, it sounds as we though can stop worrying about data-grabbing rogues on the internet.
Yet we keep hearing about breaches and busts based on data recovered from individuals and businesses, even when they thought they were taking great care to use end-to-end encryption for all their communications.
That’s because cybercriminals, state-sponsored “threat actors”, and intellectual property thieves have a whole battery of tricks to sidestep end-to-end encryption.
End-to-end encryption protects your precious data while it’s in flight, but isn’t applied until the moment that the data gets send out, and gets stripped off as soon as it’s received.
If you’re really careful, you might end up with data that’s triply-encrypted during transmission, such as a Word document that’s encrypted at rest in a file on your disk, uploaded using HTTPS encryption via your browser, and then encrypted in flight once again over a VPN connection.
But if there’s so-called RAM scraping malware on your computer or mobile phone looking out for key phrases in memory while you’re typing in the document, or zombie malware that can be remotely instructed to take silent screenshots while you’ve got confidential files open, all the end-to-end encryption in the world isn’t going to prevent an attacker from grabbing your trophy data in its most vulnerable state, namely while you are actually using it.
Ironically, attackers who use booby-trapped apps or other malware to eavesdrop directly on your device for secrets, from passwords to proprietary business plans, typically use end-to-end encryption themselves, for example in the form of HTTPS uploads, to exfiltrate your data (which is just a fancy cybersecurity term for “stealing it”) in a way that’s hard for you yourself to detect and prevent.
The criminals aren’t cracking or attacking the encryption itself; they’re simply sidestepping it by listening in just before the encryption starts, or just after it ends.
Many businesses, and some service providers, insist on undermining and cracking open end-to-end encryption protocols themselves, where possible, for their own security reasons.
As counterproductive as this sounds, there’s sometimes a good reason for doing what’s known variously as keybridging, decrypt-recrypt and middleboxing, although when criminals do it we refer to it as a MitM, or manipulator-in-the-middle attack.
For example, for several years now, almost all phishing websites have made use of end-to-end encryption in the form of HTTPS, not least because almost all hosted web service these days provide officially-signed HTTPS certificates as part of even their most inexpensive cloud-based web products.
(Remember that HTTPS by design protects the connection – it’s providing TLS, or transport layer security, after all – and doesn’t vouch for the correctness or trustworthiness of the served-up content.)
So, even if your web-filtering firewall already knows that the URLs on a phishing page are dangerous, it can only directly detect and block them in flight if the page is downloaded using plain old HTTP.
Once the rogue links are wrapped by HTTPS, they’re not scannable or blockable until they’re decrypted right inside your browser, because the same cryptographic technology that protects you from the crooks…
…also, perversely, protects the crooks from you.
MitM inspection, therefore, relies on configuring all the laptops in your company to trust your own firewall, explicitly and completely, as what’s known as a Certificate Authority that can vouch for any server, organization or even government in the world.
If you want to connect, say, to https:/example.com, the firewall accepts the HTTPS connection itself, generates a fake web certificate in the name of example.com that your browser will trust, even though wasn’t issued by or to the real example.com, and sets up a secure connection that your browser treats as trustworthy.
The firewall then negotiates its own, independent onward connection to example.com, and shuttles requests and replies between the two connections, thus creating a “decrypt-recrypt proxy” between the sites.
Your end-to-end connection doesn’t actually end at example.com, and example.com‘s connection doesn’t end at your browser.
The firewall acts as an unencrypted “bridge” between the two endpoints, so it can inspect, log, block, and even modify the requests and replies in transit.
if you’re wondering, “What could possibly go wrong?”, you are not alone.
If the firewall itself gets breached, then attackers could get hold of lots of dangerous material, such as:
With the master “impersonation key” stolen from a decrypt-recrypt company firewall, criminals can sign their own HTTPS certificates in the name of almost any site or company they like, and the laptops of everyone who works for that company will accept those fake website security certificates as real.
(For decrypt-recrypt to work in the first place, your laptop needs to be told to treat your own company’s certificate signing key in the same fully trusting way it would accept a certificate signed by any of the big Certificate Authorities that all major browsers accept by default.)
Ephemeral (one-time) cryptographic keys are supposed to be thrown away immediately after use, as their name suggests.
But many software products that support end-to-end encryption can be sneakily configured to keep a record of those one-off keys anyway.
As reckless as this “feature” sounds, it can be useful for debugging, software testing, cryptographic certification, security review, and duly-authorized troubleshooting.
In fact, deliberately extracting the per-connection decryption keys from a third-party application is sometimes the only way of figuring out what it’s doing, how much data it is sharing with the vendor, or why it’s going wrong, because intercepting the encrypted traffic alone tells you next to nothing.
As an example, and as a useful tip if you ever need to use this feature for good, software including the browsers Chrome/Chromium, Edge and Firefox, as well as the command-line tools curl and wget, will keep a permanent record of the ephemeral encryption keys used for every TLS connection, if a special environment variable called SSLKEYLOGFILE is set.
Here’s an example download utility I created that supports this key-leaking option, with the feature turned off and then on:
When combined with captured network traffic, either in real-time or later on, these saved keys can be used to convert the secure traffic into its plaintext form, as though the connection had used HTTP instead of HTTPS.
Here’s the HTTPS connection traffic, intercepted, saved, and loaded into Wireshark:
But when the extracted SSLKEYLOGFILE data is supplied to Wireshark (via Edit > Preferences > Protocols > TLS > (Pre)-Master-Secret log filename), the plaintext of the data that was originally end-to-end encrypted is extracted automatically:
(Wireshark knows which connections it can decrypt by matching up the CLIENT_RANDOM string, which does not need to be kept secret, with the data in the TLS setup traffic known as Client Hello.)
Annoyingly, strong end-to-end encryption schemes can be undone even if the underlying cryptographic algorithms are correctly implemented, without any password cracking or mathematical cryptographic attacks.
End-to-end encryption is much more likely to be compromised by:
You can protect yourself and your business against these problems by:
Learn more about our mobile security solution that goes beyond traditional MDM (mobile device management) software, and offers active on-device protection that’s more like the EDR (endpoint detection and response) tools you are used to on laptops, desktops and servers:
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
