Re: [tor-talk] Ideas to securely implement PGP encryption/decryption

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 2011-10-10, Fabio Pietrosanti (naif) <lists@xxxxxxxxxxxxxxx> wrote:
> Hi all,
>
> i understand all the doubt from Mike and Ransom about the possible
> exposure of user's security trough the exposure of functionality that
> can be "called by a remote web-application".
>
> This is an idea to mitigate most possible security issues:
>  * Put the encryption functionality into the hands of user actions
>  * Provide minimal interaction between Javascript/XUL functionalities
>
> Basically a user would like to encrypt/decrypt/sign:
>  - text form
>  - file uploaded/downloaded
>
> That kind of actions could be implemented like explicit actions that the
> user have to take.
> * Text form Encryption
>  - Right click on web/text form -> Encrypt/Decrypt

You missed the point of
https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ entirely.

From the first section title (in BIG letters) on that page: "Decrypted
text can be stolen though JavaScript"

And from the short paragraph right under the BIG box containing
katmagic's sample exploit code: "A similar approach should also work
for stealing a plaintext written in a text box before it's encrypted."

> * File Encryption
>  - Upload Box can provide an option (in the file browsing window) to Encrypt
>  - Download Box can detect if it's encrypted, and provide an option to
> Decrypt (in the file download box)

This sounds like a feature that someone who understands how to write
secure Firefox extensions might be able to implement safely.  Make
sure whoever implements it warns users that files' names will be sent
in the clear, because they will be sent in the clear (and/or exposed
to JavaScript).

> This would work without any server-side
> invocation/manipulation/whatsoever trough client-side code that could
> expose vulnerabilities.
>
> That way there will be a "user firewall" between the encryption
> functionality and the possible active content coming from the server
> mitigating the risks of possible XUL/XSS and other attacks coming from
> active-javascript calling XUL.

Asking the user for permission does not block many attacks, even if
the user understands the implications of granting permission to
perform a GPG operation.

> Also Key Management functionality could stay off protected by making a
> proper section (XUL) under Firefox options/menu that the user can use.

XUL is the reason Firefox has so many code-exec bugs.  It would be
easier and safer to ship one of the existing GPG key management GUIs
written using a real GUI toolkit.

> No code coming from the web would be allowed to interact with the
> plug-in but the end-user will still have all the encryption features
> under his power, usable in a modern web-based world.

No code coming from the web needs to interact with the GPG plugin in
order to grab the plaintext of a GPG message.

> What do you think?

I think you've found a feature (encryption of files to be uploaded)
which could be implemented securely, and which might actually be
useful to a few users.  I'm not convinced that feature is worth the
trouble of implementing and auditing a browser extension that would
provide it.


Robert Ransom
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk