SoylentNews is people
SoylentNews
Ars Technica is reporting that there are
critical PGP and S/MIME bugs which can reveal encrypted e-mails. Their advice is to uninstall the plugins, for the time being. More information will be released tomorrow (Tuesday at 07:00 UTC, 3:00 AM EDT, midnight PDT).
Little is publicly known about the flaws at the moment. Both Schinzel and the EFF blog post said they will be disclosed late Monday night California time in a paper written by a team of European security researchers. Schinzel's Twitter messages used the hashtag #efail, a possible indication of the name the researchers have given to their exploit.
The EFF also published a warning, Attention PGP Users: New Vulnerabilities Require You To Take Action Now:
A group of European security researchers have released a warning about a set of vulnerabilities affecting users of PGP and S/MIME. EFF has been in communication with the research team, and can confirm that these vulnerabilities pose an immediate risk to those using these tools for email communication, including the potential exposure of the contents of past messages.
The full details will be published in a paper on Tuesday at 07:00 AM UTC (3:00 AM Eastern, midnight Pacific). In order to reduce the short-term risk, we and the researchers have agreed to warn the wider PGP user community in advance of its full publication.
The EFF also gives additional advice on disabling PGP in Thunderbird with Enigmail as well as other mail and mail-like clients.
takyon: The embargo is broken and the full details, including the paper (PDF), have been published.
(Score: 4, Insightful) by pvanhoof on Monday May 14 2018, @01:38PM (1 child)
Also see my other response.
> 1. This paper is misnamed.
Indeed
> 2. This attack targets buggy email clients.
Exactly
> 3. The authors made a list of buggy email clients.
Well said.
The MUA should not allow *any* utilization of HTTP when rendering a HTML E-mail. Any form of doing that is a serious mistake. Not only because of what is reported here, but also because that way *that* use of HTTP will allow spammers to identify when you open the E-mail. They use that to know if your E-mail adres is still alive.
Serious MUAs don't do this without user consent. Most HTML components even have a explicit offline mode exactly or that reason. Meaning that they won't automatically go online and fetch things like the src url of an IMG.
Any MUA that does this without user consent is completely and utterly wrong. Especially in a security sensitive context. This is something most MUA developers know about and if not, should know.
Disclaimer: I was once enslaved to work on a MUA too. The one for N9, N900, 810 and N800. Luckily Nokia paid me well to deal with fscking MIME being screwed over by E-mails created by a monopolist's MUA.
Anyway. From what I can tell: stop blaming OpenPGP and stop using a MUA written by morons. In security sensitive context you most likely want to disable HTML because the MUA developers will simply use a off the shelve HTML component. Which implies, basically, WebKit or whatever the OS comes with (which could be Internet Explorer or Edge's HTML components). You don't want to unleash all the bugs of the browser on the MUA when in a security sensitive context. Those nation state actors know about those bugs in the HTML components, of course.
(Score: 2) by FatPhil on Friday May 25 2018, @01:48PM
Hey - don't forget Columbus and Dali! (I was kernel team n900..lauta)
> The MUA should not allow *any* utilization of HTTP when rendering a HTML E-mail.
One problem with your no-HTTP-while-HTML-ing absolute, which I entirely agree with from a my-own-use-of-mail (dumb console clients only, somewhat predictably) is that embedding external content is kinda expected. Teh peoples want to link to a youtube vid and have the thumbnail/screenshot visually embedded in the mail, and the video playable in-place (or worse, auto-playing in place), all without having to jump though hoops grabbing a local (mime embedded) copy of the screenshot. This is alas a feature, and the easiest way of implementing it is to run off to a remote site at render time. Convenience is the enemy of security and privacy yet again.
The widest insideous HTTP-within-HTML tracking instance I've seen that everyone seems to think is just fine is when collaboration tools (Github/Jira/etc.) that send emails intended purely for internal viewing but which contain external gravatar img src's. Presumably only for unset geometric avatars, but still they are things that identify the individuals participating in a particular discussion - even if my client doesn't fetch these images, everyone else's clients will be fetching the image that corresponds to me.
Also another issue with email privacy is that if you're Nokia, don't pay Microsoft to handle *all* of your internal mail (even patches sent for review within our team in NRC ended up bouncing off an MS server in Amsterdam). The trojan horse story is deeper than just one man. It was a proper inside job!
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves