[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
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.
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk