flaw in PGP plugins

[prehistoric]

You may have heard about this potential exploit for people using PGP to encrypt email.

The problem arises with plugins to common email clients which automatically decrypt encrypted email, not with the underlying implementation of the algorithms.

It doesn't affect me because I use text email clients rather than HTML, and don't depend on automatic decryption.

It will take time for common and convenient clients for HTML email to be secured. The full details will be released tomorrow, May 15, 2018. Separate encryption/decryption applications remain secure, so using an independent encryption program and sending an encrypted text as an attachment should be safe at present. In that case the email program never has access to the keys.

The only shocking thing here is the length of time the vulnerability has been out there, and the popularity of email clients which have failed to handle keys securely. Know anyone who uses Outlook or Thunderbird?

IT security regularly discovers that The Emperor Has No Clothes, and has not had any for many years.

[8Geee]

Well, a look-see at this does not help with reading email at the server. Encrypted mail sent to say Yahoo or Google still has 'encryption'. And from the Big W(ikipedia) I find that Signal has to have either an Andriod or iOS primary account.

That apparently goes for the desktop Linux version? Need help with that one.

Anyway, one DOES have to give out a valid phone number as opposed to email/pswd.

Next
8Geee

[prehistoric]

@8Geee,

Wait for the details to come out tomorrow. From what I've heard so far, I believe this is an error in key management in the email client/plugin interface. People forget that HTML is a programming language, so it is possible for an HTML email to exploit the API to decrypt things it should not be able to, including past messages stored on your machine. Unless it is able to retrieve private keys, this would not result in a compromise on the server transmitting email. It sounds like another compromise of email clients that run unknown HTML on your own machine.

[8Geee]

For now, it looks like the better defense would be to block pictures. I do this at Y-Mail (and have for a long time).

It helps alot if one goes to the mail-provider, and set this no picture behavior in the client also.

It might well be HTML we're up to "5" which gets layered ontop of JS... and then there's CSS.

Is it any wonder a webpage is 5Mb+ and the e-mail 1Mb.

Regards
8Geee

[prehistoric]

Here's the official explanation for the "efail" exploits, as promised.

As predicted above, it relies on HTML rendering in the same email client that performs the decryption. This only gets the plaintext into an untrusted process running on your machine. The next step is to "exfiltrate" the data to someplace else on the world-wide web. None of this is trivial.

An isolated teenage hacker is unlikely to work this out alone. On the other hand, a nation-state or a corporation with billions of dollars to gain really could use this to gain significant advantage.

If you use text emails to send ciphertext, and read them as plaintext in an offline application, you won't have this vulnerability. The problem centers on running untrusted code and having the private keys available to the same email client. At this point I don't see any mention of exfiltrating the private key, which would compromise any ciphertext messages an adversary had captured.

There are other implications, like a possible attack to retrieve private keys with known plaintext and corresponding ciphertext, but I am not current on that subject.

What I want to emphasize is that the effort that goes into securing major parts of the communication process does nothing for security at the endpoints, where encryption must be selectively broken if the communication is to be of use to the people intended. You may have a very secure HTTPS connection to Microsoft, Apple or Google, and they may have exemplary security during transit, but if security can be broken by adversaries at the origin or destination the entire business is still compromised.

[purple379]

After this problem is patched, I am supposing this problem with decrypting within email clients, a will morph in to another security hole.

So, which browser would one use to bring in PGP messages, with what Add Ons to have, and not to have?

[prehistoric]

@purple379,

I've told you my solution above. Use text email for security. Encrypt/decrypt in a separate application, so your email client does not have access to the keys.

Also, run your browser in a sandbox, so it doesn't have access to sensitive data. Anytime you run unknown code with access to the Internet you are depending on security that the web was never designed to have. Don't give it access to everything in your system.

My guess is that you probably don't have much need for highly secure communication, but if you do you can have it right now.

My bank keeps pushing me to use "convenient on-line banking". When I set up a local account to handle investments I told them what my minimum standards are. They couldn't meet these, so I told them to disable on-line transfers from the investment account, requiring that I come in in-person and present photo ID etc. to make one. The people in that branch all know me as a strange old bird. (See my avatar.)

Less than a month went by before I received a message about an adviser being available to consult with about "the breach". At this point I went back through my recent statements and discovered they had started offering the convenience of transfers via Zelle. Wrong company to use, Venmo has a safer system, though I worry about the social media aspect. Fortunately, this did not apply to that investment account, only checking.

So far, I have not been hit, but it is all too easy to discover you are vulnerable to decisions made by people you didn't even know you were doing business with. Your terms of service likely change every month. Companies are acquired by others every few years.

The real solution is one like the chip-enabled smart-card commonly used for credit card payments. I've been hit twice by skimmers when using the magnetic stripe on the card, and pay cash rather than use a terminal that can't handle the chip. It is damned hard to get the keys out of the chip, and hard for a machine to reveal information it never had.

There are solutions to the problem of logins and passwords. Here's one. This is so secure you should make careful plans for account recovery if you lose the token.

Until the rest of the world catches up, there is every reason to be paranoid.