[tor-talk] Tor Browser Bundle: PGP encryption built-in?
Hi all, is anyone evaluating whenever to include PGP encryption support into the default Tor Browser Bundle as a Firefox extension? I looked at the implementation and: * FireGPG it's discontinued http://getfiregpg.org/s/install It also seems it was using a bad design practice for the IPC communications between various modules. * NPAPI based GPG is just released (by old FirePGP contributor) https://github.com/kylehuff/webpg-npapi Having a support for GPG encryption into a generic browser, with PGP operations usable from Javascript/XUL, could open a lot of improvements and opportunities to secure Webmail and other web applications. At http://globaleaks.org we'll most probably need such kind of support into the browser and we're wondering if this could accomodate a standard requirement of the Tor Project for the Tor Browser Bundle. It would be also possible to easily make very simple XUL interfaces to handle basic PGP based file encryption operations, de-facto bundling a GPG client (with a Browser UI) into the TorBrowserBundle. What do you think about it? We're going to make some experiment in trying to build https://gitweb.torproject.org/torbrowser.git + GPG + https://github.com/kylehuff/webpg-npapi . -naif ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On 2011-10-10, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: is anyone evaluating whenever to include PGP encryption support into the default Tor Browser Bundle as a Firefox extension? No. I looked at the implementation and: * FireGPG it's discontinued http://getfiregpg.org/s/install It also seems it was using a bad design practice for the IPC communications between various modules. * NPAPI based GPG is just released (by old FirePGP contributor) https://github.com/kylehuff/webpg-npapi Having a support for GPG encryption into a generic browser, with PGP operations usable from Javascript/XUL, could open a lot of improvements and opportunities to secure Webmail and other web applications. No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but beware -- I'm sure katmagic and I missed a few dozen attacks. At http://globaleaks.org we'll most probably need such kind of support into the browser and we're wondering if this could accomodate a standard requirement of the Tor Project for the Tor Browser Bundle. No. It would be also possible to easily make very simple XUL interfaces to handle basic PGP based file encryption operations, de-facto bundling a GPG client (with a Browser UI) into the TorBrowserBundle. This sounds reasonable, except for the parts about the XUL interface and the browser-based UI. It also sounds rather like GPG4Win, except for those parts. What do you think about it? No. We're going to make some experiment in trying to build https://gitweb.torproject.org/torbrowser.git + GPG + https://github.com/kylehuff/webpg-npapi . Ugh. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On 10/10/2011 2:44 AM, Robert Ransom wrote: No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but beware -- I'm sure katmagic and I missed a few dozen attacks. You're correct - that is, the https site you link has an unsafe certificate, * per msg * in Firefox 7: tails.boum.org uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. (Error code: sec_error_untrusted_issuer) Anyone else seeing same security msg? ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On Oct 10, 2011, at 2:48 PM, Joe Btfsplk wrote: On 10/10/2011 2:44 AM, Robert Ransom wrote: No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but beware -- I'm sure katmagic and I missed a few dozen attacks. You're correct - that is, the https site you link has an unsafe certificate, * per msg * in Firefox 7: tails.boum.org uses an invalid security certificate. The certificate is not trusted because the issuer certificate is not trusted. (Error code: sec_error_untrusted_issuer) Anyone else seeing same security msg? Yes, the tails developers decided not to pay the SSL mafia and got a certificate from cacert instead. Your browser probably isn't configured to trust cacert, so you get the warning. Alternatively, someone is really trying to mitm you - tough to know. Anyway, the sha1 fingerprint of the tails website should be E1 5D 87 49 7F A1 21 75 8B 6B 1A 85 DC EF 70 E1 C6 7C 82 57. Now good luck deciding whether you should trust my claim in this unsigned email, or what. Enjoy the trip through the rabbit hole. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On 10/10/11 13:48, Joe Btfsplk wrote: tails.boum.org uses an invalid security certificate. Anyone else seeing same security msg? Well done, you've found the flaw in the PKI model. Julian -- 3072D/D2DE707D Julian Yon (2011 General Use) pgp.2...@jry.me signature.asc Description: OpenPGP digital signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] WSJ- Google- Sonic Mr. Applebaum
Here's how Google is a compliant slave. You still use Gmail?! http://online.wsj.com/article/SB10001424052970203476804576613284007315072.html#ixzz1aMoq8l2i -- http://www.fastmail.fm - The professional email service ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
On 10/10/11 9:44 AM, Robert Ransom wrote: On 2011-10-10, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: is anyone evaluating whenever to include PGP encryption support into the default Tor Browser Bundle as a Firefox extension? No. I actually think it would be a great idea to include PGP encryption support into the browser. I remember discussing this with Jake some time ago of maybe in the future having a bundle for Thunderbird and enigmail. I don't see why it it a bad idea to move one step closer into that direction by including PGP in the TBB. I looked at the implementation and: * FireGPG it's discontinued http://getfiregpg.org/s/install It also seems it was using a bad design practice for the IPC communications between various modules. * NPAPI based GPG is just released (by old FirePGP contributor) https://github.com/kylehuff/webpg-npapi Having a support for GPG encryption into a generic browser, with PGP operations usable from Javascript/XUL, could open a lot of improvements and opportunities to secure Webmail and other web applications. No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but beware -- I'm sure katmagic and I missed a few dozen attacks. Well that attack proposed there is pretty basic, I really think this is a useful idea and it should not be discarded with no thought. At http://globaleaks.org we'll most probably need such kind of support into the browser and we're wondering if this could accomodate a standard requirement of the Tor Project for the Tor Browser Bundle. No. I must also here disagree, but I think I am a bit biased . Anyways as I said, it would be of great use for people to be able to user PGP built into the browser, at least for sending encrypted email. It should not be implemented in a rush, but the gain that can be drawn from such a feature is not slim. Instead of having people download and install complicated software to send me and an encrypted message I can point them to the TBB and they are all set. Not at all a badi dea. It would be also possible to easily make very simple XUL interfaces to handle basic PGP based file encryption operations, de-facto bundling a GPG client (with a Browser UI) into the TorBrowserBundle. This sounds reasonable, except for the parts about the XUL interface and the browser-based UI. It also sounds rather like GPG4Win, except for those parts. What do you think about it? No. Robert, why do you have to be so negative? We're going to make some experiment in trying to build https://gitweb.torproject.org/torbrowser.git + GPG + https://github.com/kylehuff/webpg-npapi . Ugh. AAAaaarghhh! Robert Ransom - Art. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Comcast Residential - terms of service
I wanted to support the idea of free speech for people in repressed countries. However, shortly after installing TOR, Comcast threatened to force me to a business account (extra $12/month). So, I've killed my node. Still don't know if Comcast will force some penalty on me. I'd switch to another broadband provider - if there was one. (around here, DSL is too slow to be counted as broadband) Has anyone considered an option to drop client connections from the United States? Better yet, maybe we could just drop client connections from Comcast Support addresses grin. (It's beginning to sound like the United States is a repressed country. Freedom of Speech is only for those who can afford it.) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Fwd: Tor Browser Bundle: PGP encryption built-in?
On 10/10/11 6:44 PM, Kyle L. Huff wrote:
Another, more narrow approach would be to enforce within the plug-in
that the URL of the page that the plug-in is embedded on must match the
extension path. For example, the plug-in could detect if it was loaded
on a page with the URL containing
chrome://.../{webpg-firefox-extension-path}/plugins/..., and refuse to
load otherwise.
I would like to summarize that idea with some considerations:
Webpg-npani is not FireGPG
* FireGPG is discontinued and it's ok if it has security
* WebPG-npapi is an active project
* WebPG hackers would be happy to work with Tor Project on integration
Security Improvements
* Several security measures are already in development
* Security could be always improved to satisfy various level of paranoy
* Tor Community it's plenty of truly certified paranoid hackers(c)
and can work all together to define security requirements
* Data encryption is today only for power users
* Improve usability of end-to-end Encryption tools bringing it to the
masses:
* Users are dumb
* The users noways use a browser
* Javascript encryption exists but have several drawbacks
* Data encryption to be used by the user have to stay into the browser
* A Browser PGP support is an enabling tool for encryption diffusion
Many different use-cases could be later implemented by a community.
* Webmail plug-in for end-to-end GPG encryption
* File upload of TorBrowserBundle could always provide an option to
encrypted the uploaded file regardless of the web application used
* With PGP based on Public Key
* With a PGP based symmetric password
* File download of TorBrowserBundle could always allow decryption data
* Simple plug-in could born to use the facility to encrypt text form
on social networks (vecna was working on a general tool to do data)
* Other for sure would come
What do you think about it?
-naif
___
tor-talk mailing list
tor-talk@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Ideas to securely implement PGP encryption/decryption
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 * 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 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. Also Key Management functionality could stay off protected by making a proper section (XUL) under Firefox options/menu that the user can use. 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. What do you think? -naif ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor Browser Bundle: Usability Improvement Proposal (windows)
Hi all, i would like to propose some usability improvement for TorBrowserBundle for Windows, in order to make it more usable. Reduce to 3-clicks the requirements to use TorBrowserBundle on Windows. Today the Tor Browser Bundle require the user to make several action before using it that can represent a stopping-issue for unskilled and uncertain users. Especially the user require to: - dealing with the concept of extraction Really dumb users doesn't know what file compression is, some doesn't even know what file size. - dealing with a decision of where to extract. That relate to interacting with the system and a really dumb users fear doing actions for which he don't know the consequence. In doing this the user have to do several clicks and choices. There are a lot of users that are not even able to install firefox. They fear to damage the computer in doing some actions for which they don't know the consequence. I'd like to propose a new simplified way of using TorBrowserBundle as follow: - User Download the software - User click on TorBrowserBundle.exe - A nice splashscreen show to the user - A progress bar (below the splashscreen) inform the user that Tor it's initialing - Extracting to TorBrowserBundle Directory ...OK - Starting Tor...OK - Initialing Tor Connection... OK - Starting Firefox... OK - Then the browser show up to the user. - The browser show at first page : - useful information about Tor - inform the user about the newly created directory - include the default CheckTor page By using that approach the user will not have the feeling of no technical decision has to be taken by the user in order to use Tor, no stopping-fear of breaking something, no compression/extraction concept to be understood. The user the next time that want to use TorBrowserBundle will not need to enter into the Installation Directory but will always be able to start the software from the same file he downloaded That way it would really be a 3-clicks step for the user to use Tor Browser Bundle: - Click on download link - Accept download - Start the software What do you think? -naif ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: PGP encryption built-in?
Thus spake Arturo Filastò (a...@globaleaks.org): I actually think it would be a great idea to include PGP encryption support into the browser. I remember discussing this with Jake some time ago of maybe in the future having a bundle for Thunderbird and enigmail. I don't see why it it a bad idea to move one step closer into that direction by including PGP in the TBB. I think the enigmail vulnerability surface is way more manageable than an arbitrary webby one, though perhaps less useful. It also seems it was using a bad design practice for the IPC communications between various modules. * NPAPI based GPG is just released (by old FirePGP contributor) https://github.com/kylehuff/webpg-npapi Having a support for GPG encryption into a generic browser, with PGP operations usable from Javascript/XUL, could open a lot of improvements and opportunities to secure Webmail and other web applications. No. See https://tails.boum.org/bugs/FireGPG_may_be_unsafe/ , but beware -- I'm sure katmagic and I missed a few dozen attacks. Well that attack proposed there is pretty basic, I really think this is a useful idea and it should not be discarded with no thought. 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. 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 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. If he won't answer or won't tell you, stay the hell away from his code. What do you think about it? No. Robert, why do you have to be so negative? I think Robert is negative because the idea just sets off all sorts of warning bells. 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. 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. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgptMR1FujzP6.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On Mon, Oct 10, 2011 at 07:07:35PM +0200, Jeroen Massar wrote: On 2011-10-10 18:42 , Andre Risling wrote: Here's how Google is a compliant slave. You still use Gmail?! Does not matter what service you use, they all fail under the pressure Use your own servers at the co-lo. Use TPM and tamper-proof systems. I used to store crypto secrets on USB smartcards, and have streaming video in the rack, all on UPS. Nowadays, it's even easier. No point to make it too easy. Mallory should earn his keep. of organizations that want access to it, be that legal or illegal. (The bigger problem with the context of the article is the 1984'ish behavior of an apparent legal entity). As long as you make sure you properly encrypt your messages (PGP or if it is available for your medium OTR; and don't let your keys fall in the wrong hands, but then again rubberhose anyone?) and use Tor to access the service so that figureing out which IP you came from is useless as it is an exit, you should be pretty fine. PGP + email's prime weakness is the fact that the from/to/subject are passed in the clear and that rubberhosing you or planting a bug on your person/computer yields those precautions futile. Then again, it also depends on what your adversary is and what you are trying to protect, note also that not everybody has just one single email address. -- Eugen* Leitl a href=http://leitl.org;leitl/a http://leitl.org __ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Fwd: Tor Browser Bundle: PGP encryption built-in?
On 2011-10-10, Fabio Pietrosanti (naif) li...@infosecurity.ch wrote: Hi Kyle and Aaron, let me answer to you by making in Cc the tor-talk mailing lists where there is an on-going discussion about it. It has been suggested that FireGPG is unsafe (https://tails.boum.org/bugs/FireGPG_may_be_unsafe/), your approach by design sounds very nice. You seem to have missed the point of that page -- the problem with FireGPG is what it allows, not how it was implemented. I am wondering whether it would be possible to add another simple security mechanism so that the user is alerted anytime a GPG related operation is going to be executed. Something like: The website blahblah.com would like to use PGP to [encrypt|sign|cipher] web-data, do you want to allow it? Ransom, what do you think about Kyle and Aaron approach? (Eventually including a pre-warning for any sensitive operation to the end-user)? A warning before JavaScript enumerates your keyring isn't sufficient. Users must, at a minimum, be able to block all further attempts by a page or website to use GPG features. And even that won't help most users -- a request-for-permission dialog can only protect users who read messages before clicking 'Allow', and who understand that allowing a website to use a GPG plugin is dangerous. By embedding a GPG support into TorBrowserbundle, the Tor Project would eventually provide a Trusted PGP Key lookup server on a Tor Hidden Service that forward the PGP key lookup to public internet key servers. No we wouldn't. I mean, today everything goes over HTTP, but our browsers are capable of doing end-to-end encryption only by using Javascript. Why not try to enable the best of Anonimity (Tor) + best of Web Browsing (Firefox) with best of encryption (GPG) ? I don't consider Firefox the 'best of Web Browsing' or GPG the 'best of encryption'. They are only the crap tools we're stuck with for now. Robert Ransom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: Usability Improvement Proposal (windows)
On 10/10/11 11:01 PM, Julian Yon wrote: On 10/10/11 20:54, Fabio Pietrosanti (naif) wrote: Really dumb users You can make things too simple. Tor is not a silver bullet. A user who is so dumb (as you put it) as to not be able to install a simple piece of software will almost certainly be a liability to themselves. Unfortunately, where anonymity is concerned, thinking isn't optional. Yes,but please consider that TorBrowserBundle/OSX already required only 3 clicks from download to start: - Clikc+Download automatically Safari does it automatically placing the file in Downloads directory. - Drag TorBrowserBundle app to Application - Start application You should think to reduce the entrance barrier to as many person as possible, there are context where anonimity it's just something that someone else you trusted referred to you. -naif ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] WSJ- Google- Sonic Mr. Applebaum
On 2011-10-10 22:27 , Eugen Leitl wrote: On Mon, Oct 10, 2011 at 07:07:35PM +0200, Jeroen Massar wrote: On 2011-10-10 18:42 , Andre Risling wrote: Here's how Google is a compliant slave. You still use Gmail?! Does not matter what service you use, they all fail under the pressure Use your own servers at the co-lo. Use TPM and tamper-proof systems. Does not matter, given enough power/money/force your adversary can walk into that colo and use vampire taps to replug (both power and network) your box without you noticing anything and monitor the rest from there on. As for TPM, who build that piece of hardware and are you sure that a copy of your keys are not kept elsewhere? I used to store crypto secrets on USB smartcards, and have streaming video in the rack, all on UPS. Nowadays, it's even easier. No point to make it too easy. Mallory should earn his keep. At one point or another they just apply rubberhose crypto thus don't make it too difficult. Greets, Jeroen ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: Usability Improvement Proposal (windows)
On 10/10/11 22:18, Fabio Pietrosanti (naif) wrote: Yes,but please consider that TorBrowserBundle/OSX already required only 3 clicks from download to start: So? That's just how you install stuff on OSX. It makes no difference to my point. A naïve user who thinks they're anonymous but actually isn't (because they lack understanding) is in a more dangerous position than they were before. I'd go so far as to say it's irresponsible to deliberately put people in that position. You should think to reduce the entrance barrier to as many person as possible, there are context where anonimity it's just something that someone else you trusted referred to you. I'm nothing to do with the Tor project. Just an experienced developer who happens to also be a Tor user. Julian -- 3072D/D2DE707D Julian Yon (2011 General Use) pgp.2...@jry.me signature.asc Description: OpenPGP digital signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Ideas to securely implement PGP encryption/decryption
On 10.10.2011 22:29, Fabio Pietrosanti (naif) wrote: 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. The problem Robert and katmagic are referring to (read access to the DOM) can only be mitigated by disabling active scripting on the pages where GPG is used. The plugin probably would have to notify the user, then disable all scripting and reload the page, before executing GPG functionality. This does not help against the read plaintext before encryption attack, obviously. At the moment, I cannot think of any attack vectors once you combine it with enabled Torbutton (or a stripped down Tor Browser) where active scripting/access to the DOM is disabled completely. -- Moritz Bartl https://www.torservers.net/ ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Browser Bundle: Usability Improvement Proposal (windows)
On Mon, Oct 10, 2011 at 09:54:50PM +0200, li...@infosecurity.ch wrote 2.2K bytes in 64 lines about: : By using that approach the user will not have the feeling of no : technical decision has to be taken by the user in order to use Tor, no : stopping-fear of breaking something, no compression/extraction concept : to be understood. : : The user the next time that want to use TorBrowserBundle will not need : to enter into the Installation Directory but will always be able to : start the software from the same file he downloaded What happens in between runs? Does the extracted directory get wiped? I can see the value in this approach, in any case. Whether we like it or not, less sophisticated users are using Tor. We'll fail to protect all of them, but this doesn't mean we cannot try to guide their path towards a safer online experience with Tor. Between renaming Aurora to something more obvious, to a single executable/binary that hides the complexities of Tor from the user, these are some of the first steps towards a 'tor product for the masses'. Another approach is like that of Janusvm, where they put everything into a stripped down virtual machine, and allow all sorts of plugins, etc inside the VM. -- Andrew pgp key: 0x74ED336B ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Ideas to securely implement PGP encryption/decryption
Thus spake Moritz Bartl (mor...@torservers.net): On 10.10.2011 22:29, Fabio Pietrosanti (naif) wrote: 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. The problem Robert and katmagic are referring to (read access to the DOM) can only be mitigated by disabling active scripting on the pages where GPG is used. The plugin probably would have to notify the user, then disable all scripting and reload the page, before executing GPG functionality. This does not help against the read plaintext before encryption attack, obviously. At the moment, I cannot think of any attack vectors once you combine it with enabled Torbutton (or a stripped down Tor Browser) where active scripting/access to the DOM is disabled completely. Actually, these attacks are generally prohibited by strong isolation between the content script and the XUL script. In XUL, you can read the ciphertext, extract it, decrypt it, and display it in a protected XUL window without introducing risk, IF all steps are done properly. There are some subtleties here involving special priviledge isolation wrappers (via XPCSafeJSObjectWrapper and others), but there is no fundamental reason that it is impossible. Just complicated and tricky, in either NPAPI and XPCOM (but probably worse with NPAPI, because you won't get the priviledge isolation wrappers for free like XPCOM). The one exception is deception: One could imagine all manner of clickjacking-esque games that could be designed by malicious javascript to capture context clicks or mouseovers to create a fake password menu. Authentication and decryption UI should be designed to exist primarily outside of the content area for this reason. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpJsDrjloVcI.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Ideas to securely implement PGP encryption/decryption
I more or less give this plan my stamp of approval. Just mind the gaps, and careful with NPAPI! I am able to review and advise XUL+XPCOM code for security.. But for NPAPI, we'll need someone else. Anyone on-list have any expertise with processing untrusted DOM data in NPAPI, and then rendering output safely in browser windows? Sounds like a minefield to me, but perhaps it's safer and easier than I expect? Thus spake Fabio Pietrosanti (naif) (li...@infosecurity.ch): 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 * 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 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. Also Key Management functionality could stay off protected by making a proper section (XUL) under Firefox options/menu that the user can use. 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. What do you think? -naif ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpXOPAz9R0s2.pgp Description: PGP signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
