Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
intrigeri: sajolida wrote (09 Jun 2015 14:57:28 GMT) : Ok, so your hypothesis is that there shouldn't be problems if exchanging emails between two operating system or applications that default to UTF-8. Did I understand correctly? That's right, this was my hypothesis. But dkg later explained that it still might cause security problems, even if in the ideal (non-adversarial) case, the text renders just fine. If we think this issue is dangerous or that PGP/inline should disappear from the cyberspace, then we might be better off stopping recommending Tails OpenPGP APllet as an option in the first place. It is apparently a bit dangerous, but for many people it's the only workable option so far, so I'm not in favour of removing it. I mean, we allow sending passwords over plaintext HTTP connections, even if that's dangerous. I'm fine with keep it. Note that the difference here is that we don't provide specific tools or have documentation pages about sending your passwords over HTTP in plaintext :) -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
intrigeri: tl;dr: I don't think we need an actual reproducer to document this widely known and understood problem. Yes, but it's better to understand how bad of a problem this is to document it reasonably and be most useful for people to decide what to do with that information. sajolida wrote (08 Jun 2015 13:42:43 GMT) : [...] I failed to reproduce the problem. I encrypted á ô ü in Tails OpenPGP Applet (both symmetrically and asymmetrically) and the result opened well in Tails OpenPGP Applet, on the `gpg` command line, and in Icedove. The first two results are fully expected if both the sending side and the receiving one are configured to use the same text encoding (and Tails uses UTF-8 both for desktop apps and on the command line). Ok, so your hypothesis is that there shouldn't be problems if exchanging emails between two operating system or applications that default to UTF-8. Did I understand correctly? Regarding the third result, just curious (feel free to disregard, as IMO it doesn't really matter, as explained below): how did you send the email that you later opened with Icedove? With Icedove too, or with another email client? Yes, I sent and received the armored ciphertext from Icedove in Tails. Anyway: the root cause of the problem is PGP/inline, and it's a real one (as explained in the thread that lead to this bug being filed IIRC, the sending MUA has no way to express what's the encoding of the cleartext, because it only sees the ciphertext that's encoded in US-ASCII). In some cases, and even possibly in the majority of cases, it works because the receiving MUA's assumptions are correct, but it cannot possibly *always* work because there's no robust way to correctly guess the encoding of a bytestring in all cases. If we think this issue is dangerous or that PGP/inline should disappear from the cyberspace, then we might be better off stopping recommending Tails OpenPGP APllet as an option in the first place. But I'm volunteer to investigate this further or take that decision. In the meantime, I'll propose the following changes to emmapeel: - I understand that this problem is true for both symmetric and asymetric encryption so it should rather go in doc/encryption_and_privacy/gpgapplet.warning. - Maybe mark this as a bug instead of a note. - Rephrase This method to send email (with OpenPGP encryption inline) to avoid the parenthesis and the word inline. What about Encrypting emails with Tails OpenPGP Applet instead? - Downsize the importance of the issue in term of frequency by replace might instead of can. - Use email instead of mail, and emails in plural. - Explain what are non-ASCII characters, maybe adding in parenthesis (for example non-Latin characters or characters with accents). - Make it more clear that this happening on the receivers side, somewhere around issues in mail clients. - Replace a [[mail client]] by an explicit reference to our mail client, Claws Mail (for the time being). - I would try to replace encoding with display and issues with problems, maybe problems in the display of characters or display problems or something like this... - Maybe turn around the sentence, use passive voice (yeah!) and try something like non-ASCII characters () might not display correctly to the recipients of the email. And sorry for the messy comments, but that took me longer than I wished... -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
sajolida wrote (09 Jun 2015 14:57:28 GMT) : Ok, so your hypothesis is that there shouldn't be problems if exchanging emails between two operating system or applications that default to UTF-8. Did I understand correctly? That's right, this was my hypothesis. But dkg later explained that it still might cause security problems, even if in the ideal (non-adversarial) case, the text renders just fine. If we think this issue is dangerous or that PGP/inline should disappear from the cyberspace, then we might be better off stopping recommending Tails OpenPGP APllet as an option in the first place. It is apparently a bit dangerous, but for many people it's the only workable option so far, so I'm not in favour of removing it. I mean, we allow sending passwords over plaintext HTTP connections, even if that's dangerous. Cheers, -- intrigeri ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
Hi, tl;dr: I don't think we need an actual reproducer to document this widely known and understood problem. sajolida wrote (08 Jun 2015 13:42:43 GMT) : [...] I failed to reproduce the problem. I encrypted á ô ü in Tails OpenPGP Applet (both symmetrically and asymmetrically) and the result opened well in Tails OpenPGP Applet, on the `gpg` command line, and in Icedove. The first two results are fully expected if both the sending side and the receiving one are configured to use the same text encoding (and Tails uses UTF-8 both for desktop apps and on the command line). Regarding the third result, just curious (feel free to disregard, as IMO it doesn't really matter, as explained below): how did you send the email that you later opened with Icedove? With Icedove too, or with another email client? Anyway: the root cause of the problem is PGP/inline, and it's a real one (as explained in the thread that lead to this bug being filed IIRC, the sending MUA has no way to express what's the encoding of the cleartext, because it only sees the ciphertext that's encoded in US-ASCII). In some cases, and even possibly in the majority of cases, it works because the receiving MUA's assumptions are correct, but it cannot possibly *always* work because there's no robust way to correctly guess the encoding of a bytestring in all cases. I'm wrong, I'm sure dkg will happily correct me :) Cheers! ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
emmapeel: another patch for the documentation, that could solve #9356: Warn that Tails OpenPGP Applet can lead to encoding problems for emails also on the newly reseted branch ta...@git.tails.boum.org:emmapeel/tails * [new branch] feature/9356-warn_openpgp_encoding please give me your suggestions! Thanks for working on this. While reviewing your patch I failed to reproduce the problem. I encrypted á ô ü in Tails OpenPGP Applet (both symmetrically and asymmetrically) and the result opened well in Tails OpenPGP Applet, on the `gpg` command line, and in Icedove. Could you try to reproduce the problem? And I'm very sorry, because I was the one to report it in the first place :P -- sajolida ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
Re: [Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
On Mon 2015-06-08 10:32:18 -0400, intrigeri wrote: Anyway: the root cause of the problem is PGP/inline, and it's a real one (as explained in the thread that lead to this bug being filed IIRC, the sending MUA has no way to express what's the encoding of the cleartext, because it only sees the ciphertext that's encoded in US-ASCII). In some cases, and even possibly in the majority of cases, it works because the receiving MUA's assumptions are correct, but it cannot possibly *always* work because there's no robust way to correctly guess the encoding of a bytestring in all cases. I'm wrong, I'm sure dkg will happily correct me :) Far from it, i was writing up this exact explanation when your message came in. Thanks for writing it :) Furthermore: It's not just about whether your peer's MUA is likely to guess right, and whether a message is *likely* to be interpreted correctly. You also have to evaluate the problem in an adversarial context. If this crucial piece of context (character encoding) is not cryptographically protected, it can be manipulated by an attacker. If the bytestream gets reinterpreted based on the attacker's modifications, what kinds of errors can result? About 30 minutes of fiddling around with malicious character encodings got me to the message tampering through header substitution example here: https://dkg.fifthhorseman.net/notes/inline-pgp-harmful/ It's not a world-shattering break, but it's clear that the context does need to be protected in order for messages to be safely transmitted. Inline PGP has no way to do that. --dkg ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
[Tails-dev] [review][website] #9356 warn about char encoding on OpenPGP
ey there, another patch for the documentation, that could solve #9356: Warn that Tails OpenPGP Applet can lead to encoding problems for emails also on the newly reseted branch ta...@git.tails.boum.org:emmapeel/tails * [new branch] feature/9356-warn_openpgp_encoding please give me your suggestions! From b3ad5371b79dd63a7c558edb4e6091873b3b2029 Mon Sep 17 00:00:00 2001 From: Debian Live user amnesia@localhost.localdomain Date: Sun, 7 Jun 2015 14:22:23 + Subject: [PATCH] first draft for #9356-End user docs --- .../gpgapplet/public-key_cryptography.mdwn |8 1 file changed, 8 insertions(+) diff --git a/wiki/src/doc/encryption_and_privacy/gpgapplet/public-key_cryptography.mdwn b/wiki/src/doc/encryption_and_privacy/gpgapplet/public-key_cryptography.mdwn index 88fec19..0e03f97 100644 --- a/wiki/src/doc/encryption_and_privacy/gpgapplet/public-key_cryptography.mdwn +++ b/wiki/src/doc/encryption_and_privacy/gpgapplet/public-key_cryptography.mdwn @@ -79,6 +79,14 @@ padlock, meaning that the clipboard contains encrypted text. [[!img browser_paste.png link=no alt=Encrypted text starting with -BEGIN PGP MESSAGE-]] +div class=note + +This method to send email (with OpenPGP encryption inline) can cause character +encoding issues in mail clients when using non-ASCII characters. + +If you are going to encrypt email often, we recommend you to set up a +[[mail client|doc/anonymous_internet/claws_mail/]] instead. +/div div class=tip -- 1.7.10.4 signature.asc Description: OpenPGP digital signature ___ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.
