To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for he…
EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
31–40 of 306 posts
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#32From 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…
It's been mentioned by other comments here[0] that the team / group / individual(s) behind this paper didn't even contact the underlying development teams prior to publishing. The whole thing looks like they want to be able to say "yeah we uncovered xyz vulnerability" which they kind of could of, if they had just explained it's relevant to implementation and didn't attack the wrong projects in the process. There seems to be some level of unprofessional conduct[1] coming from the people writing the paper as well where they attack the projects on Twitter to try and silence them when their claims are refuted.
[0]: https://news.ycombinator.com/item?id=17064360
[1]: https://twitter.com/seecurity/status/995936859980222464
(Note: I'm reiterating / summarizing the findings of AnaniasAnanas from here.)
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#33While 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%.
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 that can fail and break things in weird ways)".
I suppose it'd be harder to do something similar with email.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#34If I understood correctly, I think this can be prevented by a single configuration change: "Do not automatically load inline content" but this is just speculation. I'd disable HTML rendering completely until everything becomes clearer.
Yes, I think that's the default pretty much everywhere for obvious reasons.
Of course some people configure exceptions for people in their address book, this could then be exploited by this issue.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#35To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for he…
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".
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#36From what I've read, I thought that in modern cryptographic methods you always authenticate and encrypt, in part to avoid attacks like this where an attacker can modify the encrypted message in some way. Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?
OpenPGP does have a way to authenticate the messages, see https://tools.ietf.org/html/rfc4880#section-5.13.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#37Earlier quoted context omitted.
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…
GPG is not a standard, the standard is OpenPGP. As for the tools, they seem very easy, especially engimail which IS 1-click setup. > add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own This is exactly what it is doing. PGP/MIME is a thing.
Enigmail is far from friction free and no 1-click setup. I still have to go through key generation last I checked. And then publish those keys or give them to friends.
If PGP/GPG wants adoption they need to eliminate those friction points, a TOFU model with automatic key redistribution should lower friction sufficiently but except TOFU there isn't much development in that direction.
>This is exactly what it is doing. PGP/MIME is a thing.
I don't think I ever received a single PGP/MIME email. I don't think a lot of people use PGP/MIME. It's a niche setting for a niche software.
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#38Huh, PGP encrypted messages aren't authenticated? (No HMAC etc)
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#39While 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%.
/Donns alufoil hat Google likes HTTPS, it makes the web safer, and keeps middle-boxes from interfering with their stuf. However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling. Gmail is essentially e-mail for a lot of people, so what they do matters.
“However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling.”
Absolutely. As mentioned in this¹ article:
“Though Google announced that it would stop using consumer Gmail content for ad personalization last July, the language permitting it to do so is still included in its current privacy policy, and it without a doubt still scans users emails for other purposes. Aaron Stein, a Google spokesperson, told NBC that Google also automatically extracts keyword data from users’ Gmail accounts, which is then fed into machine learning programs and other products within the Google family. Stein told NBC that Google also “may analyze [email] content to customize search results, better detect spam and malware,” a practice the company first announced back in 2012.”
――――――
¹ — https://theoutline.com/post/4524/remember-when-google-said-i...
Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME
#40While 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%.
The majority of email is encrypted in transit (https://transparencyreport.google.com/safer-email/overview?h...), so from a third-party-watching perspective it is equivalent to HTTPS.