- tor-dev - lists.torproject.org

Re: [tor-dev] Implications of switching to a single guard node: some conclusions
by Nicholas Hopper 25 Mar '14

25 Mar '14

On Thu, Mar 13, 2014 at 5:21 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > tl;dr: analysis seems to indicate that switching to one guard node > might not be catastrophic to the performance of Tor. To improve > performance some increased guard bandwidth thresholds are proposed > that seem to help without completely destroying the anonymity of the > network. Enjoy the therapeutic qualities of the graphs and please read > the whole post. This took way longer than I expected it to, but here we go. In order to examine the assumption that "higher guard bandwidth == better client performance", I modified Aaron Johnson's TorPS simulator to simulate 50K clients in several different cases: - "3guards": choose 3 guards according to the current algorithm - "T=250": choose 1 guard, guard flag assigned as current - "T=1000": choose 1 guard, filtering guards with measured bandwidth < 1000 KB/s [Note: these former guards then have an increased probability of being selected as middle and/or exit nodes] - "T=2000": 1 guard, filter guards with measured bandwidth < T - "T=3000": ibid - "T=4000": ibid For each client, the simulator created 600 circuits, and computed the maximum bandwidth each circuit could handle (the minimum bandwidth of the guard, middle and exit relays). This gives us an empirical distribution on circuit performance for each client. Then we can ask questions about the "typical" bandwidth for a client, e.g. the median circuit performance. How many clients typically have low-bandwidth circuits in each case? Looking at the 5000 (10%) unluckiest clients, we see the following behavior: https://www-users.cs.umn.edu/~hopper/guard_threshold_median_bandwidth.png Essentially, while the current guard threshold does make the unluckiest clients pretty sad on average, even a 1MB/s threshold means that on average things are a little bit brighter than the current situation, and a 2MB/s threshold for the guard flag makes everyone happier in the typical case. (And increasing the threshold beyond 2MB/s doesn't really help much) (This data is based on the consensus documents from 13 February 2014, chosen pretty much arbitrarily from the most recent month of archived consensus documents and relay descriptors) -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------

1 0

Re: [tor-dev] GSoC 2014 Txtorcon/stem integration
by meejah 25 Mar '14

25 Mar '14

E M <einnhverr(a)gmail.com> writes: > I don't really know the "moving" pace you expect me to have, so I > safely draft the final/desired proposal in time, so I would appreciate > if my pace is no up to your expectations, to let me know so I could > adapt accordingly. After the weekend is fine. The next deadline, as I understand, is April 5 at which point we (Tor people) need to have all the proposals ranked. So, your final proposal would need to be ready some time before that (say, end of March latest) as we need time to put together final rankings (with many different mentors, etc) before then. We have something like 32 proposals in the pipeline, way more than can be accepted. Although I was involved in GSoC 2013, there were no proposals for the project so this is my first time, too ;) I guess in general, this is a bit like a job interview and a bit like a contest? As in: since not all the proposals we have are going to be accepted, the more you can make yours stand out, the better I'd say. Thanks, meejah

2 1

[Orbot patch] Fix building of openssl on newer systems
by Daniel Martí 25 Mar '14

25 Mar '14

This is probably due to newer auto-tools having slightly different configuration options. On a recent setup, the following occured: make[2]: arm-eabi-/opt/android-ndk/[...]/arm-linux-androideabi-gcc: Command not found It was, for some reason, making CC be arm-eabi- plus the path to the NDK. Forcing CC when running make works around this problem. --- external/Makefile | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/external/Makefile b/external/Makefile index 875fa90..0310bb2 100644 --- a/external/Makefile +++ b/external/Makefile @@ -84,17 +84,15 @@ all: assets lib/libcrypto.a: cd openssl && \ - CC="$(CC)" \ ./Configure android -DL_ENDIAN && \ - ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr make build_libs + make CC="$(CC)" ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr build_libs lib/libssl.a: cp config.sub openssl cp config.guess openssl cd openssl && \ - CC="$(CC)"\ ./Configure android -DL_ENDIAN && \ - ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr make build_libs + make CC="$(CC)" ANDROID_DEV=$(NDK_BASE)/platforms/android-8/arch-arm/usr build_libs openssl-build-stamp: lib/libcrypto.a lib/libssl.a touch openssl-build-stamp -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

1 0

Re: [tor-dev] GSoC 2014 Txtorcon/stem integration
by Damian Johnson 25 Mar '14

25 Mar '14

Hi Einnhverr. Moving this to tor-dev@ since you intended to but got the wrong address (it's tor-dev(a)lists.torproject.org) If you're not already subscribed to it then please do so at... https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev Cheers! -Damian On Tue, Mar 25, 2014 at 4:36 AM, E M <einnhverr(a)gmail.com> wrote: > On 3/25/14, meejah <meejah(a)meejah.ca> wrote: > >> I meant a small example as part of the proposal. The idea would be to >> demonstrate some understanding of the two libraries, Python itself and >> the issues involved. You should also compare your proposal to some of >> the others from past years that I linked to -- some more detail about >> what (you think) needs to happen would be useful. This doesn't >> necessarily need to be 100% correct, but will give us some idea that >> you've thought through the issues and design. > > Hi meejah, > > I will take the time over the weekend to include some small example in > the proposal, along with more fine graned points about the work I > think should be done and other ajustments(e.g. rework the estimated > deliverables you suggested). > > I don't really know the "moving" pace you expect me to have, so I > safely draft the final/desired proposal in time, so I would appreciate > if my pace is no up to your expectations, to let me know so I could > adapt accordingly. > > >> p.s. the way most people use #tor-dev on IRC is to stay logged in >> (e.g. via a tmux or screen session) so that timezones and so forth can >> allow answers to happen later on. > > I'm in the process of setting up an VM environment with a IRC bouncer > so I could be available as much as possible on the #tor-dev channel. > My usual available hours, after setting up the bouncer is complete, > are 04:00 - 20:00 UTC(excluding the hours when I'm in class) > > I'm always open to any suggestions regarding the > proposal/process/project, please don't hesitate to bring them up to > me. > > I appreciate for taking your time out of your schedule to guide me > through this process! > > Thank You, > einnhverr On Tue, Mar 25, 2014 at 4:36 AM, E M <einnhverr(a)gmail.com> wrote: > On 3/25/14, meejah <meejah(a)meejah.ca> wrote: > >> I meant a small example as part of the proposal. The idea would be to >> demonstrate some understanding of the two libraries, Python itself and >> the issues involved. You should also compare your proposal to some of >> the others from past years that I linked to -- some more detail about >> what (you think) needs to happen would be useful. This doesn't >> necessarily need to be 100% correct, but will give us some idea that >> you've thought through the issues and design. > > Hi meejah, > > I will take the time over the weekend to include some small example in > the proposal, along with more fine graned points about the work I > think should be done and other ajustments(e.g. rework the estimated > deliverables you suggested). > > I don't really know the "moving" pace you expect me to have, so I > safely draft the final/desired proposal in time, so I would appreciate > if my pace is no up to your expectations, to let me know so I could > adapt accordingly. > > >> p.s. the way most people use #tor-dev on IRC is to stay logged in >> (e.g. via a tmux or screen session) so that timezones and so forth can >> allow answers to happen later on. > > I'm in the process of setting up an VM environment with a IRC bouncer > so I could be available as much as possible on the #tor-dev channel. > My usual available hours, after setting up the bouncer is complete, > are 04:00 - 20:00 UTC(excluding the hours when I'm in class) > > I'm always open to any suggestions regarding the > proposal/process/project, please don't hesitate to bring them up to > me. > > I appreciate for taking your time out of your schedule to guide me > through this process! > > Thank You, > einnhverr

1 0

Reminder: Tor weekly dev meetings Wednesday at 19:00 UTC
by Nick Mathewson 25 Mar '14

25 Mar '14

Hi, all. This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) We're going to try doing the weekly meeting on Wednesday. The meeting time will be: Wednesday March 26, 19:00 UTC. (That's 3pm EDT and 12:00 noon PDT) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. Starting in April, I'll be sending these reminders out monthly rather than weekly, unless that causes a huge drop in attendance. peace, -- Nick

