FireGPG is no more shipped in Tails.

You should instead use our custom GPG applet to:

Advisory

FireGPG is a Firefox addon that allows users to easily perform cryptographic actions on the contents of HTML pages, e.g. to verify signatures appearing as HTML text, or encrypt texts written inside HTML text boxes (i.e. <textarea>). Webmail interfaces commonly use text boxes for email composition, so FireGPG is a natural fit for this use case: the user writes his or her email plaintext in the text box, selects the plaintext and uses one of the "Encrypt" or "Sign and encrypt" actions available from the FireGPG menu to transform the selection to its encrypted counterpart.

The FireGPG design incorrectly assumes that this is safe, but it is not, since JavaScript running on the page can still control and observe much of what is happening on the page. For instance, a simple script can set up a timer that silently submits the contents of the text box back to the server every second, thereby leaking the plaintext as it is written, effectively bypassing any subsequent encryption. In fact, many non-malicious webmail services do just that at longer intervals, to save a draft of a message in case the user's browser crashes. The only way that a user can block this type of attack is by completely disabling JavaScript, which is often not desirable. In any case, FireGPG currently does nothing to make users aware of this issue. To the contrary, by making encryption commands easily accessible in the FireGPG context menu, it actively promotes this insecure usage.

The situation is exactly the same if a user decrypts an OpenPGP block inside a text box: the OpenPGP block is replaced with the plaintext within the text box, so the same script can leak the plaintext when the timer fires less than a second later. Luckily, webmail systems rarely present messages in text boxes (although 'pastebins' often do). It is more common for received email to be displayed as HTML text, and when the user decrypts it, FireGPG will display the plaintext in a separate window that is safely out of reach of JavaScript. FireGPG has an option, extensions.firegpg.result_always_in_new_window, called "Always display encryption and signature results in a separate window" in the FireGPG options window, that forces this behaviour when decrypting OpenPGP blocks in text boxes as well, but it is disabled by default. This option, however, does not in any way prevent leaking of plaintext while the user is writing it as described in the previous paragraph.

FireGPG also has three commands to sign (but not encrypt) messages: "Sign", "Wrapped sign" and "Clearsign". Simple JavaScript can replace the contents of the text box when the user selects it, so if the user does not re-read the text after selecting one of the 'sign' commands, the attacker will be able to obtain the user's signature on an arbitrary message. Enabling the result_always_in_new_window option does not prevent this attack; only user acuity may be able to detect and block it.

It should be clear that the current FireGPG design of performing cryptographic actions on the contents of text boxes is fundamentally flawed and unsecurable. FireGPG's current design and interface is training users to act as if the contents of text boxes are private until they are explicitly submitted by the user (e.g. by pressing a "Submit"/"Send" button). Hence:

  1. It is critical that all actions related to encryption and signing be removed from the FireGPG menu. The only way to perform these actions should be through the FireGPG Text editor, which is located in a separate window and thus safely out of the reach of content JavaScript. The FireGPG Text editor is already available through the FireGPG menu and makes all actions easily accessible.
  2. FireGPG should explicitly state that the FireGPG Text editor is the only safe place to write plaintext that are to be encrypted and/or signed, or to decrypt messages unless the result_always_in_new_window option is enabled. Hopefully this will save users that have been misled by FireGPG for years from risking their data again, and make them understand why this new, less convenient, mode of operation is necessary. Otherwise, they may continue writing their plaintext in JavaScript-accessible text boxes, and then copy-and-paste it into the FireGPG Text editor just to encrypt it, instead of writing it there from the start.
  3. The result_always_in_new_window option should be removed -- its behaviour should be forcibly enabled instead.
  4. The "Verify" command should display the contents of the signed message in the FireGPG Text editor. Otherwise, it may be possible to present to the user a different message from that seen by FireGPG.

After these changes, the only remaining actions in the FireGPG menu will be "Decrypt" and "Verify". "Decrypt" is made safe by change 3, and "Verify" is made safe by change 4. It may still be a good idea to remove these actions as well to further promote the use of the FireGPG Text editor for all cryptographic actions. If they are removed, points 3 and 4 above become irrelevant and may be ignored. Per a discussion on #tor-dev and later #tails with rransom and katmagic it came to light that FireGPG may have a few serious security and anonymity issues (katmagic even claimed with "85%" certainty that these issues were among the main reasons FireGPG was discontinued):

Sample attack

<html>
    <head>
        <script type="text/javascript">
            function decrypt() {
                var elem = document.getElementById("pgp_msg");

                if (elem.innerHTML != elem.value) {
                    elem.innerHTML = elem.value;
                    alert(elem.value);
                }
            }
            window.setInterval(decrypt, 1000);
        </script>
    </head>

    <body>
<textarea id="pgp_msg" style="height: 600px; width: 600px">
-----BEGIN PGP MESSAGE-----
<snip>
-----END PGP MESSAGE-----
</textarea>
    </body>
</html>

A similar approach should also work for stealing a plaintext written in a text box before it's encrypted.

Other ressources

Other possible issues

If it is possible to use JavaScript to check signatures, an attacker could potentially learn the user's whole key chain by replaying messages and their signatures made by those key holders. This would give the attacker an awful lot of identifying bits of the user.