Re: [tor-talk] Tor Flashproxy Badge as Firefox Extension
23.03.2013 19:31, Christian Sturm: Hello, [...] I might put the code on GitHub or so later. Please do that. https://addons.mozilla.org/de/firefox/addon/tor-flashproxy-badge/ You could make this available for Thunderbird as well. I modified the install.rdf and was able to add it and I assume it works, although I'm not seeing the badge. Maybe it's possible to change that easily. Thunderbird 18 has Websockets enabled. It should work with SeaMonkey as well. Regards, Sebastian G. (bastik_tor) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Help: Concurrently run TBB and an Obfs bridge from installed Tor; Win 7.
Hello, I want to help censored Tor users by running an obfsproxy bridge, but I (think I) also want to concurrently run TBB for my personal use. The reason I would rather not use the TBB as the obfsproxy bridge is I don't leave TBB open and running 24/7; unless starting/stopping the obfs bridge a few times per day isn't 'bad.' I don't know where to start because the Tor Project is very large and complex (at least to me). Here are a few questions I hope someone can/will answer, please forgive these if you think they're basic; I searched before I sent this e-mail, to no avail: 1. How the heck do I run an obfs bridge on Windows? (IIRC, I recall reading a very complex instruction page, I wonder if it's now easier to run an obs bridge on Windows) 2. Is it unhelpful to run an obfs bridge if it starts/stops a few times per day? 3. If the answer to 2 is yes, how can I concurrently run two Tors, on for the obfs bridge and one for my TBB? (I know how to do this on non-Windows, I'm hoping it easy to do on Windows) Thanks -- georgeofthejungle george_of_the_jun...@fastmail.fm ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] FlashProxy and HTTPS
I finally watched the recent FlashProxy talk, and the bit about Not working on HTTPS intrigued me. I looked into it, and had two initial ideas. == Mixed Content. This isn't great, but it's something that might work for now. Chrome and FF do not block an HTTP iframe on an HTTPS site. Chrome26 displays a different icon, and logs to console. Chrome Canary (28) did the same FF9.0.2 allows and has no indication IE9 blocks So putting the badge on a page in an iframe could allow a webmaster to deploy it on a HTTPS site. That frame would be on a different domain, to get protections via Same Origin Policy == Root Cert. This one is more than a bit crazy, but I don't believe in discounting crazy out of hand. Basically, if you accept that the TLS connection provides *no security whatsoever*, that is - it does not provide authenticity, and therefore should not be assumed to provide confidentiality - but you want to use it as an opportunistic layer (hey maybe this will help, it can't hurt), or to enable it working on HTTPS sites, or as an anti-fingerprinting tool (now they have to look at the handshake/certificate instead of te traffic) it becomes acceptable. Create a FlashProxy Root Cert, with a critical NameConstraint extension. The Name Constraint would be something like .entire-internet.flashproxy.com. Because it's Name Constrained, and critical, no client will accept a cert for a domain like paypal.com chaining to your root. IIRC the only desktop client that does not support NameConstraints is Safari - BUT because it's critical, Safari will outright reject the certificate. Mobile Clients should behave the same way. A group of CA's and Browser vendors are working to document the veracity of those claims, but I'm pretty confident in them because they recently, to great consternation of the IETF, said we're going to allow non-critical NameConstraint extensions, because if we don't, we'd break Safari. So you've got the root cert. Folks who want to run FlashProxies install it in their browser or OS. (The NameConstraints give them confidence you're not going to, nor can you, mess with them.) Now when a client wants to have a FlashProxy connect to them, they talk to the facilitator or another facilitator like system, and they receive a Root-CA signed cert for 127.0.0.1.entire-internet.flashproxy.com (substitute 127.0.0.1 for the client's actual IP) that's valid for a short window, say 30 minutes. Now, when the FlashProxy connects to the client, they do so using wss:// and receive the FlashProxy Root-signed certificate, and the browser lets the SSL handshake succeed. There's a lot of downsides here: - NameConstraints are not rock-solid in the sense that we've taken them for long test drives, but no one's subjected them to 20 years of continual use. When the value of the system attacked is greater than the cost, the attack happens. What's the cost for an attack on Name Constraints? We don't know. - It requires the FlashProxy user to install a root cert (e.g. do more than just open a webpage) - The requirements for the client - facilitator communication channel go up: it must now be bi-directional and support up to 1K of data or so. - The signing of certificates would introduce a DOS channel. This can be mitigated in some sense by rejecting requests for an IP if you've signed a cert for that IP in the last validity_window / 2, and preventing the IPfrom being spoofed (free if done over TCP, difficult otherwise) -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Stem Release 1.0
Hi all. After eighteen months of work and a number of delays rivaling that of the Big Dig I'm pleased to announce the initial release of stem! For those who aren't familiar with it, stem is a python controller library for tor. With it you can write scripts and applications that interact with your tor client or relay. For some examples of what you can do see the tutorials on... https://stem.torproject.org/ Stem is compatible with python 2.6 and higher (including the 3.x series), and is a near complete implementation of tor's control and directory specifications. It has relatively high test coverage (~80% for most modules) and integration tests to check its continued interoperability with new releases of tor. As always, if you encounter issues or have feature requests then please let me know! Also, if you write something that uses stem then please tell me, both so we can continue to improve our API and expand the tutorial's list of examples. Many thanks to everyone that helped make this initial release of stem possible, both with its development and packaging! -Damian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Stem Release 1.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31/03/13 05:03, Damian Johnson wrote: For those who aren't familiar with it, stem is a python controller library for tor. With it you can write scripts and applications that interact with your tor client or relay. For some examples of what you can do see the tutorials on... Oh, nice!. I am interested in some python projects myself. Do you know if there is something out there?. Particularly: 1. Python (local machine) proxy to access hidden services without installing TOR on the machine. 2. DNS resolution via TOR, without installing TOR. 3. Maybe, a Python proxy to create hidden services without installing TOR. This point could be detrimental to TOR ecosystem, nevertheless, since a server using TOR would be nice if giving back. I am interested in easing the entry barrier to access hidden services for regular unskilled users, and I am thinking about writing this proxy myself, but low level protocol details are available only on sourcecode :-?. In this particular situation, I care about hidden service anonymity, not client anonymity. - -- Jesús Cea Avión _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ Twitter: @jcea_/_/_/_/ _/_/_/_/_/ jabber / xmpp:j...@jabber.org _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQCVAwUBUVezxJlgi5GaxT1NAQKvygP+LrWyHd+hP5VghTDw5bsn+NRTpWfNY8wn nle7qQcZgTTP2nazYmcvB7w0iDH4Ll8ZwtkoAQ/N6KliEbjqZdMzhSmachwh3TOX KpcSowZyQzOqO/nquyCOS3q6APUa4QEQMMlVza11a/ZfLmpyGmmsqjUiDPaLrKGI HO2ZHeNL5MI= =nN9y -END PGP SIGNATURE- ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Stem Release 1.0
Awesome. Congrats on the 1.0 release. Literally just using this an hour ago. ROC On Sat, Mar 30, 2013 at 11:03 PM, Damian Johnson ata...@torproject.orgwrote: Hi all. After eighteen months of work and a number of delays rivaling that of the Big Dig I'm pleased to announce the initial release of stem! For those who aren't familiar with it, stem is a python controller library for tor. With it you can write scripts and applications that interact with your tor client or relay. For some examples of what you can do see the tutorials on... https://stem.torproject.org/ Stem is compatible with python 2.6 and higher (including the 3.x series), and is a near complete implementation of tor's control and directory specifications. It has relatively high test coverage (~80% for most modules) and integration tests to check its continued interoperability with new releases of tor. As always, if you encounter issues or have feature requests then please let me know! Also, if you write something that uses stem then please tell me, both so we can continue to improve our API and expand the tutorial's list of examples. Many thanks to everyone that helped make this initial release of stem possible, both with its development and packaging! -Damian ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] FlashProxy and HTTPS
I suggest you review how PKI works, and what TLS and SSL mean. On Sat, Mar 30, 2013 at 9:23 PM, Tom Ritter t...@ritter.vg wrote: I finally watched the recent FlashProxy talk, and the bit about Not working on HTTPS intrigued me. I looked into it, and had two initial ideas. == Mixed Content. This isn't great, but it's something that might work for now. Chrome and FF do not block an HTTP iframe on an HTTPS site. Chrome26 displays a different icon, and logs to console. Chrome Canary (28) did the same FF9.0.2 allows and has no indication IE9 blocks So putting the badge on a page in an iframe could allow a webmaster to deploy it on a HTTPS site. That frame would be on a different domain, to get protections via Same Origin Policy == Root Cert. This one is more than a bit crazy, but I don't believe in discounting crazy out of hand. Basically, if you accept that the TLS connection provides *no security whatsoever*, that is - it does not provide authenticity, and therefore should not be assumed to provide confidentiality - but you want to use it as an opportunistic layer (hey maybe this will help, it can't hurt), or to enable it working on HTTPS sites, or as an anti-fingerprinting tool (now they have to look at the handshake/certificate instead of te traffic) it becomes acceptable. Create a FlashProxy Root Cert, with a critical NameConstraint extension. The Name Constraint would be something like . entire-internet.flashproxy.com. Because it's Name Constrained, and critical, no client will accept a cert for a domain like paypal.com chaining to your root. IIRC the only desktop client that does not support NameConstraints is Safari - BUT because it's critical, Safari will outright reject the certificate. Mobile Clients should behave the same way. A group of CA's and Browser vendors are working to document the veracity of those claims, but I'm pretty confident in them because they recently, to great consternation of the IETF, said we're going to allow non-critical NameConstraint extensions, because if we don't, we'd break Safari. So you've got the root cert. Folks who want to run FlashProxies install it in their browser or OS. (The NameConstraints give them confidence you're not going to, nor can you, mess with them.) Now when a client wants to have a FlashProxy connect to them, they talk to the facilitator or another facilitator like system, and they receive a Root-CA signed cert for 127.0.0.1.entire-internet.flashproxy.com (substitute 127.0.0.1 for the client's actual IP) that's valid for a short window, say 30 minutes. Now, when the FlashProxy connects to the client, they do so using wss:// and receive the FlashProxy Root-signed certificate, and the browser lets the SSL handshake succeed. There's a lot of downsides here: - NameConstraints are not rock-solid in the sense that we've taken them for long test drives, but no one's subjected them to 20 years of continual use. When the value of the system attacked is greater than the cost, the attack happens. What's the cost for an attack on Name Constraints? We don't know. - It requires the FlashProxy user to install a root cert (e.g. do more than just open a webpage) - The requirements for the client - facilitator communication channel go up: it must now be bi-directional and support up to 1K of data or so. - The signing of certificates would introduce a DOS channel. This can be mitigated in some sense by rejecting requests for an IP if you've signed a cert for that IP in the last validity_window / 2, and preventing the IPfrom being spoofed (free if done over TCP, difficult otherwise) -tom ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Stem Release 1.0
1. Python (local machine) proxy to access hidden services without installing TOR on the machine. 2. DNS resolution via TOR, without installing TOR. 3. Maybe, a Python proxy to create hidden services without installing TOR. This point could be detrimental to TOR ecosystem, nevertheless, since a server using TOR would be nice if giving back. Hmm. Interacting with the tor network without a tor client would require re-implementing the protocol for behaving as a client. Definitely no simple task. :) ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