1 0

Re: [tor-dev] Stegotorus - google unit tests
by vmon＠riseup.net 25 Mar '14

25 Mar '14

Hey Noah, It seems that you successfully compiled Stegotorus, congratulation! ;) Although, you still have problem with compiling the unit tests in google framework, they are not essential in solving your challenge. I recommend that you start working on your challenge now. Per Google's recommendation, I've included the google unit test code inside the code, so that g_unittests_LDFLAGS probably won't help (because you are linking to the object file directly). You might want to download the google frame work and try to compile it independently without the stegotorus headache: https://googletest.googlecode.com/files/gtest-1.7.0.zip Keep the good work going! vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > after fixing the local branch and having to remove -Werror by hand > from the makefile yet again...maybe I am missing something else in the > unit tests? I checked git branch -v and it now matches the tor-improve > on remote/tor-improve > > selimthegrim@Rimsky-Korsakoffee:~/stegotorus$ make -j2 > make all-am > make[1]: Entering directory `/home/selimthegrim/stegotorus' > depbase=`echo src/steg/payload_scraper.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/steg/payload_scraper.o -MD -MP -MF $depbase.Tpo -c > -o src/steg/payload_scraper.o src/steg/payload_scraper.cc &&\ > mv -f $depbase.Tpo $depbase.Po > /bin/bash ./src/genmodtable.sh protolist.cc src/protocol/chop.cc > src/protocol/chop_blk.cc src/protocol/null.cc > protolist.cc is unchanged > touch stamp-protolist > /bin/bash ./src/genmodtable.sh steglist.cc src/steg/b64cookies.cc > src/steg/cookies.cc src/steg/embed.cc src/steg/http.cc > src/steg/http_apache.cc src/steg/http_steg_mods/file_steg.cc > src/steg/http_steg_mods/pdfSteg.cc src/steg/http_steg_mods/swfSteg.cc > src/steg/http_steg_mods/jsSteg.cc src/steg/http_steg_mods/jpgSteg.cc > src/steg/http_steg_mods/pngSteg.cc src/steg/http_steg_mods/gifSteg.cc > src/steg/nosteg.cc src/steg/nosteg_rr.cc src/steg/payload_server.cc > src/steg/trace_payload_server.cc src/steg/payload_scraper.cc > src/steg/apache_payload_server.cc > steglist.cc is unchanged > touch stamp-steglist > depbase=`echo src/pgen_fake.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/pgen_fake.o -MD -MP -MF $depbase.Tpo -c -o > src/pgen_fake.o src/pgen_fake.cc &&\ > mv -f $depbase.Tpo $depbase.Po > /bin/bash ./src/test/genunitgrps.sh unitgrplist.cc > src/test/unittest_base64.cc src/test/unittest_compression.cc > src/test/unittest_crypt.cc src/test/unittest_pdfsteg.cc > src/test/unittest_socks.cc > touch stamp-unitgrplist > depbase=`echo src/test/tltester.o | sed 's|[^/]*$|.deps/&|;s|\.o$||' > `;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/tltester.o -MD -MP -MF $depbase.Tpo -c -o > src/test/tltester.o src/test/tltester.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/webpage_tester.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/webpage_tester.o -MD -MP -MF $depbase.Tpo -c - > o src/test/webpage_tester.o src/test/webpage_tester.cc &&\ > mv -f $depbase.Tpo $depbase.Po > src/steg/payload_scraper.cc: In member function ‘int > PayloadScraper::scrape()’: > src/steg/payload_scraper.cc:283:49: warning: ignoring return value of > ‘int system(const char*)’, declared with attribute warn_unused_result > [-Wunused-result] > system(ftp_unmount_command_string.c_str()); > ^ > src/steg/payload_scraper.cc:312:49: warning: ignoring return value of > ‘int system(const char*)’, declared with attribute warn_unused_result > [-Wunused-result] > system(ftp_unmount_command_string.c_str()); > ^ > depbase=`echo protolist.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT protolist.o -MD -MP -MF $depbase.Tpo -c -o protolist.o > protolist.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo steglist.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT steglist.o -MD -MP -MF $depbase.Tpo -c -o steglist.o > steglist.cc &&\ > mv -f $depbase.Tpo $depbase.Po > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o pgen_fake src/pgen_fake.o src/util.o > src/rng.o src/base64.o -lcrypto > depbase=`echo src/test/tinytest.o | sed 's|[^/]*$|.deps/&|;s|\.o$||' > `;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/tinytest.o -MD -MP -MF $depbase.Tpo -c -o > src/test/tinytest.o src/test/tinytest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest.o | sed 's|[^/]*$|.deps/&|;s|\.o$||' > `;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest.o -MD -MP -MF $depbase.Tpo -c -o > src/test/unittest.o src/test/unittest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_base64.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_base64.o -MD -MP -MF $depbase.Tpo -c > -o src/test/unittest_base64.o src/test/unittest_base64.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_compression.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_compression.o -MD -MP -MF > $depbase.Tpo -c -o src/test/unittest_compression.o > src/test/unittest_compression.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_crypt.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_crypt.o -MD -MP -MF $depbase.Tpo -c - > o src/test/unittest_crypt.o src/test/unittest_crypt.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_pdfsteg.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_pdfsteg.o -MD -MP -MF $depbase.Tpo - > c -o src/test/unittest_pdfsteg.o src/test/unittest_pdfsteg.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/unittest_socks.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/unittest_socks.o -MD -MP -MF $depbase.Tpo -c - > o src/test/unittest_socks.o src/test/unittest_socks.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo unitgrplist.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT unitgrplist.o -MD -MP -MF $depbase.Tpo -c -o > unitgrplist.o unitgrplist.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/gtest/gtest_main.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/gtest/gtest_main.o -MD -MP -MF $depbase.Tpo - > c -o src/test/gtest/gtest_main.o src/test/gtest/gtest_main.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/gtest/gtest-all.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/gtest/gtest-all.o -MD -MP -MF $depbase.Tpo -c > -o src/test/gtest/gtest-all.o src/test/gtest/gtest-all.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/steg_test/steg_mod_unittest.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/steg_test/steg_mod_unittest.o -MD -MP -MF > $depbase.Tpo -c -o src/test/steg_test/steg_mod_unittest.o > src/test/steg_test/steg_mod_unittest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/test/steg_test/payload_scraper_unittest.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/steg_test/payload_scraper_unittest.o -MD -MP - > MF $depbase.Tpo -c -o src/test/steg_test/payload_scraper_unittest.o > src/test/steg_test/payload_scraper_unittest.cc &&\ > mv -f $depbase.Tpo $depbase.Po > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o tltester src/test/tltester.o > src/util.o src/util-net.o -levent > depbase=`echo src/test/tester_proxy/tester_proxy.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/test/tester_proxy/tester_proxy.o -MD -MP -MF > $depbase.Tpo -c -o src/test/tester_proxy/tester_proxy.o > src/test/tester_proxy/tester_proxy.cc &&\ > mv -f $depbase.Tpo $depbase.Po > depbase=`echo src/http_parser/http_parser.o | sed 's| > [^/]*$|.deps/&|;s|\.o$||'`;\ > g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods - > I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra - > Wno-missing-field-initializers -Wformat=2 -std=c++0x -g -O2 - > std=gnu++11 -MT src/http_parser/http_parser.o -MD -MP -MF $depbase.Tpo > -c -o src/http_parser/http_parser.o src/http_parser/http_parser.cc &&\ > mv -f $depbase.Tpo $depbase.Po > rm -f libstegotorus.a > ar cru libstegotorus.a src/base64.o src/compression.o > src/connections.o src/crypt.o src/mkem.o src/network.o src/protocol.o > src/rng.o src/socks.o src/steg.o src/util.o src/util-net.o > src/evbuf_util.o src/curl_util.o src/transparent_proxy.o > src/protocol/chop.o src/protocol/chop_blk.o src/protocol/null.o > src/steg/b64cookies.o src/steg/cookies.o src/steg/embed.o > src/steg/http.o src/steg/http_apache.o src/steg/http_apache.o > src/steg/http_steg_mods/file_steg.o src/steg/http_steg_mods/pdfSteg.o > src/steg/http_steg_mods/swfSteg.o src/steg/http_steg_mods/jsSteg.o > src/steg/http_steg_mods/jpgSteg.o src/steg/http_steg_mods/pngSteg.o > src/steg/http_steg_mods/gifSteg.o src/steg/nosteg.o > src/steg/nosteg_rr.o src/steg/payload_server.o > src/steg/trace_payload_server.o src/steg/payload_scraper.o > src/steg/apache_payload_server.o src/subprocess-unix.o protolist.o > steglist.o > : libstegotorus.a > /bin/bash ./src/audit-globals.sh src/base64.o src/compression.o > src/connections.o src/crypt.o src/mkem.o src/network.o src/protocol.o > src/rng.o src/socks.o src/steg.o src/util.o src/util-net.o > src/evbuf_util.o src/curl_util.o src/transparent_proxy.o > src/protocol/chop.o src/protocol/chop_blk.o src/protocol/null.o > src/steg/b64cookies.o src/steg/cookies.o src/steg/embed.o > src/steg/http.o src/steg/http_apache.o src/steg/http_apache.o > src/steg/http_steg_mods/file_steg.o src/steg/http_steg_mods/pdfSteg.o > src/steg/http_steg_mods/swfSteg.o src/steg/http_steg_mods/jsSteg.o > src/steg/http_steg_mods/jpgSteg.o src/steg/http_steg_mods/pngSteg.o > src/steg/http_steg_mods/gifSteg.o src/steg/nosteg.o > src/steg/nosteg_rr.o src/steg/payload_server.o > src/steg/trace_payload_server.o src/steg/payload_scraper.o > src/steg/apache_payload_server.o src/subprocess-unix.o protolist.o > steglist.o src/main.o > sed: -e expression #1, char 113: unknown option to `s' > touch stamp-audit-globals > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o unittests src/test/tinytest.o > src/test/unittest.o src/test/unittest_base64.o > src/test/unittest_compression.o src/test/unittest_crypt.o > src/test/unittest_pdfsteg.o src/test/unittest_socks.o unitgrplist.o > libstegotorus.a -levent -lcrypto -lz -lcurl -lboost_system - > lboost_filesystem -lconfig++ > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o tester_proxy > src/test/tester_proxy/tester_proxy.o -levent_openssl -levent -lssl - > lcrypto > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o webpage_tester > src/test/webpage_tester.o src/util.o src/util-net.o src/curl_util.o > src/http_parser/http_parser.o -levent -lcrypto -lz -lcurl - > lboost_system -lboost_filesystem -lconfig++ > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o stegotorus src/main.o libstegotorus.a > -levent -lcrypto -lz -lcurl -lboost_system -lboost_filesystem - > lconfig++ > g++ -Wall -Wextra -Wno-missing-field-initializers -Wformat=2 - > std=c++0x -g -O2 -std=gnu++11 -o g_unittests > src/test/gtest/gtest_main.o src/test/gtest/gtest-all.o > src/test/steg_test/steg_mod_unittest.o > src/test/steg_test/payload_scraper_unittest.o libstegotorus.a -levent - > lcrypto -lz -lcurl -lboost_system -lboost_filesystem -lconfig++ > /usr/bin/ld: src/test/gtest/gtest-all.o: undefined reference to symbol > 'pthread_key_delete@@GLIBC_2.2.5' > /lib/x86_64-linux-gnu/libpthread.so.0: error adding symbols: DSO > missing from command line > collect2: error: ld returned 1 exit status > make[1]: *** [g_unittests] Error 1 > make[1]: Leaving directory `/home/selimthegrim/stegotorus' > make: *** [all] Error 2

