A vulnerability was announced yesterday that affects both OpenPGP and S/MIME encrypted e-mails. While this was initially being passed off as an apocalyptic discovery, I don’t think that it’s scope is quite as bad as many are claiming. First, like all good modern vulnerabilities, it has a name, EFAIL, and a dedicated website:
The EFAIL attacks exploit vulnerabilities in the OpenPGP and S/MIME standards to reveal the plaintext of encrypted emails. In a nutshell, EFAIL abuses active content of HTML emails, for example externally loaded images or styles, to exfiltrate plaintext through requested URLs. To create these exfiltration channels, the attacker first needs access to the encrypted emails, for example, by eavesdropping on network traffic, compromising email accounts, email servers, backup systems or client computers. The emails could even have been collected years ago.
The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim’s email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
The weakness isn’t in the OpenPGP or S/MIME encryption algorithms themselves but in how mail clients interact with encrypted e-mails. If your e-mail client is configured to automatically decrypt encrypted e-mails and allows HTML content to be displayed, the encrypted potion of your e-mail could be exfiltrated by a malicious attacker.
I generally recommend against using e-mail for secure communications in any capacity. OpenPGP and S/MIME are bandages applied to an insecure protocol. Due to their nature as a bolted on feature added after the fact, they are unable to encrypt a lot of data in your e-mail (the only thing they can encrypt is the body). However, if you are going to use it, I generally recommend against allowing your client to automatically decrypt your encrypted e-mails. Instead at least require that your enter a password to decrypt your private key (this wouldn’t defend against this attack if your client is configured to display HTML e-mail content but it would prevent malicious e-mails from automatically exfiltrating encrypted content). Better yet, have your system setup in such a manner where you actually copy the encrypted contents of an e-mail into a separate decryption program, such as the OpenPGP command line tools, to view the secure contents. Finally, I would recommend disabling the ability to display HTML e-mails in your client if you are at all concerned about security.
If you perform the above practices, you can mitigate this attack… on your system. The real problem is, as always, other people’s systems. While you may perform the above practices, you can’t guarantee that everybody with whom you communicate will as well. If an attacker can exploit one party, they will generally get the e-mails sent by all parties. This is why I’d recommend using a communication tool that was designed to be secure from the beginning, such as Signal, over e-mail with OpenPGP or S/MIME. While tools like Signal aren’t bulletproof, they are designed to be secure by default, which makes them less susceptible to vulnerabilities created by an improper configuration.