Re: [tor-dev] Tor Cloud - Issues/Maintainer/Next Steps
Sorry I forgot to mention the ticket itself: https://trac.torproject.org/projects/tor/ticket/11502 --SiNA On 2014-04-20 17:01, Andrew Lewman wrote: On Sun, Apr 20, 2014 at 06:54:54AM -0700, s...@redteam.net wrote 0.6K bytes in 0 lines about: : I have created a ticket for Tor Cloud, I think I need access to the Which ticket number? -- "be the change we wish to see in the world." Gandhi ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Python Only Tor Client?
>> Hi all, >> >> does anyone know of any work to make a Python Only Tor Client, that just >> enable to expose a Tor Hidden Service? >> >> It would be very cool if it would be possible to avoid "Tor binary" as a >> dependency for Globaleaks, making it pure Python application code. >> >> The questions are: >> >> - Are there projects that foresee to do something like that? >> >> - From a Tor Project perspective, does it make sense? >> >> - From a Security perspective, are there strong security implications in >> doing so? >> > > I think it makes sense - the effort will be similar to Orchid which is > written in pure Java. It is a great deal of work. If someone were to > serious consider this effort - I think they should probably talk > extensively with Nick, Roger, Andrea and probably also Bruce (who > wrote Orchid) as they're probably the four most qualified people to > make suggestions. > > All the best, > Jacob If such a project ever got going then I'd be interested in helping out. Stem already provides a python implementation of many Tor data types (descriptors, exit policies, controller messages), providing quite a bit to bootstrap with. I'd love to see a project that uses small C modules for libevent and crypto, but shifts the bulk of descriptor and controller handling to a higher level language (be it Python, Go, or whatever). Oh well. I can dream. :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Python Only Tor Client?
On 04/21/2014 01:18 PM, Jacob Garber wrote: > On 4/21/14, Fabio Pietrosanti (naif) wrote: >> Hi all, > >> does anyone know of any work to make a Python Only Tor Client, that just >> enable to expose a Tor Hidden Service? > >> It would be very cool if it would be possible to avoid "Tor binary" as a >> dependency for Globaleaks, making it pure Python application code. > >> The questions are: > >> - Are there projects that foresee to do something like that? > >> - From a Tor Project perspective, does it make sense? > >> - From a Security perspective, are there strong security implications in >> doing so? > > > I have been considering such a project, though my purpose for pursuing it > would > be to both learn Python and to come to a better understanding of the internals > of Tor. Perhaps not the best circumstances for a solid implementation... > > For the time being my implementation is just going to be an experiment with > trying to speak the Tor protocol, but assuming that I can get some of the > basic > building-blocks working I'll be pursuing a Tor rewrite in my spare time (I'm > currently a student, and as such still sorting out my schedule). I'll > probably be in and out of IRC and these mailing lists asking questions > every now and > again (and trying not to ask stupid ones). > > - ajtgarber (0xEFDA75F9) > A190 2527 2D58 6A2B 8108 CB66 D57A A16A EFDA 75F9 > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > A friend and I are considering this as well for a little summer project (we're students too). In fact, we've started a bit already (very recently and limited on time until finals are over). We're sort of thinking the same things you are, and main our goals with this are: - learn internals of Tor protocol - learn more about anonymity systems and onion routing (and programming challenges that go along with this) - get better with Python (specifically Python3) We're not so focused on making a practical tool at this point and more interested in just implementing all the specs correctly, although I suppose it's possible it could turn into something useful in the future. You're welcome to hack on this with us if you want! Check here: https://github.com/blackd0t/needs-a-name Note: we really *just* started, and are still working out the basics of the protocol, "when to do what", etc. and figuring out how pieces will fit together. If you just want to do your own thing, feel free to be in touch if you want to talk about questions re: the protocol and/or chat about design decisions. We're currently figuring this stuff out too. Nik signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Python Only Tor Client?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 4/21/14, Fabio Pietrosanti (naif) wrote: > Hi all, > > does anyone know of any work to make a Python Only Tor Client, that just > enable to expose a Tor Hidden Service? > > It would be very cool if it would be possible to avoid "Tor binary" as a > dependency for Globaleaks, making it pure Python application code. > > The questions are: > > - Are there projects that foresee to do something like that? > > - From a Tor Project perspective, does it make sense? > > - From a Security perspective, are there strong security implications in > doing so? > I have been considering such a project, though my purpose for pursuing it would be to both learn Python and to come to a better understanding of the internals of Tor. Perhaps not the best circumstances for a solid implementation... For the time being my implementation is just going to be an experiment with trying to speak the Tor protocol, but assuming that I can get some of the basic building-blocks working I'll be pursuing a Tor rewrite in my spare time (I'm currently a student, and as such still sorting out my schedule). I'll probably be in and out of IRC and these mailing lists asking questions every now and again (and trying not to ask stupid ones). - - ajtgarber (0xEFDA75F9) A190 2527 2D58 6A2B 8108 CB66 D57A A16A EFDA 75F9 -BEGIN PGP SIGNATURE- Version: n/a iQIcBAEBAgAGBQJTVV/4AAoJEEyLqVBnwH7XGu0P/3e0ZI+y067si2PItq4xWsaq +NLIzEymUjoSEM8iaYkZVumcOofY+yD1vCEGIvUroCvymC0YWFH+FYw5jkiffjRX 6wmc/d25ARtT/wVP59Nrmi+P9ZpD1fMaNaQ68eS3rnIPbZHc/ONsemXnW3g/m49Q zPViKtXNu3/1pmix33yS2SSU8uJIPd9j7NWDV3lxZ9fOlFfv0TocgJgvYdx0gVJC QGXiK6dprGgXhEy4+pzxDroUbKynh0pwd6N5ZiwlCbhcSAeIps87zGPldnasb8cA ZHEcyG8Gvlsoat/kQAVI7EwLYS3HCXiqKnhmoB1hXllDG6pJpYK1FufwGYyvlUZM ds1s0OQymmuftgEFcAbuInBlbqKihwllspMGdoz6SjBj50+iYqG3K/XP5yhyiZBx fk6X4LhAPh+GCClSRPn7ZV6oPDqrc/T3yodcUfGoKAlZiFQkCkX/DZUITr59Sb1g Hy7CKBIUdrzvK0B4XLf9gdVpf/pZCy0CTUikZbnke2ctyEseKkQbiZGLYIC5+ueT VJTGYtlFxZtblz3dh+lfwEI5HAPQRaa/cR6yRJd4yxvIOGlFNNAyn4E4HXuI4K+L VoWaDoFQQButYMlx8LiYt228HGVQkfxPpwX5OWH8u2BJpRYqKblGWpGu2bvkgiyw ZpsBF6B/8v+FTLN0fMk6 =s4ji -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Potentially n00b question about Tor Cloud & Heartbleed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Ah, I just saw that Sina spoke to exactly this issue in your ticket #11502. I'll continue this conversation out of list with him. Peter B: > hi all, > > As I understand, there are two steps to mitigating the Heartbled > bug for Tor bridges: > > 1. Upgrade OpenSSL 2. rm -rf /var/lib/tor/keys/* and restart the > tor procses > > While the bridges on Tor Cloud (and therefore Access' Global Proxy > Cloud) are configured to automatically fetch updates, there is no > way to complete step 2 with SSH access, correct? If so, is there > any plan to deal with instances that were set up with the > vulnerable version of OpenSSL, but whoever set up the instance has > not or cannot regenerate the keys. > > - -- Peter Bourgelais Circumvention and Network Interference Technologist Access | accessnow.org | rightscon.org PGP ID: 0x1C16F6D8 Fingerprint: EC9B 18C2 EBF4 07E0 37C6 E306 6592 DE70 1C16 F6D8 Github: https://github.com/pbourgel -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTVUixAAoJEGWS3nAcFvbYD5cP/iSgwaz4sYluNXugq2359qv1 Cn4fsUeNDA3w6RClT30r+S2hH92Tt+W0bnxBkaCnatMbjb1/F60NDf/3hBFBgpWD fBmwWHd5aebCjzmEmUB9e92JLd7NLuidI2incpRw5q8NhecVlH5QZ1XYeDdn2+rh 7bvMy1OIj/mfdsXJ6LrpfLqlap6ubiKthvP7uxc3ym87IvKX5rMrOVko0B7rXoth i1mJHMCmKAC7duim1ACZ3Jnvx1RU6kYeDXrwVmViMKKL97xTJgFAmvfH1Vqf6v2V kGv61t57XgVPpllSsD3TCNVfEymo0u0UeGEYh/uWx7lGBmJkriV0sT5RnAFoBg0o 6g8bOMwFb4kxNwCPLWau/mwXEcjE33TTZ1dY7rUSDGEqxXgQj2CkVhs8Xp6yP/22 DNCml+nd5qaciUbGHqKZzFAiFa/6OOenpZxVAtqkxniUIwtHgIzNFo683E0fyTrE uI3UpaVaEdaTITqYcVmtISvsJ7myZF9WI+BFGmZePbOXk6Uz7/w1URfVCihsJkyk yPqEEMRLbZowoOdKNufqXLeECESI0dN3J43Ch5cwJdW+5bxivNofNcxFkZz4C5TL 3Nr2RMIgLylJWsUjtDl3t25529uH6wtZdS1glFsKii+gCvhwnx9NpHDg1X5suQWS ho4Rct2UlTXSpiWkp626 =6nX6 -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Potentially n00b question about Tor Cloud & Heartbleed
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 hi all, As I understand, there are two steps to mitigating the Heartbled bug for Tor bridges: 1. Upgrade OpenSSL 2. rm -rf /var/lib/tor/keys/* and restart the tor procses While the bridges on Tor Cloud (and therefore Access' Global Proxy Cloud) are configured to automatically fetch updates, there is no way to complete step 2 with SSH access, correct? If so, is there any plan to deal with instances that were set up with the vulnerable version of OpenSSL, but whoever set up the instance has not or cannot regenerate the keys. - -- Peter Bourgelais Circumvention and Network Interference Technologist Access | accessnow.org | rightscon.org PGP ID: 0x1C16F6D8 Fingerprint: EC9B 18C2 EBF4 07E0 37C6 E306 6592 DE70 1C16 F6D8 Github: https://github.com/pbourgel -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJTVUToAAoJEGWS3nAcFvbY15oP/31qpnsLAFZZiuvsQ19jwx6C 74drB1P8zdr8cpAvCVMpmEGRE1hDHTB4iyKQ4rttaAhJu5D5ukP+pGvL+bIL7bTC mzyww37gZE4Fh/ydyaUEQSPw6dBR0pMpKl61/DUKsvF2G/62gW8c5j/+ZXlvBYb8 5tX1ecfWF3LAuBDqrFK0EHtysZ8JfwjRz9aOBR/ZuGM9NKW2UN5iLljxsq7nKIIx YFDKEwPJKPV8t4AsaAxv1Z6ctFqAOSmFObj5Ku9Ifc8vgpSKx9yZpuAttpfaEwYT wf+PHvn1hZNzHb/UZ5ZaIBqP63w+xqTLUEmoDrO9qwSUsi2DhCPUCvKhQ7wzWsnZ 3U+GvmsV3c1JGHCroXii+B2hu04DI0fKxboyFdy+x19PvAMf4UAEIwAG+X0FO9dS pd1F8Zq5ohXItjdAm6ZxGtOL1Q9KHU29G9liYjj/N9NYq7iQLd59CNhoELHulYoO BYBUyTzVwASYIDPbcUZ63z23vCk+ymfX95JTj2J4LK0ZbmJWhe+23ZOIfXiF/v/t 5UBoSIPok336NmsNv7vGMV8O8PuqsEm6/Gv9CCETlUw+wzrSdlu3K0QhLjYagj0C Fl8uEiKzH1LzavdBsSMfDKCGQya4LbvWSnDM2DmHWra3hPG6xJMvnMPxCdqr73dv vGezCcQBb6limTdHW1xH =xqRh -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Python Only Tor Client?
On 4/21/14, Fabio Pietrosanti (naif) wrote: > Hi all, > > does anyone know of any work to make a Python Only Tor Client, that just > enable to expose a Tor Hidden Service? > > It would be very cool if it would be possible to avoid "Tor binary" as a > dependency for Globaleaks, making it pure Python application code. > > The questions are: > > - Are there projects that foresee to do something like that? > > - From a Tor Project perspective, does it make sense? > > - From a Security perspective, are there strong security implications in > doing so? > I think it makes sense - the effort will be similar to Orchid which is written in pure Java. It is a great deal of work. If someone were to serious consider this effort - I think they should probably talk extensively with Nick, Roger, Andrea and probably also Bruce (who wrote Orchid) as they're probably the four most qualified people to make suggestions. All the best, Jacob ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Python Only Tor Client?
Hey Naif, Have you considered making something with STEM? Granted, it probably isn't *quite* what you're looking for, but might get you closer: https://stem.torproject.org best, Griffin On 2014-04-21 04:46, Fabio Pietrosanti (naif) wrote: Hi all, does anyone know of any work to make a Python Only Tor Client, that just enable to expose a Tor Hidden Service? It would be very cool if it would be possible to avoid "Tor binary" as a dependency for Globaleaks, making it pure Python application code. The questions are: - Are there projects that foresee to do something like that? - From a Tor Project perspective, does it make sense? - From a Security perspective, are there strong security implications in doing so? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Panopticlick summer project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon 21 Apr 2014 02:21:35 PM CEST, Mike Perry wrote: > Gunes Acar: Sorry everyone for the long pause. > > I wrote down a proposal (and some code) to address issues raised > by Mike and George: > https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf > > Looking for your comments and critics... > >> This proposal looks like quite a good start. With respect to >> automated testing, you should definitely discuss this with >> Nicolas Vigier, who is our lead automation engineer. He has begun >> writing TBB automation tests, and can help you integrate your >> tests into that framework. You can see a few links to the >> existing testing infrastructure at in the QA and testing section >> of the TBB hacking doc: >> https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#QAandTesting Sure, >> I already have some questions noted down for him. But I must say the framework he set up is pretty easy to extend. I could add and run my tests in minutes. > > >> With respect to the rest of it, my main immediate question is how >> we should separate the results by Tor Browser version. Tor >> Browser currently reports its user agent string as the Windows >> build of the Firefox ESR release it is based off of, with no >> minor version. > >> This likely means we want users who are comfortable submitting >> their results to the dataset to select their specific TBB version >> (which is visible in the upper-right corner of about:tor). >> However, if they get this wrong, it may bias results. :/ I'd prefer minimizing the user intervention. Maybe we can modify Torbutton to place a link to test suite on about:tor page that includes TBB version in the URL (or as a hidden form field). We may have the same link somewhere in the Torbutton drop down menu. And if we want to link to the test suite from a web site, we may redirect users through about:tor?run=fptest to collect and pass the TBB version automatically. Or have a about:fingerprint page that does the same. Still we may need some sanity checks to protect data from potential polluters (crafting URLs with the fake TBB version), if that's ever possible. > > > On 03/21/2014 11:39 PM, Peter Eckersley wrote: I think we're fine with open sourcing under the Affero GPLv3. On Tue, Mar 18, 2014 at 12:28:12PM -0700, Mike Perry wrote: > Yan Zhu: >> On 03/17/2014 04:41 AM, Gunes Acar wrote: >>> Hi Yan, >>> >>> Glad that you're interested in the project. It'd be >>> very nice collaborate with you on this. >>> >>> Indeed, we've been corresponding with Peter for a >>> related project and I mentioned my intention to work as >>> a middleman between EFF and Tor. >>> >> >> Great, it seems that Peter and I are both interested and >> willing to help. >> >> Regarding >> https://trac.torproject.org/projects/tor/ticket/6119#comment:10, >> >> Peter says he has some reluctance to open source the project >> (not the data) because it might make it easier for some >> websites to track visitors without their consent. > > This might have been a valid concern 5 years ago, but now > it's just a joke. The tests on Panopticlick are ancient, > widely known, easy to reproduce, and since then much more > severe and invasive mechanisms of fingerprinting have since > been developed/deployed in modern browsers. > > Moreover, only 2 of the tests it performs actually apply to > Tor Browser users. > > Banks in particular have already deployed some of the > techniques we've fixed that the EFF study entirely > predates. And these techniques are far higher entropy than > browser resolution (such as localhost open port > enumeration, OS theme fingerprinting, and HTML5+WebGL > canvas rendering+extraction+hashing). > > Not only should we (as Tor) publicly provide tests and > easy-to-deploy working PoC code for all of these vectors, > we should also endeavor to detail cases where major browser > vendors are ignoring or exacerbating this problem, and make > it easy for everyone to test and observe this behavior > themselves. > > Not sure if that means the EFF now has a conflict of > interest with this project for some ridiculous reason, but > frankly any attempt at trying to "hide" these techniques is > downright silly. They are too well known (most are publicly > documented elsewhere, or at least on our bugtracker), and > there's waaay too much money on the other side of the fence > in terms of incentives to develop and deploy working > attacks. > > Further, starting the from EFF codebase might also be a > hindrance to us. It is not designed for measuring the > effects of defenses. In fact, its measurement mechanisms > actively penalize any attempt at defense development > (becau
Re: [tor-dev] Panopticlick summer project
Gunes Acar: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sorry everyone for the long pause. > > I wrote down a proposal (and some code) to address issues raised by > Mike and George: > https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf > > Looking for your comments and critics... This proposal looks like quite a good start. With respect to automated testing, you should definitely discuss this with Nicolas Vigier, who is our lead automation engineer. He has begun writing TBB automation tests, and can help you integrate your tests into that framework. You can see a few links to the existing testing infrastructure at in the QA and testing section of the TBB hacking doc: https://trac.torproject.org/projects/tor/wiki/doc/TorBrowser/Hacking#QAandTesting With respect to the rest of it, my main immediate question is how we should separate the results by Tor Browser version. Tor Browser currently reports its user agent string as the Windows build of the Firefox ESR release it is based off of, with no minor version. This likely means we want users who are comfortable submitting their results to the dataset to select their specific TBB version (which is visible in the upper-right corner of about:tor). However, if they get this wrong, it may bias results. :/ > On 03/21/2014 11:39 PM, Peter Eckersley wrote: > > I think we're fine with open sourcing under the Affero GPLv3. > > > > > > On Tue, Mar 18, 2014 at 12:28:12PM -0700, Mike Perry wrote: > >> Yan Zhu: > >>> On 03/17/2014 04:41 AM, Gunes Acar wrote: > Hi Yan, > > Glad that you're interested in the project. It'd be very nice > collaborate with you on this. > > Indeed, we've been corresponding with Peter for a related > project and I mentioned my intention to work as a middleman > between EFF and Tor. > > >>> > >>> Great, it seems that Peter and I are both interested and > >>> willing to help. > >>> > >>> Regarding > >>> https://trac.torproject.org/projects/tor/ticket/6119#comment:10, > >>> Peter says he has some reluctance to open source the project > >>> (not the data) because it might make it easier for some > >>> websites to track visitors without their consent. > >> > >> This might have been a valid concern 5 years ago, but now it's > >> just a joke. The tests on Panopticlick are ancient, widely known, > >> easy to reproduce, and since then much more severe and invasive > >> mechanisms of fingerprinting have since been developed/deployed > >> in modern browsers. > >> > >> Moreover, only 2 of the tests it performs actually apply to Tor > >> Browser users. > >> > >> Banks in particular have already deployed some of the techniques > >> we've fixed that the EFF study entirely predates. And these > >> techniques are far higher entropy than browser resolution (such > >> as localhost open port enumeration, OS theme fingerprinting, and > >> HTML5+WebGL canvas rendering+extraction+hashing). > >> > >> Not only should we (as Tor) publicly provide tests and > >> easy-to-deploy working PoC code for all of these vectors, we > >> should also endeavor to detail cases where major browser vendors > >> are ignoring or exacerbating this problem, and make it easy for > >> everyone to test and observe this behavior themselves. > >> > >> Not sure if that means the EFF now has a conflict of interest > >> with this project for some ridiculous reason, but frankly any > >> attempt at trying to "hide" these techniques is downright silly. > >> They are too well known (most are publicly documented elsewhere, > >> or at least on our bugtracker), and there's waaay too much money > >> on the other side of the fence in terms of incentives to develop > >> and deploy working attacks. > >> > >> Further, starting the from EFF codebase might also be a hindrance > >> to us. It is not designed for measuring the effects of defenses. > >> In fact, its measurement mechanisms actively penalize any attempt > >> at defense development (because any approach to alter browser > >> behavior instantly makes you more unique than the previous > >> userbase). > >> > >> I actually think Panopticlick has of late done more to prevent > >> browser fingerprinting defense development than to encourage it. > >> I would really like to see it DIAF. > >> > >> Here's hoping we can make something better! > >> > >> -- Mike Perry > > > > > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQEcBAEBAgAGBQJTUg4mAAoJEPb7JcMmVt4gQjwIALCsTOxvUFP3HY0N8Ap9fpKW > GD193EW32X80iH6VY54AIWA29wxKaKEM4vBJBVLkhYt8s68OAqaV1vMNtmEev26h > 2yg9us2HNYjBzaxFQpX7qhmDCiucpe3zVZZXq9T34OhjxscWc90JdvWA5D8Eiqto > exJzqi3k5djFU66apzfFAwYpk8E0Og582XFg5TOQFYGo6LvNyT69LH7+jlNsHL65 > atspVO47wKH4+0nhoG22tsMdZRzhmgSbSB1gx2a7Esf3dOBf+R0BBw+qcZptqq8Z > NPyobAecQzmV/SXgjDF4PaE12A4IkK4nCWUax7ksE6YbCNhAKBlcAt+/q2JeOt8= > =i+/g > -END PGP SIGNATURE- >
[tor-dev] Python Only Tor Client?
Hi all, does anyone know of any work to make a Python Only Tor Client, that just enable to expose a Tor Hidden Service? It would be very cool if it would be possible to avoid "Tor binary" as a dependency for Globaleaks, making it pure Python application code. The questions are: - Are there projects that foresee to do something like that? - From a Tor Project perspective, does it make sense? - From a Security perspective, are there strong security implications in doing so? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