1 0

Re: [tor-dev] Stegotorus - DELETE_METHOD
by vmon＠riseup.net 24 Mar '14

24 Mar '14

Hey Noah, I somehow lost your email and can't find it. But at first look it seemed to me that autoreconf(and configure) is not defining the DELETE_METHOD in config.h while it supposed to do so by virtue of "configure.ac:85:AX_CXX_DELETE_METHOD". Did you run autoreconf before going ahead with configure? FYI, this is how the bundler maker, makes stegotorus on a (relatively) clean debian x86_64 vm: git clone "$(STEGOTORUS_HOME)" "$(STEGOTORUS_WORK)" cd "$(STEGOTORUS_WORK)" && git checkout tor-improve #&& git checkout --detach "$(STEGOTORUS_TAG)" cd "$(STEGOTORUS_WORK)" && autoreconf cd "$(STEGOTORUS_WORK)" && ./configure PKG_CONFIG_PATH=`pwd`&& make For me after I run the autoreconf and configure, I'll have the following line in config.h: #define DELETE_METHOD = delete Could you please verify that and if not re-run the autoreconf, you might also want to share your automake and gcc version with me. You also might want to send me config.log for further investigation. Wish you all the best with your stegotorus adventure, vmon

1 0

Re: [tor-dev] Stegotorus - lisboost problem
by vmon＠riseup.net 23 Mar '14

