Re: Breaking MIME concatenation
Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig: > I have actually thought through this during a sleepless night, and I > believe that it could work as a quick and easy to implement *short term* > measure until the mail clients have fixed the HTML rendering. I do not think that HTML rendering could be fixed in a way that it would meet general security requirements. Mail clients rely on different rendering/browser engines that implement HTML/CSS as a living standard and with different features and interpretations of these standards. And probably none of these engines have been designed with security implications of tampered with HTML source code in mind. In my opinion this cannot be the basis for a secure mail client. A decrypted message part should never be embedded or displayed in other message parts of the same or any other message. And with embedded I mean embedded neither in raw nor parsed message parts (such as HTML DOMs). A decrypted message should always be displayed in its own secured sandbox. I'm quite sure that not following these rules will inevitably lead to doom. -- Just my 2 cents Alex ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On Fri 2018-05-18 05:31:36 +, Fiedler Roman wrote: > I see. If understood correctly, the trusted.gpg.d bypasses key > management with apt-key completely, so not running into problems with > apt-key deprecation. I'm actually advocating avoiding trusted.gpg.d entirely as well, and moving to explicit per-repo keyrings. So keep trusted.gpg and trusted.gpg.d completely empty, and populate /etc/apt/sources.list with lines like: deb [signed-by=/usr/share/keyrings/debian-archive-keyring.gpg] http://ftp.debian.org/debian buster main > I thought about that also, but shouldn't 99%+ of systems perform no > pinning whatsoever of packages to repositories? In that case, the > "wrong" repository could publish just a slightly increased package > version number of a package from another repository. You're asking the right questions. But please read https://wiki.debian.org/DebianRepository/UseThirdParty#Standard_pinning and the other sections on that page in more detail for the answers :) > Unless my system is misconfigured or other assumptions do not hold > true, that would imply, that the only security benefit from key > pinning is only about maintenance, making detection/pruning of stale > keys easier. Another benefit is that it is a necessary prerequisite if we want to be able to constrain some .debs (e.g. https://wiki.debian.org/UntrustedDebs and https://wiki.debian.org/Teams/Dpkg/Spec/DeclarativePackaging) based on their origin. This is still more work to be done, but if we can't isolate repos from one another than it'll never work. So please don't discount this work just because we haven't achieved all the rest of the isolation yet. The journey of a thousand miles begins with a single step, as they say. --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On Fri 2018-05-18 13:50:00 +, Whitey wrote: > Robert J. Hansen wrote: >> I don't have concrete numbers here, but my suspicion is that GnuPG is a >> package verification system that's useful for email... and most of the >> problems people have with it as a package verification system stem from >> the fact it was originally an email privacy system. > > Which might explain why some Linux distros are lax about updating GnuPG. > Ancient versions work o.k. for package verification. they won't be OK once the switch to ed25519 happens :/ --dkg ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
Robert J. Hansen wrote: > I don't have concrete numbers here, but my suspicion is that GnuPG is a > package verification system that's useful for email... and most of the > problems people have with it as a package verification system stem from > the fact it was originally an email privacy system. Which might explain why some Linux distros are lax about updating GnuPG. Ancient versions work o.k. for package verification. -- Whitey "To suppress free speech is a double wrong. It violates the rights of the hearer as well as those of the speaker." Frederick Douglass ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
Il 18/05/2018 07:31, Fiedler Roman ha scritto: > I thought about that also, but shouldn't 99%+ of systems perform no pinning > whatsoever of packages to repositories? In that case, the "wrong" repository > could publish just a slightly increased package version number of a package > from another repository. Unattended updates will apply it anyway and also for > users it would be hard noticing it: at least my "apt-get" version does not > show any information about the repository a package would be downloaded from > before confirming the installation. Thus the user would have to check each > single package manually by invoking "apt-cache policy [pkg-name]" or use > "apt-get download [packagelist]", check the logs and install packages with > "dpkg". Well, assume that who can publish to a repo you trust *is root* on your machine. Even if you could pin the package, what prevents him from adding a suid exe ? > Unless my system is misconfigured or other assumptions do not hold true, that > would imply, that the only security benefit from key pinning is only about > maintenance, making detection/pruning of stale keys easier. That's exactly what ther're for. BYtE, Diego ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
> Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > > On Thu 2018-05-17 15:37:55 +, Fiedler Roman wrote: > > Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > > > >> See sources.list(5) and > >> https://wiki.debian.org/DebianRepository/UseThirdParty for more details. > >> > >> See also https://bugs.debian.org/877012 for suggestions about > >> improvements to scoped cryptographic authorities for the default > >> installation of debian repositories. > > > > Thanks for the information. I thought, that the new model would be > > using "/etc/apt/trusted.gpg.d", as recommended by an online version of > > "apt-key". > > I recommend not relying directly on apt-key, whether online or offline :) I see. If understood correctly, the trusted.gpg.d bypasses key management with apt-key completely, so not running into problems with apt-key deprecation. > > But of course the per-repository pinning of keys could make key > > management easier as there is a n:1 link between repositories and > > keys, thus it is easier to avoid stale keys in the common key storage > > file. > > yes. furthermore, per-repository pinning of keys avoids the possibility > of one repository owner signing a Release file for a different > repository... I thought about that also, but shouldn't 99%+ of systems perform no pinning whatsoever of packages to repositories? In that case, the "wrong" repository could publish just a slightly increased package version number of a package from another repository. Unattended updates will apply it anyway and also for users it would be hard noticing it: at least my "apt-get" version does not show any information about the repository a package would be downloaded from before confirming the installation. Thus the user would have to check each single package manually by invoking "apt-cache policy [pkg-name]" or use "apt-get download [packagelist]", check the logs and install packages with "dpkg". Unless my system is misconfigured or other assumptions do not hold true, that would imply, that the only security benefit from key pinning is only about maintenance, making detection/pruning of stale keys easier. > ... LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 05/16/2018 08:59 PM, Werner Koch wrote: > On Thu, 17 May 2018 01:39, miri...@riseup.net said: > >> However, I get that many users expect HTML, embedded images and links. > > Well they expect a bit of markup like *bold* or _underlined_ or > /italics/ and links like https://gnupg.org but any decent MUA already > supports this for plain text mails. Proper GUI based MUAs also support > inline images (which are part of MIME); I used such MUAs already in in > the mid 90ies. > > I doubt that mail is the right thing to employ fancy CSS stuff, though. I usually just look at text. But this has moved me to look at source for some commercial messages. They're basically sending websites. Insane. >> So the best solution would be a tweak to GnuPG that breaks HTML and >> embedded remote content. That would protect against Efail, no matter how > > gpg will nver touch the payload. If MUAs want to sanitize HTML, I won't > have a problem with that. Upon reflection, I get that. So yes, in MUAs. But however implemented, the lesson here is that HTML and executable code in messages aren't compatible with gpg security. > Shalom-Salam, > >Werner > ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
given that the OS package verification use case is relevant for millions of server installations, i'm not convinced that Linux on the Desktop is really what rjh was referring to. --dkg dkg got it in one. Especially with the advent of cloud computing and one-click deployments of whole OSes, the package verification space is bigger than ever before. I don't have concrete numbers here, but my suspicion is that GnuPG is a package verification system that's useful for email... and most of the problems people have with it as a package verification system stem from the fact it was originally an email privacy system. This isn't a mark against it. Any good software package will soon get used for things far beyond the authors' original intent. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On Thu 2018-05-17 15:37:55 +, Fiedler Roman wrote: > Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > >> See sources.list(5) and >> https://wiki.debian.org/DebianRepository/UseThirdParty for more details. >> >> See also https://bugs.debian.org/877012 for suggestions about >> improvements to scoped cryptographic authorities for the default >> installation of debian repositories. > > Thanks for the information. I thought, that the new model would be > using "/etc/apt/trusted.gpg.d", as recommended by an online version of > "apt-key". I recommend not relying directly on apt-key, whether online or offline :) > But of course the per-repository pinning of keys could make key > management easier as there is a n:1 link between repositories and > keys, thus it is easier to avoid stale keys in the common key storage > file. yes. furthermore, per-repository pinning of keys avoids the possibility of one repository owner signing a Release file for a different repository. This paves the way for a local administrator to put meaningful constraints on a given external repository (e.g. pinning which packages can be shipped from that repo, or restricting maintainer scripts from running). I welcome any and all help in continuing to drive the ecosystem down this path. Regards, --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On Thu 2018-05-17 10:01:37 +0200, Werner Koch wrote: > On Thu, 17 May 2018 01:48, r...@sixdemonbag.org said: > >> While y'all are having this discussion, remember that GnuPG's 95% use >> case is verifying Linux packages, and that number isn't expected to >> change a whole lot. > > I am pretty sure that there are more Windows GPG users than users who > run Linux on their desktop. given that the OS package verification use case is relevant for millions of server installations, i'm not convinced that Linux on the Desktop is really what rjh was referring to. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
> Von: Daniel Kahn Gillmor [mailto:d...@fifthhorseman.net] > > On Thu 2018-05-17 08:45:18 +, Fiedler Roman wrote: > > As gnupg starts getting more and more problematic regarding some > > functions (see the discussions on command line/unattended use), Ubuntu > > Bionic AND Debian Buster dropped it from their debootstrap > > I don't know about Ubuntu Bionic, but for Debian Buster this is simply > false. > > Buster relies on gpgv (which is part of the GnuPG suite) for validating > archive signatures. That seems just a misunderstanding, as my initial message mentioning the changes was imprecise from my side, the follow-up https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060422.html should have made it clear, that we are both talking about the same thing. """Yes, but all those features do not apply to apt-key or are of little relevance. Hence gpg seems to have been included just for minimal use (just adding/removing keys, everything is trusted as performed by root user anyway). I do not know the reasons behind them dropping gpg, but I guess the just needed a failesafe, minimalistic tool for that purpose and now they dropped gpg and run only with gpgv to my knowledge.""" > > and replaced the apt-key management parts with own solutions. > > apt-key has been deprecated for a while now. I don't think i've seen a > secure use of apt-key that i can really encourage anywhere. > > If you want to do sane cryptographic controls on repositories, you > should (a) place the key for a given repo somewhere sensible in the > filesystem (e.g. /usr/share/keyrings/REPONAME-keyring.gpg), and (b) add > a Signed-By: line to your .sources file (or a signed-by option to the > line in your .list file). > > See sources.list(5) and > https://wiki.debian.org/DebianRepository/UseThirdParty for more details. > > See also https://bugs.debian.org/877012 for suggestions about > improvements to scoped cryptographic authorities for the default > installation of debian repositories. Thanks for the information. I thought, that the new model would be using "/etc/apt/trusted.gpg.d", as recommended by an online version of "apt-key". But of course the per-repository pinning of keys could make key management easier as there is a n:1 link between repositories and keys, thus it is easier to avoid stale keys in the common key storage file. > ... ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On Thu 2018-05-17 08:45:18 +, Fiedler Roman wrote: > As gnupg starts getting more and more problematic regarding some > functions (see the discussions on command line/unattended use), Ubuntu > Bionic AND Debian Buster dropped it from their debootstrap I don't know about Ubuntu Bionic, but for Debian Buster this is simply false. Buster relies on gpgv (which is part of the GnuPG suite) for validating archive signatures. > and replaced the apt-key management parts with own solutions. apt-key has been deprecated for a while now. I don't think i've seen a secure use of apt-key that i can really encourage anywhere. If you want to do sane cryptographic controls on repositories, you should (a) place the key for a given repo somewhere sensible in the filesystem (e.g. /usr/share/keyrings/REPONAME-keyring.gpg), and (b) add a Signed-By: line to your .sources file (or a signed-by option to the line in your .list file). See sources.list(5) and https://wiki.debian.org/DebianRepository/UseThirdParty for more details. See also https://bugs.debian.org/877012 for suggestions about improvements to scoped cryptographic authorities for the default installation of debian repositories. > Hence "apt-key import" will not work any more on debootstrap templates > (thus in containerized environments) because gnupg is in process of > removal from essential system parts. Again, this is simply not true. e-mail itself (let alone encrypted mail) is not an essential system part, but cryptographic software update verification *is* an essential system part, and debian continues to depend on gpgv for that purpose. --dkg signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Users GnuPG aims for? (Re: Breaking MIME concatenation)
-<| Quoting Andrew Gallagher , on Thursday, 2018-05-17 09:24:54 AM |>- > On 17/05/18 09:11, Bernhard Reiter wrote: > > I agree that technically HTML (with it extensions) is a bad format to serve > > this need. Similiar to PDF. One RTF was an approach Nextstep's mail took > > and that got some adoption, but not enough. Today it would be some very > > simple > > wiki markup language. > > Content-type: text/markdown ;-) Which allows embedding raw HTML: https://spec.commonmark.org/0.27/#html-blocks Best, Philipp signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 17/05/18 00:39, Mirimir wrote: > So the best solution would be a tweak to GnuPG that breaks HTML and > embedded remote content. I know I did suggest this earlier as a thought experiment, but MIME issues are obviously better implemented in the mail client itself, or in extremis in the secure mail plugin(s). And since this has already been implemented in at least one plugin (see Patrick's earlier messages) I think it's best to leave it on that side of the fence. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
Mirimir wrote: > So the best solution would be a tweak to GnuPG that breaks HTML and > embedded remote content. That would protect against Efail, no matter how > email clients were configured. It'd also protect against other exploits > that depend on fetching remote content. And it wouldn't require users to > entirely forgo HTML and embedded remote content. Just with GnuPG. I hope that's not a suggestion that gnupg should examine the data that it's decrypting, identify whether or not it is HTML, identify whether or not the HTML is well-formed and complete, and if not, append additional HTML to "complete" the incomplete HTML. Isn't that the same as tampering with the encrypted message? :-) And wouldn't it need to do this even in the absence of MDC failure? Admittedly, if there was MDC failure, the content has already been tampered with so what harm would a little more tampering do? :-) And by "protect against other exploits", what did you have in mind? Should gnupg try to identify PDF content, OLE objects in Office documents? How much file format knowledge will gnupg need to have stuffed into it to protect everyone from everything? :-) But I can't believe that such functionality belongs in gnupg. Certainly not when I'm decrypting database backups. I think it would make more sense if the email clients and addons that use gnupg to perform email decryption performed that addition themselves because they know to expect HTML content. It would make even more sense for email clients not to combine separate MIME parts naively into a single HTML document (I wonder how many emails that would break). It seems that nobody is expecting the email client/addon authors to make such changes but hopefully they will. Of course if gnupg could be changed in such a way that all email clients were fixed automatically that would be great/efficient. But I think the best thing gnupg can do is to suppress plaintext output on MDC failure (as already mentioned by many) assuming that that's even possible, but even that won't help with this MIME part rendering issue. cheers, raf ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On 05/17/2018 03:24 AM, Andrew Gallagher wrote: > On 17/05/18 09:11, Bernhard Reiter wrote: >> I agree that technically HTML (with it extensions) is a bad format to serve >> this need. Similiar to PDF. One RTF was an approach Nextstep's mail took >> and that got some adoption, but not enough. Today it would be some very >> simple >> wiki markup language. > > Content-type: text/markdown ;-) Wouldn't Markdown potentially suffer from the same types of problems? Or am I missing something? -- Shawn K. Quinn http://www.rantroulette.com http://www.skqrecordquest.com signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On 17/05/18 09:33, Werner Koch wrote: > and remember that mail is serious work and not for amusement. I think you're screaming into the wind there... ;-) More seriously though, properly marked-up text is demonstrably easier to read. That's why people submit academic papers in Latex instead of courier monospace with hand-drawn equations. At Patrick's suggestion I have moved to "Simple HTML" in my tbird, but even that requires noticeably more effort to scan and parse compared with "Original HTML" with disabled remote content. Featurism is absolutely a problem. But not all features are featurism. Simple markup (like the original markdown, not its increasingly featureful descendants) does make an important difference. The real trick is knowing where to draw the line. Turing-completeness in a document format is a fundamentally bad idea, but things like CSS that allow for hidden content can be problematic in certain contexts and not others. Like most things in security, "it depends". I completely understand where you're coming from, I'm a vim-loving unix beardie at heart too. But I don't think an insistence on text/plain asceticism is tenable in 2018. HTML mail is unfortunately going to be around for a long time. So mail clients (no more or less than web browsers) have a responsibility to sandbox untrusted content. Plaintext is a workaround, not a solution. -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
AW: Users GnuPG aims for? (Re: Breaking MIME concatenation)
> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von > > Am Mittwoch 16 Mai 2018 15:46:05 schrieb Martin: > > I think a fundamental discussion is necessary with the question: Who > > should / will use GnuPG in the future? > > Note that during one contract in 2016 we came up with some thoughts > in where GnuPG could be heading: > https://wiki.gnupg.org/EasyGpg2016/VisionAndStories > > > Two extremes: Only these people who need really to encrypt their > > emails because they are persecuted. But these people learned how to > > handle their email client correctly and these people will write > > text-only also in the future. > > The problem stays viewing email contents. No, there is much more to it and I have the feeling, that GnuPG development does not really account for that, thus loosing grounds. As an example, gnupg is also key management. As gnupg starts getting more and more problematic regarding some functions (see the discussions on command line/unattended use), Ubuntu Bionic AND Debian Buster dropped it from their debootstrap and replaced the apt-key management parts with own solutions. Hence "apt-key import" will not work any more on debootstrap templates (thus in containerized environments) because gnupg is in process of removal from essential system parts. Even for more limited use-cases, like e-mail decryption: Some use it for client side de/encryption procedures, others use it server side in encryption/decryption gateways. In my opinion gnupg development has a strong motion towards client-only use-cases, thus I started like Ubuntu/Debian to get rid of in all server side applications. I do that as sysadmin-self-defence, but I do not like it from an ethical aspect: good encryption tools should be basics for a free digital society. This is also the reason why I participate in the discussion. LG Roman ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On Thu, 17 May 2018 10:24, andr...@andrewg.com said: > Content-type: text/markdown ;-) Content-type: text/org-mode But we need to disable Babel processing. So better stick with Content-type: text/plain and remember that mail is serious work and not for amusement. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp4eFr7vqot5.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 16.05.18 21:50, Lukas Pitschl | GPGTools wrote: > >> Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig : >> >> Content-Type: mutlipart/mixed; boundary="WRAPPER" >> Content-Description: Efail protection wrapper >> >> --WRAPPER >> Content-Type: text/html >> >> >> >> >> >> --WRAPPER >> (result of PGP/MIME decryption) >> —WRAPPER— > > Looks alright so far, does the same work for inline PGP? Is there > a particular for the specific inline-styles? At least in Enigmail, inline-PGP is not affected by remote URL calls. The reason is that Enigmail reads the encrypted message data from the displayed message, and then replaces the displayed message content with the decrypted message. In other words, if the secretly to-be-decrypted message part is not displayed, then Enigmail won't come into action. > In macOS Mail we will disable remote content loading completely > and prevent the user from re-enabling it for encrypted messages. The same is currently being developed in Thunderbird (using the "Simple HTML" mode), together with a clean fix for the DOM tree issues. -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Users GnuPG aims for? (Re: Breaking MIME concatenation)
On 17/05/18 09:11, Bernhard Reiter wrote: > I agree that technically HTML (with it extensions) is a bad format to serve > this need. Similiar to PDF. One RTF was an approach Nextstep's mail took > and that got some adoption, but not enough. Today it would be some very simple > wiki markup language. Content-type: text/markdown ;-) -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On Thu, 17 May 2018 01:48, r...@sixdemonbag.org said: > While y'all are having this discussion, remember that GnuPG's 95% use > case is verifying Linux packages, and that number isn't expected to > change a whole lot. I am pretty sure that there are more Windows GPG users than users who run Linux on their desktop. Salam-Shalom, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgpwPggmntTZA.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Users GnuPG aims for? (Re: Breaking MIME concatenation)
Am Mittwoch 16 Mai 2018 15:46:05 schrieb Martin: > I think a fundamental discussion is necessary with the question: Who > should / will use GnuPG in the future? Note that during one contract in 2016 we came up with some thoughts in where GnuPG could be heading: https://wiki.gnupg.org/EasyGpg2016/VisionAndStories > Two extremes: Only these people who need really to encrypt their > emails because they are persecuted. But these people learned how to > handle their email client correctly and these people will write > text-only also in the future. The problem stays viewing email contents. > Or is Email encrypting a need for *every* email user? But there the > standard today IS that mails are HTML-written and contain links and > pictures and so on. If GnuPG should be a tool for "everybody" HTML > mail must be encrypted and decrypted correctly by the clients and > GnuPG should give any important information, Personally I believe that it is a need for users to have end-to-end encryption with email. And it is a legitimate need for users to have some markup and graphical layout. I agree that technically HTML (with it extensions) is a bad format to serve this need. Similiar to PDF. One RTF was an approach Nextstep's mail took and that got some adoption, but not enough. Today it would be some very simple wiki markup language. The technical and organisational difficulty is how to control backchannels and educate and support users to be able to make good decisions about their security and the implications and transported files. Best Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner signature.asc Description: This is a digitally signed message part. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On Thu, 17 May 2018 01:39, miri...@riseup.net said: > However, I get that many users expect HTML, embedded images and links. Well they expect a bit of markup like *bold* or _underlined_ or /italics/ and links like https://gnupg.org but any decent MUA already supports this for plain text mails. Proper GUI based MUAs also support inline images (which are part of MIME); I used such MUAs already in in the mid 90ies. I doubt that mail is the right thing to employ fancy CSS stuff, though. > So the best solution would be a tweak to GnuPG that breaks HTML and > embedded remote content. That would protect against Efail, no matter how gpg will nver touch the payload. If MUAs want to sanitize HTML, I won't have a problem with that. Shalom-Salam, Werner -- # Please read: Daniel Ellsberg - The Doomsday Machine # Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. pgp_IskXpacDs.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
> I think a fundamental discussion is necessary with the question: Who > should / will use GnuPG in the future? While y'all are having this discussion, remember that GnuPG's 95% use case is verifying Linux packages, and that number isn't expected to change a whole lot. Email users are important, but are also a very very small part of the ecosystem. Under 5% of the use, definitely; probably under 1%; I wouldn't be surprised if it was under 0.1%. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 05/16/2018 02:46 AM, Martin wrote: > Hi > > Am Dienstag, 15. Mai 2018, 22:19:17 schreiben Sie: > >> On 05/15/2018 04:44 AM, Patrick Brunschwig wrote: > >> > >>> I think the correct solution must be to treat each MIME part >>> independently, i.e. it needs to be parsed independently by the HTML >>> engine and produce its own DOM tree. At the end, you can concatenate >>> these DOM trees and create a single correct HTML document. >>> >>> -Patrick > >> So why use HTML with gnupg? > > I think a fundamental discussion is necessary with the question: Who > should / will use GnuPG in the future? > > Two extremes: Only these people who need really to encrypt their > emails because they are persecuted. But these people learned how to > handle their email client correctly and these people will write > text-only also in the future. > > Or is Email encrypting a need for *every* email user? But there the > standard today IS that mails are HTML-written and contain links and > pictures and so on. If GnuPG should be a tool for "everybody" HTML > mail must be encrypted and decrypted correctly by the clients and > GnuPG should give any important information, Yes, emails commonly contain HTML, embedded images and links. But Efail is by no means the only reason to avoid them. Tracking pixils. Malware dropping. I've avoided all that since the 90s. It's just good OPSEC. That is, this isn't really about GnuPG. It's about email OPSEC. However, I get that many users expect HTML, embedded images and links. So the best solution would be a tweak to GnuPG that breaks HTML and embedded remote content. That would protect against Efail, no matter how email clients were configured. It'd also protect against other exploits that depend on fetching remote content. And it wouldn't require users to entirely forgo HTML and embedded remote content. Just with GnuPG. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
> Am 16.05.2018 um 06:21 schrieb Patrick Brunschwig : > > Content-Type: mutlipart/mixed; boundary="WRAPPER" > Content-Description: Efail protection wrapper > > --WRAPPER > Content-Type: text/html > > > > > > --WRAPPER > (result of PGP/MIME decryption) > —WRAPPER— Looks alright so far, does the same work for inline PGP? Is there a particular for the specific inline-styles? In macOS Mail we will disable remote content loading completely and prevent the user from re-enabling it for encrypted messages. Unfortunately the chance that Apple will fix their mime parser is probably close to none. Currently also looking if it is possible to inject a separate web document. Best, Lukas signature.asc Description: Message signed with OpenPGP using GPGMail ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Am Dienstag, 15. Mai 2018, 22:19:17 schreiben Sie: > On 05/15/2018 04:44 AM, Patrick Brunschwig wrote: > >> I think the correct solution must be to treat each MIME part >> independently, i.e. it needs to be parsed independently by the HTML >> engine and produce its own DOM tree. At the end, you can concatenate >> these DOM trees and create a single correct HTML document. >> >> -Patrick > So why use HTML with gnupg? I think a fundamental discussion is necessary with the question: Who should / will use GnuPG in the future? Two extremes: Only these people who need really to encrypt their emails because they are persecuted. But these people learned how to handle their email client correctly and these people will write text-only also in the future. Or is Email encrypting a need for *every* email user? But there the standard today IS that mails are HTML-written and contain links and pictures and so on. If GnuPG should be a tool for "everybody" HTML mail must be encrypted and decrypted correctly by the clients and GnuPG should give any important information, - -- Regards Martin -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEE92uV/w2x7WB1p4XLsdyR185C444FAlr8NjoACgkQsdyR185C 4474IAf/VBxWlV8/r5QHblhK6wUVzZFflEJH1zrE25notn3F5SNp35hoF6JkbjNU sbej2HMAaGPaSn7zoFNs6npzw/1jR0/Y8o6jgRR2XfDjCMMhMrDvfiGceoOvDNoG FJfV5llksYKUYPXzxrxQLJ+m553MItZ2VfN0SXz4cLnH+cqEcXAt9dKHYdJPJjus CxmEDe0U+noYYn+Pr7i6Lx18OGDyPot6OGt1lJ9biQhTpfn0/WuyFkHaNSRFoe8Z LnLIjyvcKbb083nsYCQWlY59QR2Kz38ulzFajwGYx8fKXwFxSptpwEM8xbD0u/vh DlGPOnzX7W8wgzvn+2AyQ/hi9kVWPg== =Gbsn -END PGP SIGNATURE- ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On Tue, 15 May 2018 22:19, miri...@riseup.net said: > So why use HTML with gnupg? Even some of the journalist kicking that EFFective hype are using encrypted mails with HTML content. 's/ pgpaY0DPHbkw1.pgp Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
> On 16 May 2018, at 05:21, Patrick Brunschwig wrote: > > Content-Type: mutlipart/mixed; boundary="WRAPPER" > Content-Description: Efail protection wrapper > > --WRAPPER > Content-Type: text/html > > > > > > --WRAPPER > (result of PGP/MIME decryption) > --WRAPPER-- I like this. It handles the various quoting options, and does its best to display the cleartext safely. Tbird correctly disables JS, so we don’t need to worry about that. Should there be some indication that mischief is afoot? Or is it more important not to unnecessarily frighten the user? A ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 15.05.18 17:53, Lukas Pitschl | GPGTools wrote: > >> Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig : >> >> I already tried a while ago to trick the Thunderbird HTML rendering >> engine with tricks like this... They don't work. The rendering engine >> ignores the tag (and also tags like ). >> >> I think the correct solution must be to treat each MIME part >> independently, i.e. it needs to be parsed independently by the HTML >> engine and produce its own DOM tree. At the end, you can concatenate >> these DOM trees and create a single correct HTML document. > > I have also already tried to implement a similar fix for Apple Mail a few > days ago, > using which did work, but is probably a too naive attempt > to mitigate against these XSS-kind of attacks. > > So I absolutely concur with Patricks statement, that the Mime Parsers have > to be adjusted to treat every text/html part as single DOM tree or even use > different > web document instances to represent the message. I have actually thought through this during a sleepless night, and I believe that it could work as a quick and easy to implement *short term* measure until the mail clients have fixed the HTML rendering. If we embed the complete result that we get from gpg into the following wrapper, then we should be able to mitigate at least any known form of the attack when it comes to calling a remote URL during message reading: Content-Type: mutlipart/mixed; boundary="WRAPPER" Content-Description: Efail protection wrapper --WRAPPER Content-Type: text/html --WRAPPER (result of PGP/MIME decryption) --WRAPPER-- Does anyone see a major hole in this that I may have overseen? If not, then I think I'll implement this in Enigmail until Thunderbird has fixed this properly. -Patrick signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 05/15/2018 04:44 AM, Patrick Brunschwig wrote: > I think the correct solution must be to treat each MIME part > independently, i.e. it needs to be parsed independently by the HTML > engine and produce its own DOM tree. At the end, you can concatenate > these DOM trees and create a single correct HTML document. > > -Patrick So why use HTML with gnupg? For many years, by default I compose only text, view only text, display no inline images, and never fetch remote content. On the rare occasion that I've tested a fresh Thunderbird install, and accidentally composed HTML, Enigmail has always warned about the need to fold long lines. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
> Am 15.05.2018 um 17:44 schrieb Patrick Brunschwig : > > I already tried a while ago to trick the Thunderbird HTML rendering > engine with tricks like this... They don't work. The rendering engine > ignores the tag (and also tags like ). > > I think the correct solution must be to treat each MIME part > independently, i.e. it needs to be parsed independently by the HTML > engine and produce its own DOM tree. At the end, you can concatenate > these DOM trees and create a single correct HTML document. I have also already tried to implement a similar fix for Apple Mail a few days ago, using which did work, but is probably a too naive attempt to mitigate against these XSS-kind of attacks. So I absolutely concur with Patricks statement, that the Mime Parsers have to be adjusted to treat every text/html part as single DOM tree or even use different web document instances to represent the message. ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 15/05/18 16:44, Patrick Brunschwig wrote: > I already tried a while ago to trick the Thunderbird HTML rendering > engine with tricks like this... They don't work. The rendering engine > ignores the tag (and also tags like ). OK, that particular trick won't work. But if content injection is possible, then counter-injection should also be possible. How about: We don't need to worry about what comes after the injected tag close unless DOM scripting is enabled, and if it is enabled, we can abuse it just as easily as the bad guys can. :-) > I think the correct solution must be to treat each MIME part > independently, i.e. it needs to be parsed independently by the HTML > engine and produce its own DOM tree. At the end, you can concatenate > these DOM trees and create a single correct HTML document. Of course that would be the most correct solution. I was trying to see if I could think up the quickest solution. ;-) -- Andrew Gallagher signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Breaking MIME concatenation
On 15.05.18 16:59, Andrew Gallagher wrote: > It struck me at lunch that it might be possible for gnupg itself to > scupper the MIME concatenation (direct exfiltration) technique mentioned > in efail, and thereby plug the leaks in multiple vulnerable clients at > once. This would however require it to be naughty with its output. > > MIME concatenation works because in many clients the individual MIME > parts of a message are not kept isolated from each other after they are > passed to the rendering engine. Instead, they are concatenated together > into a single document, perhaps with some separator such as an hline. > This is dangerous because an HTML parser will interpret that document as > a single unit, breaking all sorts of same-origin hygiene. > > The primary technique for exfiltration is to wrap the target document in > an active HTML tag such as . But HTML requires the > quoted string to be safe, and there is no way for the efail attack to > perform input sanitation on the target document before the HTML parser > gets its hands on it. > > Bear with me, because this is *not* a fully thought-out plan, merely an > idea. ;-) > > So gnupg could (under circumstances likely to prevail inside a mail > client) prefix and/or suffix its output with an HTML content-injection > string specially designed to break out of whatever active element the > efail attack might be using. It could be as simple as prefacing the > output document with the perfectly valid HTML tag: > > I already tried a while ago to trick the Thunderbird HTML rendering engine with tricks like this... They don't work. The rendering engine ignores the tag (and also tags like ). I think the correct solution must be to treat each MIME part independently, i.e. it needs to be parsed independently by the HTML engine and produce its own DOM tree. At the end, you can concatenate these DOM trees and create a single correct HTML document. -Patrick -Patrick ___ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
