61–70 of 306 posts
A lot of buzz for a not so critical vulnerability. Well it is critical but very hard to exploit because : 1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client. Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content. By the way I hate this kind of "buzz" disclosure. Just disclose full…
Curious, how?
Tangent: Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?
Earlier quoted context omitted.
As Let's Encrypt showed, this is all about usability.
Let's encrypt wouldn't be nearly as widely used if browsers didn't require https for a lot of new features people want to use, though. And Google will lower the ranking of non-https sites soon, if they haven't already. Having Let's encrypt available as a free option lets the browser makers force web services to use https, since "anyone can add it, it's free! (Never mind the increased complexity and even more things t…
From the original article: > EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails. I don't understand how this is being touted as vulnerabilities in OpenPGP and S/MIME. Sure there is undefined behavior in the OpenPGP and S/MIME standards but if implementations choose an insecure behavior for the undefined behavior, then it is a flaw i…
While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.
E-Mail needs better tools and better standards than GPG IMO. For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult. On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content b…
Error reporting in email clients that support OpenPGP is awful because they all work by some variant of exec-ing the GPG process and piping its input/output, so half the time you'll try to set up PGP and it just won't work. Even when it does work, no extant mail program has yet reached the level of having an actual UI/UX designer spend even a couple of months of work actually trying to make the PGP experience a good one - and why would they when no-one's prepared to pay for it? Security professionals are willing to work for free on things like security audits of the GPG code, because you can get a conference paper out of that, but there's no corresponding channel for usability work.
> Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own.
PGP/MIME already does this. We don't need a new standard. We need to get better at using the standard we have.
A lot of buzz for a not so critical vulnerability. Well it is critical but very hard to exploit because : 1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client. Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content. By the way I hate this kind of "buzz" disclosure. Just disclose full…
> I know I'm safe with blocked remote content. Curious, how?
Example : If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client.
Anyway, the attacker still need to get a hand on your encrypted email.
As if a brand name, logo and website were not enough, even the white paper title is cringy clickbait: "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels". OpenPGP is not broken. Nothing in your paper has anything to do with OpenPGP. This is simply spreading overblown FUD for your 15 minutes of mainstream media fame.
I don't even understand why they needed to tease the thing one day in advance with measures that were so weird that nobody knew what to expect. "Stop decrypting email", right, super convenient and totally appropriate given the actual vulnerability. Next time maybe they'll say "don't touch your mouse until further notice". What difference would it have made if they had simply published this website straight away? Seem…
This hardly seems like an OpenGPG or S/MIME vulnerability to me and more like an XSS-like exploit of email clients.
The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".
Earlier quoted context omitted.
Also relevant https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...
This seems to contradict the earlier claim that "the GnuPG team was not contacted by the researchers".
A few days later, they got an email asking for a phone call, which wasn't followed up upon--I'm not sure to what extent this is GnuPG's fault, whether this is a usual way of communicating a serious vulnerability. It would've been better if they called em back, definitely goes for both parties.
Then after a few months of silence, 2.5 weeks ago, they received another email with a different title that, according to Werner Koch, was too redacted to act upon:
On 2017-11-29 we got a short mail asking for a phone call. It might be
that I did not reply to that but in any case my office phone number is
easy to lookup. I did not get a phone call.
Since then we have not seen any more communication - not even about the
proposed coordinated public disclosure. Thus I closed this issue in
December and forgot about it.
On 2018-04-27 I received another paper via a Kmail developer which had a
different title than the one from November
*** DO NOT PUBLISH OR SHARE ON PUBLIC MAILING LISTS ***
Efail: Breaking S/MIME and OpenPGP Email Encryption using
Exfiltration Channels
and no author names etc. The GnuPG team discussed this but did not see
that any action was required. In particular because due to the
redaction we were not able to contact and help the developers of other
MUAs which might be affected.
It does seem to me that the security researchers were a bit too trigger-happy on the redacting of information, in particular unnecessarily so in private emails to the security folk they expected to act on the vulnerability.
I see how this can be used to exfiltrate an email you’ve sent to others, but th exploit doesn’t seem to show how to exfiltrate private emails between other parties. I mean, it’s an interesting bug, but since the only I can exfiltrate is the contents of plaintext I sent you in the same exploit then it doesn’t seem to leak anything other than any HTML email does. Am I missin something?
If I want to decrypt a message to you that I have intercepted I can create my own email containing a modification of the intercepted message and send it to you, causing you to send me the plaintext contents.