23 Mar '14

Hey Noah, > The configure file cant seem to digest libboost (on ubuntu). i > installed 1.53-all-dev in /usr/lib/x86_64-linux-gnu/ and then took The problem is that not all distribution come with libboost.pc file (ubuntu/debian come with individual pc file for each component of boost but not one pc file for the whole boost library). I have left a libboost.pc file in the root directory of Stegotorus. Just copy it into /usr/lib/pkgconfig or where ever your other package config (.pc) files reside. We should resolve this problem more fundamentally if your application goes through. Thanks for your efforts and let me know if you managed to pass this barrier. Best of luck, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > The configure file cant seem to digest libboost (on ubuntu). i > installed 1.53-all-dev in /usr/lib/x86_64-linux-gnu/ and then took > that out and installed 1.54-all-dev in usr/lib. Even though I set the > libboost_LIBS variable properly. > > On Fri, Mar 21, 2014 at 3:13 PM, <vmon(a)torproject.org> wrote: > > > Noah Rahman <selimthegrim(a)gmail.com> writes: > > It says you'll have to enable modifications > > > Just did! I'll try to update the tickets sometime this weekend. >

1 0

GSoC 2014 : Rewrite Tor Weather
by Sreenatha Bhatlapenumarthi 22 Mar '14

22 Mar '14

Hi there! I am Sreenatha(lucyd). I am interested in working on Tor Weather this summer as a part of GSoC 2014. I helped Damian migrate weather to stem(#8264) last summer and have been following the work on it's rewrite. I made an attempt to further this by writing a couple of python scripts. 1. Relay Search using Onionoo : A python script[0] that uses onionoo's search functionality to find relays with specific fingerprint/nickname/IP address. For now, I've used a global variable to store the search results for better performance in case of a repeated query. Once the database structure for the new weather is confirmed, I'll modify it accordingly. Feedback on this is much appreciated. 2. Patch for #9889 : I've also submitted a patch[1] for #9889 that checks if a given relay qualifies for a t-shirt. I'd really appreciate if you could take a look at my work and suggest possible improvements or provide some advice regarding the project in general. Cheers, Sreenatha [0] - https://github.com/lucyd/weather-rewrite/blob/master/search_relay.py [1] - https://trac.torproject.org/projects/tor/ticket/9889#comment:3

2 3

Fwd: About using source code
by saurav dahal 21 Mar '14

21 Mar '14

Can anybody please tell me how to use the original source code of tor by modifying and implementing on the TOR network? For example: I want to log how many circuits have been made through my OR. Thanks, Saurav

3 5

Tor integration into CACHeCoin
by kalgecin 21 Mar '14

21 Mar '14

Hey guys, I'm looking into integrating TOR network into CACHeCoin. The idea is, by default, the coin should connect through the tor network, with the option of disabling it and connecting normally. This will help boost some anonymity within the coin and help the TOR network by keeping up the nodes :-) The idea is, if the person activated connection through tor (which is already by default) he'll be able to receive stake. If he disables, No stake will be generated. Unfortunately i don't have much free time to dig into the tor code, but will be happy to receive the pull request on github https://github.com/kalgecin/CACHeCoin/ Please let me know what you think -- Kalgecin http://code.google.com/p/kalgecin *https://github.com/kalgecin <https://github.com/kalgecin>* https://plus.google.com/u/0/104834274682757290524<https://plus.google.com/u/0/104834274682757290524/posts> https://twitter.com/kalgecin

3 3

Panopticlick summer project
by Gunes Acar 21 Mar '14

21 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear All, My name is Gunes Acar, a 2nd year PhD student at Computer Security and Industrial Cryptography (COSIC) group of University of Leuven. I work with Prof. Claudia Diaz and study online tracking and browser fingerprinting. I'd like to work on "Panopticlick" (https://www.torproject.org/getinvolved/volunteer.html.en#panopticlick) summer project and other fingerprinting related issues which I tried to outline below: 1) Collaborate with Peter@EFF to port/open-source Panopticlick: https://trac.torproject.org/projects/tor/ticket/6119#comment:4 a) implement necessary modifications - e.g. we won't be having cookies or real IP addresses to match returning visitors. b) consider security implications of storing fingerprints (e.g. what happens if someone gets access to fingerprint database?) 2) Add machine-readability support outlined in Tor Automation proposals: https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… a) which one(s) should we implement? JSON, YAML, XML? 3) Survey the literature for fingerprinting attacks published since Panopticlick. Implement those that may apply to TBB: a) Canvas & WebGL fingerprinting (Mowery et al.) - make sure the patch at #6253 works b) JS engine fingerprinting (Mulazzani et al.) c) CSS & rendering engine fingerprinting, (Unger et al.) ... 4) Check with realworld fingerprinting scripts to see if they collect anything that is not considered before. Check if TBB's FP countermeasures work against them. (We can use data from FPDetective study to find sites with fingerprinting scripts) 5) Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in case they consider an update. 6) Convert fixed FP-related bugs into regression tests. https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting… 7) Build test cases to check the severity of fingerprinting related open tickets, e.g.: https://trac.torproject.org/projects/tor/ticket/8770 https://trac.torproject.org/projects/tor/ticket/10299 8) Work on potential fingerprinting bugs that ESR31 may bring. 9) ESR transitions seem to create a lot of FP-related issues that need to be checked manually (e.g. #9608). Consider developing a tool that iterates over the host objects of two browsers to compare them automatically (e.g. to pinpoint new objects, new methods, updated default values, etc.). Similar to "diff tool" mentioned here: https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… 10) Evaluate the font-limits of TBB by checking the average # of fonts Top 1 Million sites use. We can either collect fresh data with FPDetective or use the existing (~1 year old) data. More on my background relevant to fingerprinting and TBB code base: We recently published a paper called "FPDetective: Dusting the Web for Fingerprinters" (CCS'13) to measure the prevalence of browser fingerprinting on the Internet. As a part of this study, we built instrumented browsers from Chromium and PhantomJS source code and developed a framework to detect fingerprinting (https://github.com/fpdetective/) I also got my hands dirty with the TBB source code to seek vulnerabilities in FP countermeasures. Two ways I found to circumvent existing font limits were as follows: https://trac.torproject.org/projects/tor/ticket/8270#comment:2 https://trac.torproject.org/projects/tor/ticket/5798#comment:13 Other pointers: My website: http://www.esat.kuleuven.be/cosic/?page_id=126 FPDetective website: https://www.cosic.esat.kuleuven.be/fpdetective/ My (first & only) Tor patch: https://trac.torproject.org/projects/tor/ticket/10472 My Tor FAQ profile: http://tor.stackexchange.com/users/731/gacar Looking for your comments, Cheers, Gunes N.B.: I won't be applying to GSoC. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTJmUiAAoJEPb7JcMmVt4g4jAH/2JLUKPGo52JpfsHeMtLZgQm JVoEELKuNVjwJ5KqgO4OhIqpS6yl/cggLsUe19fNrC5I++5w5lGWM3JRqCU/T5OV PLwRrs1lc1wU2zWkcKN/uvZyFys1xAsA2NzyYRZdKOjoGiDI8a3wgYM/o8a5PSt0 +wTJ6OdtRpFuXk9CrxUScx6kbLEYCoQeGcAmQe+ZIUWo6CzeQr/3yP8Jz7B3Uyqq ccSJACFuif2naQFiCDqyuQLIZu/9jMFGbYMg81OhZeeOWhmq4FwCjZOR8bzj8zqV i3N8hFXTRSYLjOg5AWVX+JMsCWJAX3rTrYe6X5GKA/tIm1gMJhwtedfaE38eHOM= =2stA -----END PGP SIGNATURE-----

