1 # SOME DESCRIPTIVE TITLE
2 # Copyright (C) YEAR Free Software Foundation, Inc.
3 # This file is distributed under the same license as the PACKAGE package.
4 # FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
9 "Project-Id-Version: PACKAGE VERSION\n"
10 "POT-Creation-Date: 2012-10-24 20:35+0300\n"
11 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
12 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
13 "Language-Team: LANGUAGE <LL@li.org>\n"
16 "Content-Type: text/plain; charset=UTF-8\n"
17 "Content-Transfer-Encoding: 8bit\n"
21 msgid "[[!meta title=\"FireGPG susceptible to devastating attacks\"]]\n"
26 msgid "**FireGPG is no more shipped in Tails.**\n"
30 msgid "You should instead use our custom GPG applet to:"
33 #. type: Bullet: ' - '
35 "[[Encrypt text with a passphrase|encryption_and_privacy/gpgapplet/"
36 "passphrase_encryption]]"
39 #. type: Bullet: ' - '
41 "[[Encrypt and sign text using public-key cryptography|encryption_and_privacy/"
42 "gpgapplet/public-key_cryptography]]"
45 #. type: Bullet: ' - '
47 "[[Decrypt and verify text|encryption_and_privacy/gpgapplet/decrypt_verify]]"
52 msgid "[[!toc levels=2]]\n"
62 "[FireGPG](http://getfiregpg.org/) is a Firefox addon that allows users to "
63 "easily perform cryptographic actions on the contents of HTML pages, e.g. to "
64 "verify signatures appearing as HTML text, or encrypt texts written inside "
65 "HTML text boxes (i.e. <textarea>). Webmail interfaces commonly use "
66 "text boxes for email composition, so FireGPG is a natural fit for this use "
67 "case: the user writes his or her email plaintext in the text box, selects "
68 "the plaintext and uses one of the \"Encrypt\" or \"Sign and encrypt\" "
69 "actions available from the FireGPG menu to transform the selection to its "
70 "encrypted counterpart."
75 "The FireGPG design incorrectly assumes that this is safe, but it is not, "
76 "since JavaScript running on the page can still control and observe much of "
77 "what is happening on the page. For instance, a simple script can set up a "
78 "timer that silently submits the contents of the text box back to the server "
79 "every second, thereby leaking the plaintext as it is written, effectively "
80 "bypassing any subsequent encryption. In fact, many non-malicious webmail "
81 "services do just that at longer intervals, to save a draft of a message in "
82 "case the user's browser crashes. The only way that a user can block this "
83 "type of attack is by completely disabling JavaScript, which is often not "
84 "desirable. In any case, FireGPG currently does nothing to make users aware "
85 "of this issue. To the contrary, by making encryption commands easily "
86 "accessible in the FireGPG context menu, it actively promotes this insecure "
92 "The situation is exactly the same if a user decrypts an OpenPGP block inside "
93 "a text box: the OpenPGP block is replaced with the plaintext within the text "
94 "box, so the same script can leak the plaintext when the timer fires less "
95 "than a second later. Luckily, webmail systems rarely present messages in "
96 "text boxes (although 'pastebins' often do). It is more common for received "
97 "email to be displayed as HTML text, and when the user decrypts it, FireGPG "
98 "will display the plaintext in a separate window that is safely out of reach "
99 "of JavaScript. FireGPG has an option, `extensions.firegpg."
100 "result_always_in_new_window`, called \"Always display encryption and "
101 "signature results in a separate window\" in the FireGPG options window, that "
102 "forces this behaviour when decrypting OpenPGP blocks in text boxes as well, "
103 "but it is disabled by default. This option, however, does not in any way "
104 "prevent leaking of plaintext while the user is writing it as described in "
105 "the previous paragraph."
110 "FireGPG also has three commands to sign (but not encrypt) messages: \"Sign"
111 "\", \"Wrapped sign\" and \"Clearsign\". Simple JavaScript can replace the "
112 "contents of the text box when the user selects it, so if the user does not "
113 "re-read the text after selecting one of the 'sign' commands, the attacker "
114 "will be able to obtain the user's signature on an arbitrary message. "
115 "Enabling the `result_always_in_new_window` option does not prevent this "
116 "attack; only user acuity *may* be able to detect and block it."
121 "It should be clear that the current FireGPG design of performing "
122 "cryptographic actions on the contents of text boxes is fundamentally flawed "
123 "and unsecurable. FireGPG's current design and interface is training users to "
124 "act as if the contents of text boxes are private until they are explicitly "
125 "submitted by the user (e.g. by pressing a \"Submit\"/\"Send\" button). Hence:"
128 #. type: Bullet: '1. '
130 "It is critical that all actions related to encryption and signing be removed "
131 "from the FireGPG menu. The only way to perform these actions should be "
132 "through the FireGPG Text editor, which is located in a separate window and "
133 "thus safely out of the reach of content JavaScript. The FireGPG Text editor "
134 "is already available through the FireGPG menu and makes all actions easily "
138 #. type: Bullet: '2. '
140 "FireGPG should explicitly state that the FireGPG Text editor is the only "
141 "safe place to write plaintext that are to be encrypted and/or signed, or to "
142 "decrypt messages unless the `result_always_in_new_window` option is enabled. "
143 "Hopefully this will save users that have been misled by FireGPG for years "
144 "from risking their data again, and make them understand why this new, less "
145 "convenient, mode of operation is necessary. Otherwise, they may continue "
146 "writing their plaintext in JavaScript-accessible text boxes, and then copy-"
147 "and-paste it into the FireGPG Text editor just to encrypt it, instead of "
148 "writing it there from the start."
151 #. type: Bullet: '3. '
153 "The `result_always_in_new_window` option should be removed -- its behaviour "
154 "should be forcibly enabled instead."
157 #. type: Bullet: '4. '
159 "The \"Verify\" command should display the contents of the signed message in "
160 "the FireGPG Text editor. Otherwise, it may be possible to present to the "
161 "user a different message from that seen by FireGPG."
166 "After these changes, the only remaining actions in the FireGPG menu will be "
167 "\"Decrypt\" and \"Verify\". \"Decrypt\" is made safe by change 3, and "
168 "\"Verify\" is made safe by change 4. It may still be a good idea to remove "
169 "these actions as well to further promote the use of the FireGPG Text editor "
170 "for all cryptographic actions. If they are removed, points 3 and 4 above "
171 "become irrelevant and may be ignored. Per a discussion on #tor-dev and "
172 "later #tails with rransom and katmagic it came to light that FireGPG may "
173 "have a few serious security and anonymity issues (katmagic even claimed with "
174 "\"85%\" certainty that these issues were among the main reasons FireGPG was "
180 msgid "Sample attack\n"
188 " \t\t<script type=\"text/javascript\">\n"
189 " \t\t\tfunction decrypt() {\n"
190 " \t\t\t\tvar elem = document.getElementById(\"pgp_msg\");\n"
196 " \t\t\t\tif (elem.innerHTML != elem.value) {\n"
197 " \t\t\t\t\telem.innerHTML = elem.value;\n"
198 " \t\t\t\t\talert(elem.value);\n"
201 " \t\t\twindow.setInterval(decrypt, 1000);\n"
210 " <textarea id=\"pgp_msg\" style=\"height: 600px; width: 600px\">\n"
211 " -----BEGIN PGP MESSAGE-----\n"
213 " -----END PGP MESSAGE-----\n"
221 "A similar approach should also work for stealing a plaintext written in a "
222 "text box before it's encrypted."
227 msgid "Other ressources\n"
230 #. type: Bullet: '- '
232 "[[tor-talk] Tor Browser Bundle: PGP encryption built-in?](http://www.mail-"
233 "archive.com/tor-talk@lists.torproject.org/msg02105.html)<br/> A thread on "
234 "the [tor-talk] list adressing the issues of supporting GPG inside a browser."
237 #. type: Bullet: '- '
239 "[Spoofing OpenPGP signatures against FireGPG](http://lair.fifthhorseman.net/"
240 "~dkg/firegpg-audit/spoof/)<br/> Another possible attack on FireGPG."
245 msgid "Other possible issues\n"
250 "If it is possible to use JavaScript to check signatures, an attacker could "
251 "potentially learn the user's whole key chain by replaying messages and their "
252 "signatures made by those key holders. This would give the attacker an awful "
253 "lot of identifying bits of the user."