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 [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