3 6

Descriptor-id and responsible hidden service directorate. Changes in version 0.2.4.18-rc - 2013-11-16
by Frank Young 21 Mar '14

21 Mar '14

I have noticed that since the release of version 0.2.4.18-rc - 2013-11-16, Attempts to fetch v2 rendezvous service descriptor are failing. The issue seems to get worse as many people are updating their clients. The calculation of decriptor ids based on specification in rend-spec.tx <descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica))> doeesn't seems to be correct anymore. All 6 responsible hidden services directorates return 404 to a GET request for /tor/rendezvous2/<base32_encode[descriptor-id]> I search through the tor source for the release version (0.2.4.18-rc - 2013-11-16) in rend_compute_v2_desc_id and rend_client_refetch_v2_renddesc but failed to notice any significant change. Could any member of the dev team respond to to this?

2 3

GSOC- Revamp GetTor
by Kiran Mathew Koshy 21 Mar '14

21 Mar '14

Hi everyone, My name is Kiran Mathew Koshy and I'm a student of IIT Patna, India. I''m interested in participating in Google Summer of Code 2014 under Tor project. GetTor is a service that I had tried a couple of months ago when tor was blocked by our sysadmin, and I believe revamping getTor will have huge impact on avoiding censorship. *TL;DR version*: 1. A system by which a user has multiple routes of obtaining the tor browser- dropbox , mega, google drive, and a couple of other file sharing sites 2. If the user provides their pgp key, an encrypted reply can be sent 3. If the user requests so, the file sent should be password-protected , plus some random data(in a single file) should be added along with the tor browser in order to have variable file sizes. 4. Some file sharing sites(most) allow you to transfer a file between accounts. This is a bit unnecessary, but can be implemented if there is time left. 5. NLP: A very simple natural language processor to process the email and to scavenge for the requested configuration- language, os, file sharing site, etc. Example mail: "please send me a tor browser bundle ( English) that works on Windows. Could you send it through Mega ?" . 6. An email proxy- To counter the small chance that the mail server doesn't allow emails to gettor(a)gettor.torproject.org. Chances of this are low in my opinion, since gmail/ any other mail service is usually available. *Details and explanation*: 1. In most cases, a sysadmin or an ISP can block known bridges, torproject sites, and tor nodes. In this case, *the only way to ensure that a user can access the tor browser software is by allowing multiple sources to download it from. * The practice of blocking File sharing sites is also common, so sites like dropbox, google drive, box, etc are also important. The code will be written in a modular format such that addinga new file sharing site would be equal to adding a couple of urls of their REST API, or at most, writing a new module consisting of 10-15 lines of code. I have worked with the APIs of file sharing sites before, and most are quite similar. 2. If PGP keys are sent, an encrypted reply follows. No brainer. 3. Bundling the software with a file of random size into a password protected tar would prevent snooping based on size of the https request. A little bit far fetched, yes, but good if you are up against your government. This would prove to be cpu intensive and network intensive, since the server will have to encrypt the file and upload it to a file sharing site every time someone requests it. Therefore, this will be limited to one or two instances at any given time. It is also possible to upload multiple instances of encrypted tor browser software, and store the keys in the server. 4. Self Explanatory 5. An NLP would be very simple to implement in this case, in order to fish out the keywords and choose the correct configuration. Example mail: "please send me a tor browser bundle ( English) that works on Windows. Could you send it through Mega ?" . The keywords in this case would be: 1. tor browser bundle. 2. English. 3.Windows 4.Mega. A list of such keywords will be stored on the server. I believe an NLP would be better than the current arrangement. 6. Self Explanatory. Since the current getTor doesn't come close to this, I believe it is best to *rewrite it, reusing select parts*. I havce a good experience in C++ and Python. I completed Google Summer of Code 2013 under Wikimedia Foundation, so this is my second year for GSOC. Since I'm a bit late to apply, I will be submitting this as a proposal right away. Please comment on any changes you would like to incorporate in this. -- Kiran Mathew Koshy Electrical Engineering, IIT Patna, Patna, India

1 0

Tor Browser Weekly IRC meetings moved to 18:00 UTC Fridays
by Mike Perry 20 Mar '14

20 Mar '14

Due to the US Daylight Savings Time changes generating new conflicts for a few people, the Tor Browser team's weekly IRC meeting will now be on Fridays at 18:00 UTC in #tor-dev on irc.oftc.net, starting this Friday, March 21st. We will be snuggling up next to the Huggable^W Pluggable Transports team meeting, which is just before us at 17:00 UTC on alternating Fridays. Their next meeting is March 28th. The hope is that this will help us to work closer with them to polish up the new unified PT-enabled Tor Browser, add new transport types, and otherwise generate PLUR (yeah, I said it). For details on our meeting format, see the original post: https://lists.torproject.org/pipermail/tbb-dev/2014-February/000000.html P.S. We may have to revisit this time again when the EU switches to "Summer Time" on March 30th. Running an hour later in the EU may start to run into people's Friday evening plans, but we'll cross that bridge once it starts burning. -- Mike Perry

