[tor-talk] Tor Browser Bundle: PGP encryption built-in?

[Kyle L. Huff]

On 10/10/2011 01:07 PM, Mike Perry wrote:
> The problem with a browser extension is that the very thing that makes
> it useful is what makes it so risky. A GPG plugin of any kind becomes
> a vector for all sorts of nasty web attacks that would have normally
> been stopped by the server, such as XSS, XSRF, and various sorts of
> webbugs. On top of that, you need to protect against XUL XSS (which
> yields arbitrary code exec), as well as the privacy issues of
> leaking side-channels about the existence of certain keys in an
> otherwise anonymous browsing session.

The plug-in (basically, an API to GnuPG) should never be exposed to
anything other than the extension that provides it; there should be
a separation between the plug-in, and the web page. I spoke about
this in my prior email that I believe was forwarded to this list, as
I was not yet subscribed.

> I'm not sure exactly what the FireGPG author expects to gain my moving
> all of this stuff to NPAPI. A naive use of his NPAPI code could easily
> lead to an *increase* in the vulnerability surface, not a decrease.
> And that's even assuming he codes the NPAPI bits safely.

I was never the author of FireGPG, I was a contributor to a specific
module for FireGPG; My intention for moving to NPAPI is to make a
more portable browser interface to GnuPG (FireGPG used an IPC
library that was not portable to other browsers) that can be used
on any browser/email client that supports NPAPI.

A naive use of JS+XPCOM IPC library could equally (if not more so)
compromise a system if used incorrectly. This is true for anything.

Care must be given to these subjects regardless of the language/
tools used.

The source of my NPAPI plugin is freely available for anyone to
review, so you can see for yourself if I have coded the NPAPI bits
safely, and I gladly accept bug reports! =c )

> I think your first task is to find out exactly what this guy thinks he
> did wrong in JS+XPCOM, and why moving to a more complicated language
> like C++ will make it better, and not worse.

I didn't write FireGPG, but I will say the first place FireGPG went wrong
was when it directly queried users for their passphrase. This should
be delegated to the gpg-agent and in my opinion should never be
requested by the browser.

I would argue that C++ is less complicated than JS+XPCOM, but we
are getting into personal perception here...

> If he won't answer or won't tell you, stay the hell away from his
> code.

Agreed. Feel free to ask me questions regarding the plug-in code and
design decisions.

> I definitely agree that this doesn't make the idea not worth doing.
> Personally, I think it would be way easier and safer to devote the
> effort into securing Thunderbird for GPG and Tor so we could just
> bundle that, but I understand the benefits and appeal of having
> everything in the browser.

Technically, webpg-npapi should work with thunderbird, as I believe it
supports bundled NPAPI plug-ins.

> But man, tread with care. GPG-in-a-browser is like a minefield of
> killer beehives in a jungle filled with wild dogs. Oh yeah, and when
> the dogs bark, they shoot bees at you.

Too true!

Here is a link to the official source that I mentioned:
https://github.com/kylehuff/webpg-npapi

Please note; I am *not* advocating that my NPAPI plug-in be packaged
into a Firefox extension for use with Tor. I was asked by a Tor-talk
mailing-list user what I thought about the possibility of including it, and
I made my concerns known. I have no dog in this fight, use the module
or don't, it makes no difference to me. I will gladly assist in any changes
that are deemed necessary in order to make it more secure, but
otherwise I have nothing to do with it, so please don't misunderstand
my response as anything other than an attempt to answer questions.