1 0

GoSC - Website Fingerprinting project
by Marc Juarez 20 Mar '14

20 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lunar: > Have you read Mike Perry's long blog post on the topic? > https://blog.torproject.org/blog/critique-website-traffic-fingerprinting-at… > > It outlines future research work in evaluating the efficiency of > fingerprinting attacks, and also mention a couple of promising defenses. Yes, I am aware of it and I'm currently working on a study to evaluate the efficiency of these attacks. As Mike Perry said in the post, most of the attacks give an unrealistic advantage to the adversary and probably countermeasures work much better than what has been shown so far. However, some of the results of these articles suggest that there exist coarse-grained traffic features that are invariant to randomized pipelines (RP, SPDY) and thus can still identify web pages (Dyer et. al.). Also, edit-distance based classifiers broke some old versions of the RP implemented in Tor Browser. It's an open problem to see if these features actually uniquely identify web pages in larger worlds than the ones considered in the literature. In any case, link-padding strategies are specially designed to conceal these features with the minimal amount of cover traffic and are becoming affordable in terms of bandwidth. The project I propose would be directed to address this bug ticket: https://trac.torproject.org/projects/tor/ticket/7028 For example, I would like to implement the common building blocks for link-padding countermeasures (such as a "traffic generator controller" in the onion proxy and the entry guard). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHz3kAAoJEGfJ5xfgazlxOwoH/ilP01mjxyyeuPbko/xkKGfw 5gMJGFa0m4StabJ1bhbqJWF2jsu6W2SBCVCqea0emvOvab0WzhuvQvzQb2obZpzr NReUhhiGRhj4xN+2yAL3Vh8zoyZigKtSQPoykwa/AFG7TvIGppHZb0S5ii7Hk/Yf UtwO3Kt3YCGJT3FoKEJQgN2wz82Skbo4Xiw0bknemPFmIkxlxyplkkD0D34OdEYx YPPxRBMuEnpa1H5H3bPMXK55kBP91qS5fg23hsN6Gksy45yhLeiOJZBi0n3nlHD2 xtp4sWdQhTUDFP85kSmbzW/eufuc4WAI6k5KeZtc5YrmIl9eOnAu+tG8Ghu4Vpc= =Rf6n -----END PGP SIGNATURE-----

4 7

Re: [tor-dev] Torbirdy
by mujnabed＠gmail.com 19 Mar '14

19 Mar '14

Hi, I've submitted my project proposal on Improving Torbirdy for review on Google Melange as suggested. If you guys can verify the proposal and suggest any modifications that would be great. My Name is Debanjum in case I haven't mentioned earlier. Thanks D

2 1

Interested in GSoC - Hidden Service Naming or Hidden Service Searching
by Jeremy Rand 19 Mar '14

19 Mar '14

Hi Tor developers, I'm interested in participating in GSoC. I'm an undergrad majoring in computer science at University of Oklahoma, and I've been a major Tor enthusiast for years. There are two possible projects which I'm considering; I'm looking for some feedback on which you think would be better for me to apply for. One project is allowing hidden services to have human-readable names. I think Namecoin would be an excellent backend for this. I coded a proof-of-concept of using Namecoin to point human-readable .bit domains to .onion domains; that code is available at https://github.com/JeremyRand/Convergence . For example, using this, you can visit http://federalistpapers.bit/ to get to the Federalist Papers hidden service. The proof of concept only works on Firefox right now (not TorBrowser); I would definitely be interested in porting it to TorBrowser, improving its privacy, and making it work for applications other than web browsing. Namecoin also has the useful feature of allowing HTTPS fingerprints to be embedded in the blockchain, which eliminates the need to trust certificate authorities for clearnet HTTPS websites (I understand that malicious exit nodes messing with TLS is currently a significantly voiced concern for Tor). I have a strong understanding of how Namecoin's DNS works and have developed some projects using Namecoin (including a dynamic DNS client), so I think I'm a good fit for such a project if there's interest in the Tor community. I talked with Jacob Appelbaum about using Namecoin recently; he was concerned about a 51% attack. I think that could be mostly resolved via a checkpointing system; while doing so adds a small degree of centralization, Tor is already slightly centralized, and it's still less centralized than other alternative naming systems that have been proposed (e.g. having Tor Project maintain a list of names themselves). While I'm not particularly familiar (yet) with how checkpointing is done within Namecoin's block validation system, I do know how to at least verify whether the currently loaded blockchain matches a given checkpoint (which would at least alert users that an attack had taken place). The other project is making a search engine for hidden services (listed as Project Idea F on the Tor website). I think YaCy could be used to accomplish this in a decentralized and censorship-free way. I would suggest making a separate YaCy network for hidden services, using a regexp whitelist to only index .onion URL's (YaCy has such a network but I think it's currently inactive). YaCy doesn't have whitelist support built in, but I think the blacklist feature should be usable for simulating such a feature with some effort. YaCy's SOLR schema supports searching based on outgoing link URL's, so I think I could make a standard YaCy client search for all clearnet sites which link to a .onion/.onion.to/.tor2web.org URL, and feed those URL's to a Tor YaCy client for indexing. I've been a YaCy enthusiast for a couple years, and I'm actually using YaCy in a grad-level CS project this semester (the course is on Artificial Neural Networks and Evolution), so while I haven't touched the YaCy source code, I think I'm a good match for this project. Do either of these sound like good proposals? Is one significantly more likely to be approved than the other, so that I know which to submit? Thanks, -Jeremy Rand

3 7

Re: [tor-dev] Panopticlick summer project
by Yan Zhu 18 Mar '14

18 Mar '14

(resending to tor-dev because the original message didn't go through) On 03/16/2014 11:52 PM, Yan Zhu wrote: > On 03/16/2014 07:59 PM, Gunes Acar wrote: >> Dear All, >> >> My name is Gunes Acar, a 2nd year PhD student at Computer Security and >> Industrial Cryptography (COSIC) group of University of Leuven. >> >> I work with Prof. Claudia Diaz and study online tracking and browser >> fingerprinting. I'd like to work on "Panopticlick" >> (https://www.torproject.org/getinvolved/volunteer.html.en#panopticlick) >> summer >> project and other fingerprinting related issues which I tried to >> outline below: > > Hi Gunes, > > I think all of these projects below would primarily be with EFF, not Tor > directly. Peter and/or I would be your point of contact; I'm not > familiar enough with Panopticlick at this time to give you much feedback > on the ideas below, so I cc'ed Peter. > >> >> 1) Collaborate with Peter@EFF to port/open-source Panopticlick: >> https://trac.torproject.org/projects/tor/ticket/6119#comment:4 >> a) implement necessary modifications - e.g. we won't be having cookies >> or real IP addresses to match returning visitors. >> b) consider security implications of storing fingerprints (e.g. what >> happens if someone gets access to fingerprint database?) > > Peter, what's the blocker on this? It sounds like Tor folks really want > it to happen soon, so I'm happy to take the lead on helping get this > open-sourced from the EFF side. > >> >> 2) Add machine-readability support outlined in Tor Automation >> proposals: >> https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… >> a) which one(s) should we implement? JSON, YAML, XML? > > No input here. > >> >> 3) Survey the literature for fingerprinting attacks published since >> Panopticlick. Implement those that may apply to TBB: >> a) Canvas & WebGL fingerprinting (Mowery et al.) - make sure the patch >> at #6253 works >> b) JS engine fingerprinting (Mulazzani et al.) >> c) CSS & rendering engine fingerprinting, (Unger et al.) > > This sounds greatly useful. Another good place to look is Mozilla's bug > tracker (https://bugzilla.mozilla.org/) > >> 4) Check with realworld fingerprinting scripts to see if they collect >> anything that is not considered before. Check if TBB's FP >> countermeasures work against them. (We can use data from FPDetective >> study to find sites with fingerprinting scripts) > > Same as above. > >> 5) Backport new "attacks" found in 3 & 4 to EFF's Panopticlick in case >> they consider an update. > > Yes, I'm happy to get those updates into EFF's instance. > >> 6) Convert fixed FP-related bugs into regression tests. >> https://trac.torproject.org/projects/tor/query?keywords=~tbb-fingerprinting… >> >> 7) Build test cases to check the severity of fingerprinting related >> open tickets, e.g.: >> https://trac.torproject.org/projects/tor/ticket/8770 >> https://trac.torproject.org/projects/tor/ticket/10299 >> >> 8) Work on potential fingerprinting bugs that ESR31 may bring. >> >> 9) ESR transitions seem to create a lot of FP-related issues that need >> to be checked manually (e.g. #9608). Consider developing a tool that >> iterates over the host objects of two browsers to compare them >> automatically (e.g. to pinpoint new objects, new methods, updated >> default values, etc.). Similar to "diff tool" mentioned here: >> https://people.torproject.org/~boklm/automation/tor-automation-proposals.ht… >> >> 10) Evaluate the font-limits of TBB by checking the average # of fonts >> Top 1 Million sites use. We can either collect fresh data with >> FPDetective or use the existing (~1 year old) data. > > All of the above sounds fine. > > Assuming that we can get Panopticlick open-sourced, I'm more than happy > to help you with any of these subprojects. > > -Yan > (EFF Staff Technologist / HTTPS Everywhere maintainer) >

3 3

Re: [tor-dev] Torbirdy
by mujnabed＠gmail.com 18 Mar '14

18 Mar '14

Hi, Thanks for the feedback. I have done some work in javacript and c++ and am comfortable coding in both, which is one of the reasons I chose the project. So I'll go ahead and submit my application at the max by tomorrow. Also can I edit the final project proposal once its submitted to melange ? Anyway thanks for all the help. Regards D

1 0

Another weekly tor dev meeting, 19:00 UTC on Wednesday 3/19
by Nick Mathewson 18 Mar '14

18 Mar '14

Hi, friends! This is another developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) We're going to try doing the weekly meeting on Wednesday. The meeting time will be: Wednesday March 12, 19:00 UTC. (That's 3pm EST and 12:00 noon PST) As before, we'll do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. peace, -- Nick

1 0

[RELEASE] Torsocks 2.0.0-rc5/6
by David Goulet 17 Mar '14

17 Mar '14

Hi everyone! Here is the release candidate 5 *and* 6 for Torsocks 2.x. Unfortunately, right after the release 5, I've noticed a critical issue that made the new allow inbound option misbehaved quite badly so I'm immediately releasing rc6 containing that fix. Basically, you can ignore rc5 if you prefer. Sorry for that! A new option has been introduced to allow inbound connections (that were previously blocked in rc4). The torsocks.conf new option is "AllowInbound 0|1" set to 0 by default meaning listen/accept is *blocked* for remote connections only so the localhost is *alway* allowed. This fixes the "ssh -L/-D" use cases to open a listening socket. Again, *by default* any localhost socket will work so this example out of the box should work properly: $ ssh -D8080 yourserver.com You will notice a "listen: Operation not permitted" with the above command because by default ssh tries to connect to IPv6 localhost but fail somehow. I'm aware of the issue but will need much more investiguation to fix but it's not a show stopper. Furthermore, whois was not working because fclose() is used to close the socket and torsocks was not tracking that call thus failing to see the close connection. This was NOT triggering any leak but whois was simply not working. This has been fixed which is an important use case for Tails. Here is the change log for both versions. 2014-03-17 torsocks 2.0.0-rc6 * Fix: set addr len for getsockname in accept * Fix: use socket fd and NOT sockaddr in accept 2014-03-17 torsocks 2.0.0-rc5 * Fix: strict aliasing in library * Add fclose() support * Fix: add torsocks.conf option type * Add option to allow inbound connections * Fix: handle NULL node in getaddrinfo Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Git: https://github.com/dgoulet/torsocks.git (mirror: https://gitweb.torproject.org/user/dgoulet/torsocks.git) Github tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc6.tar.gz TPO Tarball: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks-2.0.0-rc6.tar.bz2.asc) Cheers! David

2 1

A simple HTTP transport and big ideas
by David Fifield 17 Mar '14

17 Mar '14

Here is a repository containing a simple HTTP-based transport. git clone https://www.bamsoftware.com/git/meek.git cd meek/meek-client export GOPATH=~/go go get go build tor -f torrc Usually when you think of an HTTP transport, you think of something that steganographically tries to make something look like plain HTTP requests and responses. Try and forget that idea for now, because that's not what I have in mind. The protocol is simple. The client generates a random string to serve as a session id. It puts this session id in a POST to the server. The server has a map from session ids to ORPort connections; if the POST's id is not in the map, the server creates a new ORPort connection, otherwise it uses an existing one. The server copies the POST body to the ORPort, and copies a block of data from the ORPort to the HTTP response. The client receives the response, and when it has more to send, it does another POST (with the same session id). Then repeat. How do we prevent 1) fingerprinting of the HTTP requests and 2) blocking of the HTTP server? The answer to (1) is that the HTTP requests are really HTTPS: the censor gets to see where they are going but not what is inside them. The answer to (2) is hinted at by the Bridge line: Bridge meek 0.0.2.0:1 url=https://meek-reflect.appspot.com/ front=www.google.com We use Google App Engine as a middleman, using a trick to make it look as if we're talking to www.google.com. This transport can get through as long as https://www.google.com/ is unblocked, even if App Engine is blocked. (Up to things like TLS fingerprinting and traffic analysis, which we need to think about.) Like flash proxy, this transport doesn't need bridge distribution. The torrc has everything you need to make it work. Unlike flash proxy, it works without any port forwarding games. Now for the big ideas. This transport is similar to https://trac.torproject.org/projects/tor/wiki/doc/GoAgent in its use of App Engine. However, GoAgent requires every user to upload their own instance of the app server. I propose that we run a server for use by the public and see how much it costs. (App Engine's free tier gives you 1 GB a day and above that it costs money.) If the cost is comparable to that of running a fast relay, it might make sense to fund on an ongoing basis. As a student I have $1000 in App Engine credit that I wouldn't mind burning on the experiment. A simple PHP script can do the work of the App Engine server component: all it does is copy HTTP requests and responses. By using PHP as a middleman, you lose Google's too-big-to-fail unblockability, but you gain an easy way to set up lots of bridges. Such a PHP bridge would not even require a shell account, just a PHP web host. Conceivably such bridges could even be distributed through BridgeDB. Thinking about transport composition, scramblesuit|meek could be an interesting thing. What this would mean is that your client makes an HTTP request to some server, containing a POST body with the beginning of a ScrambleSuit conversation. If you have the shared secret, the server replies with 200 and you start communication. If you don't have the shared secret, the server replies with a 404 (or even 200 with an ordinary web page). What it means is that there can be a magic URL that only you (holder of the shared secret) can use as a bridge. It could even be on a real web site with real pages and everything. ScrambleSuit would additionally provide some diversity of packet lengths and timing. The Google fronting trick, it turns out, also works on CloudFlare sites, which are many. If we ran a bridge as a web app on CloudFlare, even if our web app is blocked, a censored user could access it through the name of any CloudFlare site that supports HTTPS. There may be other CDN-like systems that work similarly. The software is working (try it!) though of course there are always lots of things to do. I'd like the client to be able to pin the certificate of www.google.com. We need the client to use TLS that looks like that of a browser (now it is just using Go's built-in HTTPS support). There are some constant buffer sizes and polling timeouts; they can probably be tuned for better performance. David Fifield

1 2

Re: [tor-dev] Torbirdy
by D 17 Mar '14

17 Mar '14

Hi Sukhbir, Thanks for the quick reply and clarification. > We already have code ready for generating random > message-IDs Yeah I saw the SHA-512 based random message-ID insertion in your Thunderbird+Tor paper. >> 3. And using extension hooks with explicit calls instead of checking user >> set configurations flags for removing timestamp data from header. This it's >> suggested will allow better handling of messages received/sent in the >> background by Thunderbird. > Yes, that's correct. Figuring out how to do this and doing it properly > is the only blocker Right, so start with fixing the preference setting system using extension hooks instead of preference flags. Then work with the new preference system on issues #6314, #6315. Finally, verify stability across different MUA's,MTA's for the updated patches, submit the patch request to #902573 & #902580 and work with Mozilla for patch request acceptance. Does this process flow sound reasonable ? Should I give a more elaborate write-up on the it for you to proof-read or should I just give you the final project proposal for proof-reading ? The only prior experience I have with extension development was on Gnome and it was minimal. But I've started reading up on extension development in Thunderbird and the Torbirdy code. Should be able to run by you a more detailed project proposal soon. Thanks D

2 1

GsoC - Interested in "Revamp GetTor"
by Israel Leiva 17 Mar '14

17 Mar '14

Hi! My name is Israel Leiva, I'm a computer science student at University of Santiago, Chile. More info about me in [1]. I'm interested in the 'Revamp GetTor' project for the Google summer of code. I think that GetTor has a huge impact on how to avoid censorship, and therefore it could be expanded to do a lot more of what it does now. Here is my idea: i) A modular design, with a core module in charge of transmitting data to the others modules, each one of them would represent a different "service" (e.g. SMTP) ii) The core module will be in charge of receiving requests from the other modules and answer them. For example, the SMTP module will say "Give me the URL links for TBB in this language" and the core module will answer with the desired links. These links could be retrieved from several locations, my proposal is that the links could be stored in a private git repository available only to trusted Tor developers, so the links and other data could vary with time according to the different censorship behaviours. iii) As I said, the other modules will each represent a different "service". I propose the following three for starting: * SMTP: Enhance the current bot. I tried it a couple of days ago and it didn't work as I expected (sent me a windows link when I asked for linux). * Twitter: this module will answer requests via twitter, either via mentions or via direct messages. It will ask for the corresponding links to the core module. There are lots of bots implemented out there, no need to reinvent the wheel. * Skype: this module will listen for calls or chats and will answer with a file transfer or message with the links. I believe this can be done using the sevabot [2] in Python or the Skype::Any [3] in Perl. The main idea is that this new design would allow for new services to be implemented in the future. ** OTHER IDEAS ** Here are some minor ideas that could also be considered: a) Most OS bring tools to make DNS requests, and an (experimented) user could make custom requests for TXT records that contain links. I know this isn't the case for most people, but it could be helpful. b) Users could send formatted mails with their public PGP keys to the SMTP service, and the bot will answer them with encrypted content. c) Users could notify services with censored links, this means that if, for example, a user requests the links via SMTP and one of them has been blocked, he/she could send a message notifying this to the SMTP service. This info along with stats about which services are more popular will be saved in a log file (I think this is how is working now) and/or a database. The purpose of this data will be to enhance GetTor, no info about users will be recorded. d) Other option to storage could be Github (as you may know, repos can be downloaded as ZIP files). e) For all the above, GetTor will need official twitter/github accounts. f) Comunication between modules could be done via system commands, but I'm open to any other suggestions. This communication will involve sending links (trusted servers, github repo, dropbox accounts) or local uris (~/tbb/latest.tgz). A basic diagram representing what I've tried to explain can be found on [4]. I think the best way to achieve this is to rewrite GetTor, but if you choose extend the current code to do it I'm okay with it. If you choose the former, I could do it in Python, eventhough I have a lot more experience in Perl (I've coded a module to automate the grading of programming tasks [5]). This is just a draft, please let me know if you find this is the way to go and I'll work in the details and a possible timeline to see how much can be done in 4 months. [1] http://ileiva.github.io [2] https://github.com/opensourcehacker/sevabot [3] http://search.cpan.org/~akiym/Skype-Any-0.06/lib/Skype/Any.pm [4] https://raw.github.com/ileiva/Tor/master/revamp-gettor-simplediagram.txt [5] https://metacpan.org/author/ILV best. -- israel

2 2