- tor-dev - lists.torproject.org

yes hello, internet supervillain here
by Fears No One 09 Nov '14

09 Nov '14

Sorry in advance for the length. I just want to make sure that everything is included. If you have any questions/clarifications, just ask. It isn't every day that someone like me pops up on tor-dev, and I just want to make sure this is as productive and helpful as possible. This will probably be a very humbling experience, because unlike my fellow illegal onion operators both past and present, I will actually be outside of a jail cell and able to read the ruthless dissection of my set-up. On the bright side, you're all are getting way more info from me than the pigs will ever willingly cough up, which means if they have some sort of magic onion decloak trick, this mailing list discussion is a good chance at finding it. All of these files are in the hands of the cops anyway (And I have no plans of bringing doxbin back), so there are 0 real-time opsec concerns. First, the files: http://doxbin.strangled.net/ http://qhlkmirbijvet2dp.onion/ sha256 and sha512 checksums for all the files are at the bottom. NOTE: This isn't my box and I didn't set it up. WARNING: The .xz files will unpack to roughly 1 GB. Some other info: 1. The box (An OpenVZ VPS) was hosted with Hetzner in Germany. People on Twitter keep asking if the box was in Bulgaria, but we didn't use Bulgaria for one simple reason: The very first doxbin box (Bought in 2011) was with a VPS company in Bulgaria. After the first month, they said "TOR IS ILLEGAL" (I shit you not), killed the box, and kept the $5 we had paid for the 2nd month. Can't say I blame them. 2. It wasn't transproxied. We did this once before, but it became a hassle to drop iptables rules just to upgrade tor, especially when tor was getting regular updates semi-recently. Console access with VPS companies generally requires java plugins or something just as gross, so there aren't a lot of sane options here. It gets annoying when there's a surge in the frequency of tor upgrades, so we stopped transproxying the box. inb4 OMG OPSEC MISTAKE DETECTED!!!11 3. This script (And copypasta that contained its important parts) was used to build nginx for the various boxes from roughly November 2011 to mid-October 2014: http://pastebin.com/dBC7E8Jd Early versions didn't use naxsi, and sed replaced the server banners in the source before compiling. Yes, I know it doesn't verify the source. See the next point: 4. Around 2 weeks ago, I started grabbing dotdeb.org's source versions of nginx and building .debs using hardening-wrapper with the following command at the end: DEB_CFLAGS_SET="-O2 -fstack-protector-all -fforce-addr -ffast-math -fomit-frame-pointer -falign-functions=64 -falign-loops=32" dpkg-buildpackage -uc -us -j8 5. The tor build was from deb.torproject.org. I'm not able to check the box and never thought to back up /etc/apt/sources, but it used the experimental-wheezy repo. All updates were done within 24 hours of the new .debs going live. 6. Last but not least, the elephant in the room: The php is a headache-inducing nightmare. I inherited the code and it worked, so I just papered over its defects over the years (There was no anti-flood protection originally, for example) and built it up to resemble Kowloon Walled City expressed in php. I have a feeling that a lot of focus is going to be placed on the code, to the detriment of finding any possible tor bugs. In any case, everything about doxbin's setup is being disclosed in the spirit of making this an interesting learning experience for all parties involved. BEGIN TINFOIL Upon scrolling through the .xz files (I personally use xzless), you'll find a bunch of stuff like: 1 /%5C%22http://www.hackforums.net/code/fail/code/code/code/code/code/code/old/code/old/code/old/code/code/old/fail/fail/code/fail/fail/fail/fail/fail/fail/code/old/code/old/code/fail/fail/old/old/old/code/code/fail/fail/code/code/fail/old/code/old/old/code/code/fail/code/code/code/old/old/code/code/old/old/old/code/old/fail/fail/old/code/code/old/code/code/code/fail/code/code/code/fail/code/code/fail/fail/old/code/code/code/code/code/code/old/fail/code/code/code/old/code/fail/old/fail/code/code/fail/old/code/fail/fail/code/code/code/code/fail/fail/code/code/old/old/code/code/old/old/old/code/code/old/code/old/code/code/old/old/old/old/code/code/fail/code/old/fail/code/old/code/code/code/code/fail/code/code/code/code/code/code/old/code/code/fail/code/code/code/code/code/code/old/code/fail/fail/fail/code/fail/old/fail/old/fail/old/fail/code/code/fail/fail/fail/code/code/code/fail/code/code/old/code/code/old/fail/fail/code/old/old/fail/old/code/old/old/old/old/old/old/old/pgp.txt All of the requests were around (If I recall correctly) 3KB in size. Oddly enough, it caused tor to hiccup pretty badly, although the web server itself was just fine and I didn't have any network bandwidth problems (i.e. No obscene traffic spikes). It's also worth pointing out that the tcp buffers weren't even close to maxed. The same box has handled a similar volume of legitimate requests before (Namely back in March, after The Hidden Wiki debacle; see https://twitter.com/loldoxbin/status/530765088366821377) The solution to getting tor availability back was to set ConstrainedSockets to 1 and play with ConstrainedSockSize (Originally set to 8192, then 4096). This made doxbin regularly available again, whereas before it was hit or miss. Once the requests stopped, I waited a couple of days before commenting those two config lines out and reloaded tor. A month later, the same kinds of requests started coming in again. After the first few hours, I started 301 redirecting all requests containing /%5C%22 to the new Hidden Wiki's Hard Candy page. I also added a grep -v to my log report script in order to filter out the noise (Possibly a mistake, but we both tailed logs and watched for something like a different attack style that the ddos was being used to cover and never noticed anything). That was good enough to maintain availability, so I rolled with it and the requests eventually stopped. I have no hard data on that last point, just the fact that I tailed the access log and the requests went from 5 per second to 1 every 3-6 seconds before dying off completely. I said on Twitter that we suspected it was a deanonymization attempt, but I didn't elaborate why because LOL 140 CHARACTERS. Intangir (The other admin, who took over for me from Halloween 2013 to some time around July of this year) and I talked about it back in August and decided that an attacker was probably involved spraying specially crafted packets at the box in order to mess up its circuits, and eventually get us on attacker-controlled nodes. Since we mitigated the availability loss, we deemed it as no big deal. In hindsight, that seems hilariously stupid/naive of us. The kid who started doxbin had a similar theory that I'm just going to paste verbatim: <founder> ANYWAY <founder> i think <nachash> CONTINUE <founder> the attack <founder> was to DoS you <founder> until you created circuits <founder> entirely made of dickbleedable nodes <founder> and then dickbleeding them <nachash> but the server <nachash> got seized <founder> yeah, the IP was discovered by dickbleed though <founder> the entire circuit was leaking info <nachash> lol, did you just reproduce this? <founder> not yet, i'll be trying <nachash> Do you mind if I share this with tor devs? <founder> go ahead <founder> its just a theory at the moment If either of these theories even remotely pan out, a possible mitigation for the next person like me (Which shouldn't require any tor dev work) might look something like this: 1. Make several public relays and configure the torrc of the hidden service to only make circuits which begin with those nodes. Private bridges would be a liability in this case because anyone who figures out the guard node by weaponizing one of attacks from a whitepaper (Which guard nodes were modded to mitigate) will be able to find the guard node and then quickly discover that it isn't part of the public tor network. Public bridges might be ok, but probably less so. 2. Cross your fingers and pray really, really hard that the money trail is correctly obscured. 3. ???? 4. PROFIT! (Or lulz, in my case) (No, the similarity between the idea of drug market operators giving back to the network by donating nodes to the practice of drug cartels building schools and hospitals is not lost on me) Another thing to consider is the recommendation against running a hidden service as a relay. Of course, the argument against doing so in the documentation is very sound. At the same time, the FBI has stated in the Silk Road criminal complaint that upon finding the IP, the investigator verified that it wasn't a tor node and knew he had won the onion lottery. Of course, that could still be psyops/parallel construction garbage to scare people into making their jobs a little easier, but it's something to thing about. END TINFOIL sha256sums of all the files: 04261115c2ca8d28c439ee16926e271479b8626cc9403d31d686317227f9f4b0 archive.php.txt 2811be83aa41666f245432a1a562a3ac6c7035a59a16beae09571a71723e734c captcha.php.txt c5b9bff30748b8d68666f6d4687757f955cde96e67bbb00edad703af45b776ae doxbin_2014_08_21.txt.xz cde066ef290ee22c8d78a34af17d33a393845105d21f9fd96db93e0a51290b77 doxbin_2014_08_22.txt.xz 43ec183ee7efc3e9d14d084e50fe054ac6ffb60919e596a8dc4824f116fa1d83 doxbin_2014_08_23.txt.xz 3e630b3843341926ab7667a41a023fa4d63a38d01a5a3549a66f8bc98507cd39 doxbin_2014_08_24.txt.xz 20af2efec930e477fe5595eee66418f87af047ad4316ffc399761002c2d5f45d doxbin_2014_08_25.txt.xz 1c24eecbc98456a4c2f489a6012a48ec2119927402e7dd1ac12cff7732d04192 doxbin_2014_08_27.txt.xz afcdafc5293b6a9dbe402da65522f01a231f3f9727a4e597e70cf44321f96c2f doxbin_php.txt 66d495a5d21df855eedc6e3493a159b2b522b1b8170610c7c7e013f31d01e0ba doxviewer.php.txt 34611133cb4da451fc45f09e2ca6a08a71267439755b68608cbbc9b2a151ccee error.php.txt f37e6be62b149e40fb604cef90313d321f2bf4d2156808ef997a82004307c22f faq.php.txt 10bc8b38757ad7b27576488a37cec4a2f9dd0ed2ef467cc605ac0da8e83f3e23 index.php.txt 9596d7339f7a89eca7f18dd36cc2f433cdaa23700497816a6a71889158f90bc7 legal.php.txt 912241933303556097d60b890bac18be4577cbefaa6794088b256a3bf1f3796e naxsi_core.rules.txt 36bfb91a072d43a07de816d78a7cae8b7350a7f8069798468c8f3556acbeab9b nginx.conf.txt 66df06cdf6e6aba5dab8655e72c30bc5020f2319db1329c2f93bc74e96a96ac4 post.php.txt b9c12279b289a56702c9a3dc9b873b453ca4642efbcacba597c8bd252a9092ab privacy.php.txt 728fb96cbecafd974a9afc3211e8d9eb7bbb49f73e3ccb64fe9f7390341b3d38 proscription.php.txt ae0b124f3ccd849653ef806b10dd41cf316ffd45ef5d8d5af8c2d117027835e4 resources.tar.xz 7ba7ab341f29fc6d5a449bcd2f18c8962b8475b34c8b5745676da4f4c8e51a90 search.php.txt 6aa7c5dbe7aaa25b729ab542e0396f7f7d322244935ea4c0ad0e468b01d19374 thw.php.txt sha512sum: 7a0e5eaed12d6f7134c56cdd6e68e8255e49c00897fe05701abb84e91d215ed23f462d6b0485467da04a2d7c0a51d5e6a3fece943d9ce2137321a0913448afec archive.php.txt 804d679233f811aa66ca6fbc370e0734c7ba830959165496c66a0585637e4c5f966e6dfcbed618bea65ab11aa2f49351840376abc553e74c84001cf5e737da2b captcha.php.txt 734adca606f984fce830ebb5d5a05dee0c75d06ff05498483ff057cfd879f670f1a6bd42f5ad090bd63edd0f54d8eed86a0aa04cfe60669c11ac141f271ec366 doxbin_2014_08_21.txt.xz c9b55b8b9cf3d3f5820b8cde5b3de77cd609b17c1f6c234118b4b632978a8ef131227500fac66e2238756014437672178515ba028b70f8dc29b0b3b7ef158632 doxbin_2014_08_22.txt.xz c63ab075b0383be0703c97bf9fbe42e1dbb3f1ab01eddddbe1752af12bd38a71d6906c2c4c18695b0afa091049ca8583a86b747690cea17c45bd4edcaf269611 doxbin_2014_08_23.txt.xz 4486fbf61e5132a6167f46c7ec88f7fe25d879e72094d43b3189f786ad84a4e3fd75adc76fddf4ece26b7b670091d29e6a5e7631fd0660b4d549cc49d2e8bcfc doxbin_2014_08_24.txt.xz 1ac1e9359092d77e0a13a404ea428cc396b22a8f89dd7bb3241a80a4aa16a3d769aacf0289d1c83e3e367e24ca0a922ca9b3d950a14f962defd6f7c69c62cc63 doxbin_2014_08_25.txt.xz e6722d43221a13d6df3f521b040d11a17cd27a63017a73893bf25396468127bbb7f8d81b1b4c7c0aba52e82b09419e63c3df9df877c68fc7603fc9f19b8bda20 doxbin_2014_08_27.txt.xz c9d20c82b473260473824ed4909c165f10a3a1a93405cab1ac28d8ae17ee839754998f0d6e7e78c09fec4e21bf4efd6c65ece4734c87f437199cd256cd6756ab doxbin_php.txt b73db1ceefdc501f6ec0fd52c368a88f1e88d80049ed2824fb4a8c60d2c70a87079528f1a043bca6fd2d073ce186eb87531a9cf69b449f537a041786e4f634f3 doxviewer.php.txt 4f4702f4f4970f67f73b23ca357f764f62eddd63a6fa7878d1c0aeaa2f48ed3813e84261a278ee396aa3e0c6dbe4e5333d8d83b85d173e13be9bea337cf7a678 error.php.txt 6cfc57fd6f3aaf9a7829b83f8a43852e965dc11929be29f59c494bd8b5723b0fee9aa9ccdc734b8bb07127555d14a8619343061d6fe88508afe7f9ba569ac376 faq.php.txt d568388cd9abcad5c0db31a25feef410f7a1a1b26ca3d542b38d1e75c232dbc6d852040dffb3d754d74aac6ecf04e996844b673d4b74ac00c05bb920f63528d1 index.php.txt 35164a260e89a3ef296460ebfba7b3f5b902b4594fcbc5871e1b431f6c4b89c2e80ae372c50fd6a30d50edeaa94e7326c0cbefca92537e37a3deddbfa610e8f7 legal.php.txt 93fcbfd36e299239ec2e350fc9a768b9c819089a6922aa997c377d205e7895cd3f6beef00fbadf7de0e02f26efd3ce7a0e47c5d927ae5eb4c9c256c4be58855e naxsi_core.rules.txt 1c0ac0e10e715ef8049ea7d1ae3fc635b96a9d62811137e98a4c3794f8ba86f5b66ea883d5ebe939d7cb607cc575e04d8c47ee4ddaabf0887ef44e99c56c4a0a nginx.conf.txt 3f29d8d34bc91e1114f089a937bf736b7b74837f5aeb834ae0ace6e7612e2b401bc8f769fa74a432533d92c28b7165eb31dc40eb7ffbfaf82dd870815cc4e189 post.php.txt 8079dff1ceb2309d98198d3503db8bdaeb38bcdf9679548e8fe7ce1a8bbc87506f8d165713d90c7d2f6316031c1bd7eb7765441d325741c8bd5ca6bc2a6a2843 privacy.php.txt a1f6d218a2f65617203d53fbbf625da362d9f2e2676fbc1a28491a1717a6c21367b0a241bd1599c336be2d31d085717b16b3efaffeb383e0a11ce73839ce648f proscription.php.txt 94b8bd2fb8b25880e1c25d5fcf60ebe93d3c42857ef61cdf5261dfcaaf1d34cc5d085c358793d22dc7cfd66dcb7628f0eb9953560c3c646d2b7abc08a368c4d3 resources.tar.xz 0fee75a98e3f8ae4d0c578af399144c49382c7680626cc62e01aa250fad11d1aea522e87ec8e79e6136632bd54bffe681b2ecc283e1d56a7e75b7ab17f7e2319 search.php.txt e69bdba3aeb6c94a3b785b96385fafe0ec58e66688333f423004da1a4725bd54666f1e0b427d52068cdbefa430146162f1511c3c0930ea4379f6b022756a48bf thw.php.txt Hope this helps, - nachash

5 6

Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
by teor 09 Nov '14

09 Nov '14

Hi All, A "privacy everywhere" solution could have two components: 1. the HSTS-like "always open this site in .onion" policy already discussed; and 2. an AppLinks or AppLinks-like[1] header that specifies a preferred app and/or URL for Tor, I2P, namecoin, … The first handles the situation where you're already in the Tor browser, I2P, namecoin, and simply wish to pin the .onion etc. URL for that site. The second handles the situation where you're browsing the web in your standard browser, but want to switch to a .onion site in the Tor browser if one is available (or the equivalent namecoin or I2P action). AppLinks is mainly designed for mobile platforms, but has Windows schemes as well. I could imagine schemes like: al:onion:url https://facebookcorewwwi.onion al:onion:attribute value al:namecoin:url https://... al:namecoin:attribute value al:i2p:url https://... al:i2p:attribute value What do you think? I wonder if this is helpful, or could just end up being out of scope, duplicating effort, or abusing the AppLinks protocol design (which is focused on an app per platform, not multiple options for alternate URLs). T [1]: http://applinks.org/documentation/#applinknavigationprotocol teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w… > On 3 Nov 2014, at 23:00, tor-dev-request(a)lists.torproject.org wrote: > Date: Mon, 03 Nov 2014 00:12:53 -0600 > From: Jeremy Rand <biolizard89(a)gmail.com> > To: tor-dev(a)lists.torproject.org, https-everywhere > <https-everywhere(a)lists.eff.org>, namecoin(a)googlegroups.com > Subject: Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi Yan, > > Namecoin would definitely be interested in something similar (we were > actually discussing the possibility of exactly this yesterday). Maybe > we could produce a list of relevant projects that would benefit from > this? (The three that come to mind immediately are Tor, I2P, and > Namecoin, but there may be others.) If there are more than a few > projects that would benefit, then it might be interesting to find a > neutral format for the HTTP header, so that we wouldn't have to list > all the supported TLD's explicitly in the spec. > > (CCing to Namecoin dev list.) > > - -Jeremy Rand > Lead Application Engineer, Namecoin Project > >> On 11/02/2014 11:48 PM, yan wrote: >> +tor-dev. tl;dr: Would be nice if there were an HTTP response >> header that allows HTTPS servers to indicate their .onion domain >> names so that HTTPS Everywhere can automatically redirect to the >> .onion version in the future if the user chooses a "use THS when >> available" preference. >> >> I imagine the header semantics and processing would be similar to >> HSTS. It would only be noted when sent over TLS and have the >> max-age and include-subdomains fields. >> >> -yan >> >> yan wrote: >>> Hi all, >>> >>> Some people have requested for the "Darkweb Everywhere" extension >>> [1] to be integrated into HTTPS Everywhere. This is an extension >>> for Tor Browser that redirects users to the Tor Hidden Service >>> version of a website when possible. >>> >>> I'm supportive of the idea; however, I'm worried that since >>> .onion domain names are usually unrelated to a site's regular >>> domain name, a malicious ruleset would be hard to detect. AFAIK >>> Darkweb Everywhere only defends against this by publishing a doc >>> in their Github repo that cites evidence for each ruleset [2]. >>> >>> What if, instead, we asked website owners to send an HTTP header >>> that indicates the Tor Hidden Service version of their website? >>> Then HTTPS Everywhere could cache the result (like HSTS) and >>> redirect to the THS version automatically in the future if the >>> user opts-in. >>> >>> If this is something that EFF/Tor would be willing to advocate >>> for, I would be happy to draft a specification for the header >>> syntax and intended UA behavior. >>> >>> Thanks, Yan >>> >>> >>> [1] https://github.com/chris-barry/darkweb-everywhere/ [2] >>> https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.… > _______________________________________________ >>> HTTPS-Everywhere mailing list HTTPS-Everywhere(a)lists.eff.org >>> https://lists.eff.org/mailman/listinfo/https-everywhere >> >> _______________________________________________ tor-dev mailing >> list tor-dev(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQEcBAEBAgAGBQJUVxzXAAoJEFgMI9bDV/9qY3UIAJrl5LI/1OHJngu1W9DsLAjr > nh+Csnm66z5tQTwiwva1Tb4b6trHv4KkHItaTm0cI44mQNsd+YEkh0oRBTSNNcRm > HY0BDn2pqTlQPN9bWvclGEtCacevCbaQiZgPpxPa+1crtavto4VAnv0/EI85QVAe > XHUNBeAHmB3qNATXsVJ61oksWlU/x8ao62fB13cUd2fVyaasWz4PPsAJ9n3TkdYG > /el7mAuM6XdA1fFaGFd1ta0jRuER2VgKQvJQctu/6a/9jiNlib3YmMOOxvF0WR+/ > foUdhFkNCmRWwxqnxFDiKM0ilRLjTQ47CYRkgkqD4azPlkNvUULbO3KhaWPB9/4= > =rUsH > -----END PGP SIGNATURE----- >

2 1

Re: [tor-dev] [tor-internal] HS attack blog post (was Re: Hidden services and drug markets takedown)
by A. Johnson 09 Nov '14

09 Nov '14

I think the option to rate-limit guard selection is a great idea to defend against guard DoS. The downside is possible connection loss even if you’re not under attack and you just happen to pick flaky guards. In case you’re interested, I examined this defense and how often such benign service loss would occur in section 6.B of "The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network” <http://ohmygodel.com/publications/sniper-ndss14.pdf>. Table 6 shows the probability that this happens for a Tor client that operates continuously for two months (after 2-3 months all guards will have expired and the process repeats). If, for example, you are willing to require only one active guard (a_g=1) and you limit yourself to no more than 4 new guards (r=4) chosen in the last 28 days (t=28), then you had a 0.0008 chance of having any down time (whether or not it happens depends on which guards you chose). If you increase the number of allowed new guards to 5 (r=5), then the probability of downtime was zero. Cheers, Aaron > Got it. Though on the client side, could we have a warning or have an option to hibernate a HS if they have been forced to switch guards N times in the last N minutes or hours or such? This would allow a DNS on the HS of course, but that may be preferable to discovery. > > David Chasteen > > PGP 0x48458ecd78833c0d > > On Nov 9, 2014 12:49 PM, "Matthew Finkel" <matthew.finkel(a)gmail.com> wrote: > On Sun, Nov 09, 2014 at 12:34:01PM -0500, David Chasteen wrote: > > Would it be possible to create some kind of tor weather-like detection > > and alert system to warn if such a massive DoS attack were underway such > > that users could know that perhaps now might not be the best possible > > time to use Tor? A hidden threat is worse than a known one. We're not > > going to be able to mitigate every known threat, but making users aware > > that the threat profile is heightened can allow them to make informed > > risk decisions. > > > > Unfortunately we don't receive any real-time statistics from relays, > and our metrics calculations are run daily, so there's a significant > delay in any visualizations we generate. Perhaps we can still look for > and see long-term attacks (> 24-36 hours) but nothing that will > significantly benefit users shortly after the attack begins. > _______________________________________________ > tor-internal mailing list > tor-internal(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-internal > _______________________________________________ > tor-internal mailing list > tor-internal(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-internal

1 0

Proposals 220 and 228 updated
by Nick Mathewson 07 Nov '14

07 Nov '14

Hi, all! I've checked in some small changes to proposals 220 and 228; please see the torspec git repository for information. These reflect changes that I have realized those proposals needed while I was working on implementing them in ticket 12498. best wishes, -- Nick

1 0

tor meetings for the week of November 10: including triage party!
by Nick Mathewson 07 Nov '14

07 Nov '14

Good morning/afternoon/evening! On Tuesday at 1700 UTC, there is the regular patch workshop. On Wednesday at 1330 UTC, there is our regularly scheduled development meeting. On Thursday at 1330 UTC, there is a bug triage party, where we will try to figure out what we need to solve in 0.2.6, and what we can mark as nice-to-have-but-deferrable. All meetings are on the #tor-dev channel on OFTC; if we get too noisy or have a conflict, we'll move somewhere else. Everybody is welcome! yrs, -- Nick

1 0

Why the seeming anticorrelation between obfs3 and vanilla bridges in metrics graphs?
by David Fifield 07 Nov '14

07 Nov '14

In the past few months of bridge user graphs, there is an apparent negative correlation between obfs3 users and vanilla users: when one goes up, the other goes down. If you draw a horizontal line at about 5500, they are almost mirror images of each other. I don't see it with any other transport pairs. Any idea why it might be? I can see what could cause a simultaneous decrease in vanilla and increase in obfs3: Tor gets blocked somewhere and users switch to obfs3. But I wouldn't expect blocking events to look so smooth or happen so frequently, and it doesn't explain why the reverse change happens later (obfs3 being blocked while Tor is unblocked is less plausible). I can also understand the overall long-term trend of obfs3 increasing and vanilla decreasing. But I don't see why they should mirror each other so closely over short time periods. Some hypotheses: 1. There are lots of users who have a mix of vanilla and obfs3 bridges configured. Their tor (randomly?) chooses one of them, which usually works. The number of such users is constant over the short term; i.e. the sum of obfs3+vanilla is constant, but the proportion of obfs3 and vanilla fluctuates randomly. 2. Maybe vanilla-down/obfs3-up is caused by blocking events, and vanilla-up/obfs3-down is caused by natural new-user churn and/or coincidence. 3. There is something about the way BridgeDB hands out bridges, or the way in which users use it, that causes it to give out obfs3 bridges at the expense of vanilla and vice versa. 4. Some kind of feedback loop: obfs3 bridges get used and get congested, so users switch to vanilla, which then get used and congested, etc. David Fifield

3 7

Help regarding contribution
by harsh sangwan 06 Nov '14

06 Nov '14

Sir / Madam, I am an undergraduate student. Recently, I've developed huge interest in Tor & thus would like to contribute to it by adding code to its projects. Problem is, I don't know much about contributing to open source & that's where I would like you to help me. I have expert skills in C/C++ & shell scripting. Can you please help me with these things ? 1. Finding me appropriate mentor & project given my technical skills. 2. Guiding me about the prerequisites I should fulfill before I can start contributing to Tor. Hope to see a good response.

2 1

OpenBSD in doc/TUNING
by Libertas 05 Nov '14

05 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I think it would be a good idea to add OpenBSD to doc/TUNING because its file descriptor limits are a little confusing, and because promoting OpenBSD relays benefits the Tor network's security. By default, OpenBSD limits the total number of file descriptors to 7030. This can be changed only by recompiling the kernel: http://unix.stackexchange.com/questions/104929/does-openbsd-have-a-limit-to… However, stricter limits are set in /etc/login.conf so that a single user cannot open all available file descriptors, preventing others from opening files. In this config file, openfiles-cur is the max upon login, and openfiles-max is the highest limit that can be set (even using ulimit -n) without changing /etc/login.conf and restarting. The _tor user is in the daemon class, at least on my install. You can check using 'userinfo _tor'. This means that the daemon class rules in /etc/login.conf also apply to Tor. See 'man login.conf' and Absolute OpenBSD (2nd Ed.) for more info. If I recall correctly, my OpenBSD relay maxed out at 1024 before I changed /etc/login.conf. This agrees with what I'm seeing in contrib/dist/tor.sh.in, and (again, IIRC) also happened to be the openfiles-max value. It's worth noting that contrib/dist/tor.sh.in only checks for the maximum file descriptor count in /proc/sys/fs/file-max (lines 53-65 on the master branch), which doesn't exist in OpenBSD, so Tor will probably default to 1024 regardless of what openfiles-max is. I'm still a beginner, so let me know if I made any mistakes. Also, let me know if I should send this to the relays list as well. I can write up a short draft paragraph if people think this is accurate and worthwhile. Help is welcome. Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUWQv+AAoJELxHvGCsI27NXvAP/i5Q0wWuSY7d+DUqJfdddju1 FoEf27qtLV6ze8WscWQgCHciTTdXDkW43OVptcTbuwJ9TOYMPPhtF/6ENgizxoin 37I1lVlm5sZ926UKRwkOapc4keJ910gpcePZJ9vgbCSNJhRO7tg4BKdhLJfeRY0f CaEFTB6bHigqfGAWeQjzDfGZ3LifawrdoN1tTDXpqpRH9tNhcAD+pvepP4Pze3xm lVUcQmD/Dn4rpQTS7IrNkR66WtR/NJ2xc8JSXrX/81hKT+SbNGmCjTxIc7uWrI0S aTrI9oAeQtJ4LRrlaZBzc1C1JbkW6xB5oNjtR6JEtK536/9nmzrRmZNGeKOtpGrk rIEwJjwrv5sNYRhul8Hl6ngrjIzwQLmZR+aNda0USEaRLpfUBYiFg9rqxTPLMU3Q VOo3Hf08zQTXCddcizs19Q1km67scJ5PkgSdkm8qS06H19uQEXXKcHOtUstNxGrY GxWAD5RIm/53QIYurNJW4UctwvzCuanviHTkWCDn0dwV42HvUUfJCgOnmkuf9n1+ ZMxxT1F49WV4pBEPEVp4cRN9NPqkfMMMtKLCtM6WxoJNXdkIyQz46D9ZNahaHFOh TuehsBW29GT/w9FW1APKeMleq+eV9lpZb2GbWXrjnFr7MRuCJZVCz5wzr11hnept trInFflWvbIWtp4yv6Vf =bm5p -----END PGP SIGNATURE-----

2 1

Damian's Status Report - October 2014
by Damian Johnson 05 Nov '14

05 Nov '14

I love the beginning of winter. Landscape a chilly tundra, no sun, yet still no snow to slip on. What I *don't* love, however, is all the sicknesses that float around. This month has been uncommonly unlucky for me with three separate bugs making the rounds. No single one was a big whoop, but still can't say I'm a fan of things making themselves at home in my warm, cozy respiratory track. Oh well. Enough of that. This month was mostly focused on arm, specifically rewriting the graph panel. Work here is ongoing, but I hope to have this section done in November. Other noteworthy things this month include... * Stem now has a set of methods to more easily work with hidden services thanks to federico3 and Patrick [3]. New methods include... * get_hidden_service_conf * set_hidden_service_conf * create_hidden_service * remove_hidden_service * Addressed OOM issues with DocTor. DocTor uses quite a bit of memory, but the real trouble was that sending a notification at the end forked, doubling allocated memory. I addressed this by spawning the mail subprocess earlier, before we read in descriptor data. * Couple DocTor patches from Tom Ritter - thanks Tom! [1][2] * Subteam discussions with Karsten and OONI folks accumulating in the VegasTeam3 wiki [4]. I'm dubious that this will mean much (or anything) in practice, but we'll see. * Attended a couple local tech events including TA3M Seattle and Seagl [5]. * Got promoted at work! This was five years in the making, so I'm pretty delighted. :P Cheers! -Damian [1] https://trac.torproject.org/projects/tor/ticket/13389 [2] https://trac.torproject.org/projects/tor/ticket/13390 [3] https://trac.torproject.org/projects/tor/ticket/12533 [4] https://trac.torproject.org/projects/tor/wiki/doc/VegasTeam3 [5] http://seagl.org/

1 0

Summary of meek's costs, October 2014
by David Fifield 04 Nov '14

04 Nov '14

Here's the summary of meek's CDN fees for October 2014. Earlier reports: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 -- total by CDN $49.15 + $137.98 + $0.00 = $187.13 grand total Golly! I'm as shocked as you are. There was an explosion in users after the release of Tor Browser 4.0 on October 15 (first attached image): https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… Before that, we were mostly under the free thresholds on each service. Now we're consistently exceeding those thresholds and getting charged at the normal rate. For example, Amazon gives us 50 GB free each month; last month we only used about 32 GB but this month it was about 480 GB. There was really only half a month of heavy use, so next month I expect the charges to be at least double. But I'm going to try to apply some free credits; see below. At the moment, the most cost-effective backend is meek-azure, because it's running on a free research grant for a year. obfs3 is currently the most-used transport, with about 8000 simultaneous users, compared to meek's 500. https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… Just looking at the time period from October 15 to October 31, the mean value of the obfs3 graph is 8075, and that of the meek graph is 450, a ratio of 18:1. About 94% of October's meek users appeared after October 15. So a rough calculation of meek's monthly cost, if it were to become as used as obfs3 is today, is $171.14 * 0.94 * (8075/450) * 3/2 ≈ $4300 The 3/2 comes from assuming that Azure will cost as much as the other two eventually. The other big assumption in this calculation is that costs scale linearly with users, which isn't quite true because of the free thresholds and because of regional pricing differences. == App Engine a.k.a. meek-google == This is the first month we had charges for "instance hours"; previously we paid only for bandwidth. App Engine by default runs just one copy of your app, but spins up new instances of it during increased load. You get 28 instance hours for free each day, so as long as there's just one instance you don't pay anything. The total cost of $40.85 broke down as follows: 289 GB $34.72 123 instance hours $6.13 The attached meek-google-costs-2014-11-01.png shows the breakdown of costs between bandwidth and instance hours for the last few months. On October 25 I experimented with upgrading the App Engine instance class from "F1" to "F2". https://cloud.google.com/appengine/docs/adminconsole/performancesettings#Se… F2 has more CPU and I thought it might speed up TLS. F2 uses up instance hours at twice the rate of F1, so even if you only have one instance you pay for 20 hours. I downgraded the class back to F1 on October 27 when, for the first time, we hit the daily spending limit of $5.00 I had set, about 22 hours into the day. (I happened to be using meek-google at the time, so I noticed right away when it stopped working.) I bumped back up to F2 and increased the daily spending limit on October 31. This month I'm going to try to activate a credit I have for App Engine, which is $500 for three months. We'll probably run out of the $500 before the three months are up, because we're currently pretty close to the $5 per day that implies. The attached meek-google-2014-11-01.png shows B/s for the month. == Amazon a.k.a. meek-amazon == The Amazon bill of $130.29 breaks down in a complicated way by region. Each region has different free thresholds and different per-unit rates. I've summarized it here but the actual bill has 31 line items. This month is the first month with bandwidth charges; previously we had only paid for the number of HTTPS requests. Asia Pacific (Singapore) 23M requests $27.86 169 GB $19.49 Asia Pacific (Sydney) 150K requests $0.00 1 GB $0.15 Asia Pacific (Tokyo) 16M requests $18.93 108 GB $18.28 EU (Ireland) 15M requests $16.22 108 GB $11.75 South America (Sao Paulo) 180K requests $0.00 1 GB $0.03 US East (Northern Virginia) 8M requests $7.77 92 GB $9.81 The attached meek-amazon-2014-11-01.png shows GB/day for the month. == Azure a.k.a. meek-azure == Azure is still on a free grant for a year. Unfortunately I don't see a way to find out what it would be costing or even get a report of monthly bandwidth usage. The attached meek-azure-2014-11-01.png shows GB/hour for the last seven days of the month. David Fifield

1 0

Patch meeting today at 1700 UTC; one-time day change for tor dev meeting
by Nick Mathewson 04 Nov '14

04 Nov '14

Hi! The weekly tor patch workshop is still 1700 UTC on Tuesdays. That is now _noon_ Eastern and 9:00 am Pacific in the US, thanks to our bizarre timekeeping system. For this week only, I need to move the day of the tor dev meeting to **Thursday** at 1330 UTC (8:30 am Eastern) -- my kid has a doctor's checkup. yrs, -- Nick

1 0

Pluggable transports meeting tomorrow (16:00UTC Wednesday 5th of November 2014)
by George Kadianakis 04 Nov '14

04 Nov '14

Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention!

1 0

OONI hackfest summary
by Arturo Filastò 04 Nov '14

04 Nov '14

>From October 24th to 26th the OONI team gathered in Berlin for a hackfest. Around 20 people ended up showing up and although most of them were seasoned Oonitarians some fairly new people joined us that I hope will become part of the growing OONI community. The scope of the hackfest was that of data analytics and visualization with special focus on the Tor bridge reachability study we are currently doing. # Bridge reachability study The goal of this study [1] is that of answering some questions concerning the blocking of Tor bridges [2] and pluggable transport [3] enabled bridges in the countries of China, Iran, Russia and Ukraine (test vantage points). To establish a baseline to eliminate the cases in which the bridge is marked as blocked, while it is in fact just offline, we measure also from a vantage point located in the Netherlands. For every test vantage point we perform two types of measurements: * A Bridge reachability measurement [4][5] that attempts to build a tor circuit using the bridge in question * A TCP connect measurement [6][7] that simply does a TCP connect to the bridge IP and port We run both of the measurements to further debug the reason why the blocking is happening, may this be due to a TCP RST or direct IP blocking or tor malfunction. So far this study has been running for a little less than 1 month. # OONI data pipeline In order to produce the aggregate data needed to build visualizations we have built a data pipeline [8] This consists of a series of operations that are done to the raw reports in order to strip out sensitive information and place the collected data into a database. The nice thing is that the data pipeline we have designed is not specific to this study, but can and will be in the future expanded to export data needed to visualize also the other types of measurements done by OONI. The data pipeline is comprised of 3 steps (or states, depending on how you want to look at it). When the data is submitted to a OONI collector it is synchronized with the aggregator. This is a central machine responsible for running all the data processing tasks, storing the collected data in a database and hosting a public interface to the sanitised reports. Since all the steps are independent from one another it is not necessary that they run on the machine, but it may also be more distributed. Once the data is on the aggregator machine it is said to be in the RAW state. The sanitise task is then run on the RAW data to remove sensitive information and strip out some superfluous information. A RAW copy of every report is also stored in a private compressed archive for future reference. Once the data is sanitised it is said to tbe in SANITISED state. At this point a import task is run on the data to place it inside of a database. The SANITISED reports are then place in a directory that is publicly exposed to the internet to allow people to download also a copy of the YAML reports. At this point is is possible to run any export task that performs queries on the database and produces as output some documents to be used in the data visualizations (think JSON, CSV, etc.). # The OONI hackfest The first day of the hackfest was spent going over the scope of the project we would be working on in the following days as well as working in groups that were interested in tacking the design of one aspect of the problem. Sticky notes were plentiful and helped us have a clear vision of what lied ahead of us. By the end of the first day we had clear what were the set of tasks that were needed to achieve our goals and which teams would be responsible for doing what. The second day was almost entirely dedicated to hacking and everybody had a task to complete that was either completed by the end of the day or sooner. Some people even completed their initially assigned task before the end of the day and came back asking for more! By the end of the second day we had a real data set to hand over to the visualization team, to start producing some pretty graphs based on real data. We decided that the first visualization we wanted to do should be kept as simple as possible and be something that we could also use to debug the data we had collected. It should tell us which bridges were working when and it should present the information in a way that would highlight the country involved and the pluggable transport type. A prototype of it can be seen here: http://reports.ooni.nu/analytics/bridge_reachability/timeline/ The code for this visualization can be found here: https://github.com/Shidash/OONI-Bridge-Reachability-Timeline # Next steps * Write scripts for generating the bridge_db.json document based on the data that is given to us from the bridge db team https://trac.torproject.org/projects/tor/ticket/13570 * Align the dates in the visual timeline https://trac.torproject.org/projects/tor/ticket/13639 * Better tokenising for bridges so that bridges that have the same fingerprint, but different transport are grouped properly https://trac.torproject.org/projects/tor/ticket/13638 * Finish setting up the docker containers for the steps of the data pipeline https://trac.torproject.org/projects/tor/ticket/13568 * Setup disaster recovery procedure and backup: https://trac.torproject.org/projects/tor/ticket/13584 * Setup monitoring of the probes. https://trac.torproject.org/projects/tor/ticket/12549 * Add support for obfs4 https://trac.torproject.org/projects/tor/ticket/13597 * Set upper bound in comparison with the control in the bridge reachability timeline https://trac.torproject.org/projects/tor/ticket/13640 * Make sure that the control measurement is for the specific bridge measurement https://trac.torproject.org/projects/tor/ticket/13655 Questions and comments should be directed to the ooni-dev mailing list or to the #ooni channel on irc.oftc.net. Have fun! ~ Arturo [1] https://lists.torproject.org/pipermail/ooni-dev/2014-October/000184.html [2] https://www.torproject.org/docs/bridges [3] https://www.torproject.org/docs/pluggable-transports.html.en [4] https://gitweb.torproject.org/ooni/spec.git/blob/HEAD:/test-specs/ts-011-br… [5] https://gitweb.torproject.org/ooni-probe.git/blob/HEAD:/ooni/nettests/block… [6] https://gitweb.torproject.org/ooni/spec.git/blob/HEAD:/test-specs/ts-008-tc… [7] https://gitweb.torproject.org/ooni-probe.git/blob/HEAD:/ooni/nettests/block… [8] https://github.com/TheTorProject/ooni-pipeline/blob/master/Readme.md#ooni-p…

1 0

Re: [tor-dev] [HTTPS-Everywhere] "darkweb everywhere" extension
by yan 03 Nov '14

03 Nov '14

+tor-dev. tl;dr: Would be nice if there were an HTTP response header that allows HTTPS servers to indicate their .onion domain names so that HTTPS Everywhere can automatically redirect to the .onion version in the future if the user chooses a "use THS when available" preference. I imagine the header semantics and processing would be similar to HSTS. It would only be noted when sent over TLS and have the max-age and include-subdomains fields. -yan yan wrote: > Hi all, > > Some people have requested for the "Darkweb Everywhere" extension [1] to > be integrated into HTTPS Everywhere. This is an extension for Tor > Browser that redirects users to the Tor Hidden Service version of a > website when possible. > > I'm supportive of the idea; however, I'm worried that since .onion > domain names are usually unrelated to a site's regular domain name, a > malicious ruleset would be hard to detect. AFAIK Darkweb Everywhere only > defends against this by publishing a doc in their Github repo that cites > evidence for each ruleset [2]. > > What if, instead, we asked website owners to send an HTTP header that > indicates the Tor Hidden Service version of their website? Then HTTPS > Everywhere could cache the result (like HSTS) and redirect to the THS > version automatically in the future if the user opts-in. > > If this is something that EFF/Tor would be willing to advocate for, I > would be happy to draft a specification for the header syntax and > intended UA behavior. > > Thanks, > Yan > > > [1] https://github.com/chris-barry/darkweb-everywhere/ > [2] > https://github.com/chris-barry/darkweb-everywhere/blob/master/doc/EVIDENCE.… > _______________________________________________ > HTTPS-Everywhere mailing list > HTTPS-Everywhere(a)lists.eff.org > https://lists.eff.org/mailman/listinfo/https-everywhere >

3 2

Call for Papers: Switzerland - International Conference on Semantic Web Business and Innovation (SWBI2015)
by Conference Updates 03 Nov '14

03 Nov '14

The International Conference on Semantic Web Business and Innovation (SWBI2015) The University of Applied Sciences and Arts Western Switzerland (HES-SO Valais-Wallis) October 7-9, 2015 http://sdiwc.net/conferences/swbi2015/ All registered papers will be included in SDIWC Digital Library ================================================================ The proposed conference on the above theme will be held at he University of Applied Sciences and Arts Western Switzerland (HES-SO Valais-Wallis) on October 7-9, 2015 which aims to enable researchers build connections between different digital applications. The conference welcomes papers on the following (but not limited to) research topics: *Semantic Web and Linked Data - Database, IR, NLP and AI technologies for the Semantic Web - Geospatial Semantic Web - Information Extraction from unstructured data - Information visualization of Semantic Web data and Linked Data - Internet of things - Languages, tools, and methodologies for representing and managing Semantic Web data - Linked open data - Management of Semantic Web data and Linked Data - Ontology engineering and ontology patterns for the Semantic Web - Ontology modularity, mapping, merging, and alignment - Ontology-based data access - Privacy and Security - Query and inference over data streams - Search, query, integration, and analysis on the Semantic Web - Semantic business process management - Semantic Sensor networks - Semantic technologies for mobile platforms - Semantic Web and Linked Data for Cloud Environments - Semantic Web, Ontologies - Social networks and processes on the Semantic Web - Supporting multi-linguality in the Semantic Web - User Interfaces and interacting with Semantic Web data and Linked Data *Business and Innovation in Semantic Web - Business Model Innovation - Business Models and E-Commerce - Business Technology Intelligence - Challenges for change in semantic services - Collaborative improvement and innovation - E-Business Applications and Software - E-commerce Technology Adoption - E-commerce, E-Business Strategies - E-tailing and Multi-Channel selling - Evolution of Business model for Semantic Web Applications - High-tech marketing - Implementation strategies for responsible innovation - Innovation for E-Business - Innovative methods and tools for products and services - Practices and Cases in E-Commerce - Production of Knowledge Economy - Technology and Business Transformation - Technology strategies - The Latest Trends in Linked Data - Web Advertising and Web Publishing - Web and Mobile Applications Researchers are encouraged to submit their work electronically. All papers will be fully refereed by a minimum of two specialized referees. Before final acceptance, all referees comments must be considered. Important Dates ============== The Submission is open Notification of Acceptance: 6 weeks from the submission date Camera Ready Submission: September 14, 2015 Registration Deadline: September 14, 2015 Conference Dates: October 7-9, 2015

1 0

On the visualization of OONI bridge reachability data
by George Kadianakis 02 Nov '14

02 Nov '14

== What is bridge reachability data? == By bridge reachability data I'm referring to information about which Tor bridges are censored in different parts of the world. The OONI project has been developing a test that allows probes in censored countries to test which bridges are blocked and which are not. The test simply takes as input a list of bridges and tests whether they work. It's also able to test obfuscated bridges with various pluggable transports (PTs). == Why do we care about this bridgability data? == A few different parties care about the results of the bridge reachability test [0]. Some examples: Tor developers and censorship researchers can study the bridge reachability data to learn which PTs are currently useful around the world, by seeing which pluggable transports get blocked and where. We can also learn which bridge distribution mechanisms are busted and which are not. Bridge operators, the press, funders and curious people, can learn which countries conduct censorship and how advanced technology they use. They can also learn how long it takes jurisdictions to block public bridges. And in general, they can get a better understanding of how well Tor is doing in censorship circumvention around the world. Finally, censored users and world travelers can use the data to learn which PTs are safe to use in a given jurisdiction. == Visualizing bridge reachability data == So let's look at the data. Currently, OONI bridge reachability reports look like this: https://ooni.torproject.org/reports/0.1/CN/bridge_reachability-2014-07-02T0… and you can retrieve them from this directory listing: https://ooni.torproject.org/reports/0.1/ That's nice, but I doubt that many people will be able to access (let alone understand) those reports. Hence, we need some kind of visualization (and better dir listing) to conveniently display the data to human beings. However, a simple x-to-y graph will not suffice: our ploblem is multidimensional. There are many use cases for the data and bridges have various characteristics (obfuscation method, distribution method, etc.) hence there are more than one useful ways to visualize this dataset. To give you an idea, I will show you two mockups of visualizations that I would find useful. Please don't pay attention to the data itself, I just made some things up while on a train. Here is one that shows which PTs are blocked in which countries: https://people.torproject.org/~asn/bridget_vis/countries_pts.jpg The list would only include countries that are blocking at least a bridge. Green is "works", red is "blocked". Also, you can imagine the same visualization, but instead of PT names for columns it has distribution methods ("BridgeDB HTTP distributor", "BridgeDB mail distributor", "Private bridge", etc.). And here is another one that shows how fast jurisdictions block the default TBB bridges: https://people.torproject.org/~asn/bridget_vis/tbb_blocked_timeline.jpg These visualizations could be helpful, but they are not the only ones. What other use cases do you imagine using this dataset for? What graphs or visualizations would you like to see? [0]: Here are some use cases: Tor developers / Researcers: *** Which pluggable transports are blocked and where? *** Do they do DPI? Or did they just block the TBB hardcoded bridges? *** Which jurisdictions are most aggressive and what blocking technology do they use? *** Do they block based on IP or on (IP && PORT)? Users: *** Which pluggable transport should I use in my jurisdiction? Bridge operators / Press / Funders / Curious people: *** Which jurisdictions conduct Tor censorship? (block pluggable transports/distribution methods) *** How quickly do jurisdictions block bridges? *** How many users/traffic (and which locations) did the blocked bridges serve? **** Can be found out through extrainfo descriptors. *** How well are Tor bridges doing in censorship circumvention?

4 6

TOR Interference??!??!?
by Liste 30 Oct '14

30 Oct '14

Sometime, of many computers, of many hidden service, the TOR's connection are interrupted, very slow, and can't connect to hidden serivce or Internet site. When i change the TOR identity all works better. Sometime into the log file i can see a message like this: * Hidden service descriptor corrupted. * Invalid hidden service descriptor. Are some hidden services under attack? I try to create some hidden service to test... After 2 or 3 days the hidden service become unavailable. But if i change the TOR identity of hidden service (server), the hidden service become available. Why??? One time, in 1-2 July, i was see the corruption of SSL connection over TOR network (all connection). What's going on? What's wrong? Test system: * Debian 7 * TAILS 1.1 * Parrot OS * Windows 7 * Debian 7 (Another as server)

1 0

GetTor development status
by ilv 30 Oct '14

30 Oct '14

Hi people. We've been working very hard to get GetTor deployed as soon as possible. Meanwhile, I'd like to tell you what we've been up to. 1) Changed from logging quite a bit of stuff, to not logging at all. GetTor actually creates log files, but they remain empty. We'll see what we need to log on the way. 2) Changed from keeping stats about the requests (os, locale, etc) to just keep a counter to know how many requests we've received so far. The only exception is with some info necessary to avoid flood, namely: the hashed user, number of requests for that user and the last time that user made a request. All of this is stored in a SQLite database. 3) For now we'll only send Dropbox links. We now use long urls with the ?dl=1 prefix to automatically download the file, instead of the old short urls used (during the revamp). You can see an example of what urls should be sent on [1]. We hope to implement other providers in the future. We'll need an official Dropbox account for this, this is one of the things we're waiting to deploy. 4) You can check a template of the message that should be sent when sending the links on [2], under the "links_msg" msgid. The interpolated info is: operating system, locale, the links (see [1] for links format). We're working on making this as usable as possible, so any thought on this is very welcome! 5) I still have pending an script to synchronize with the latest version of TBB on dist.tp.o and upload that to Dropbox. Help here is very welcome too. I think that is for now. Any comment/feedback is welcome. If you have any crazy ideas about new ways to distribute the TBB with GetTor, please tell us. I have created two files in the Github repo: providers [3] and distribution_methods [4]. Make a pull request if you're feeling inspired :) [1] https://github.com/ileiva/gettor/blob/master/providers/dropbox.links [2] https://github.com/ileiva/gettor/blob/master/lang/smtp/i18n/en/LC_MESSAGES/… [3] https://github.com/ileiva/gettor/blob/master/providers.txt [4] https://github.com/ileiva/gettor/blob/master/distribution_methods.txt happy hacking, -- 0xA456E2CE540BFC0E

1 0

Newbie Devloper Questions
by pylis＠riseup.net 29 Oct '14

29 Oct '14

Hello, I am would like to begin working on a distributed application sitting on top of TOR and am wondering if there are any existing guides providing a good starting point for this type of development. If not, what other resources might be good starting points to become familiar with the foundation concepts? Thank you

2 1

A fun graph you can make at home
by David Fifield 29 Oct '14

29 Oct '14

This is a graph of the number of simultaneous relay users for every country, one country per row. It's roughly 30 cm wide and 3 m tall. https://people.torproject.org/~dcf/graphs/relays-all.pdf It's basically the same as https://metrics.torproject.org/users.html?graph=userstats-relay-country&sta… but for every country at once. I thought it might help reveal differences and similarities. It's made with the attached R script. Run it like so: Rscript relays-all.R You can see a few interesting features. Most conspicuous is the Sefnit botnet in late 2013 that affected almost every country. Also look at Russia (ru) around June 2014 and Iran (ir) in August, to pick out some recent censorship-related examples. To generate individual pages for printing and taping together, I used the pdfposter program: pdfposter -v -p 999x1letter relays-all.pdf relays-all-paginated.pdf David Fifield

1 1

MATor: A live-monitor for anonymity guarantees
by Esfandiar Mohammadi 28 Oct '14

28 Oct '14

Hi, tl;dr: we have a CCS paper coming up about a client-based live-monitor, called MATor [1], that assesses the influence of Tor's path selection to a user's anonymity. The paper is a first step towards a useful live-monitor that assesses a user's anonymity in a provable manner. We would appreciate your feedback on our approach and the direction in general. In detail, we implemented a live-monitor that computes upper bounds of the de-anonymization probability for sender, receiver, and relationship anonymity, based on Tor consensus data and the ports that the client needs. We formalized the guarantees that the live-monitor outputs in (an extension of) the AnoA framework [2] for circuit creation against passive attackers that do not control infrastructure (ASNs or IXPs). We use safe approximations in the live-monitor to be able to efficiently (a few seconds [3]) compute upper bounds for de-anonymization. At the moment the MATor monitor is a separate tool, but we are working on integrating it into the Tor client code. We envision an integration into Tor Browser Bundle. Since MATor is an ongoing project, we would appreciate your opinion about the approach in general. Best wishes, - Sebastian & Esfandiar [1] Michael Backes, Aniket Kate, Sebastian Meiser, Esfandiar Mohammad. (Nothing else) MATor(s): Monitoring the Anonymity of Tor's Path Selection. to appear in Proceedings of 21st ACM CCS, ACM, 2014. The MATor project page (containing the paper and the implementation): http://www.infsec.cs.uni-saarland.de/projects/anonymity-guarantees/mator.ht… [2] Michael Backes, Aniket Kate, Praveen Manoharan, Sebastian Meiser, and Esfandiar Mohammadi. AnoA: A Framework For Analyzing Anonymous Communication Protocols Unified Definitions and Analyses of Anonymity Properties. Proceedings of 26th IEEE CSF, pages 163-178, IEEE, 2013. The AnoA project page (containing the paper): http://www.infsec.cs.uni-saarland.de/~meiser/paper/anoa.html [3] The running time is as follows on a MacBook Air 2GHz Intel i7 with 4GB RAM: Preparation time: 3.39 seconds For sender anonymity: 0.73 seconds For recipient anonymity: 6.07 seconds For relationship anonymity: 9.10 seconds

1 0

Link protocol version
by Владимир Мартьянов 28 Oct '14

28 Oct '14

I'm trying to understand link protocol versions, but I have some problems. I requested descriptor from the root server and it contains line "protocols Link 1 2 Circuit 1". Then I connected to the node, sent VERSIONS cell and got a responce: "00 00 07 00 04 00 03 00 04". But according to that responce, the node supports link protocol v3 and v4, not v1 and v2. Could you please explain that moment?

2 4

Using Mozilla Persona for "Helping Internet services accept anonymous users"
by isis 27 Oct '14

27 Oct '14

[pre scriptum] This email particularly concerns the people on the Tor Browser team, and to those interested in progress on Roger's "A Call To Arms: Helping Internet services accept anonymous users" blog post. [0] Hello all, While setting up a Mozilla Persona Identity Provider (IdP) server for testing ways to provide a system for anonymous users to log in to websites, I discovered some serious problems [1] which, in my opinion, make Persona unusable for our case. One of these problems [2] essentially boils down to forcing us to choose between two options for real-world deployment, due to a lack of forward compatibility in the existing Mozilla Persona deployment: 1. We could deploy a version which is compatible with the legacy Persona implementation but which has privacy issues. We would need to accept that the so-called "anonymous" users of the Tor Project IdP would be sent from the website they are trying to log into (Wikipedia, for example) to https://login.persona.org, and that the latter would speak to the Tor Project IdP. There is not even remotely a chance for even pseudonymity, if we went this route, as the https://login.persona.org server could: * Log which websites a Tor user tries to log into, * Log when a Tor user tried to log into or out of any website, * Potentially link a user's pseudonyms (yes, even if we handed out blinded signatures in our credentials), * Arbitrarily decide to block all Tor users without the consent of either Wikipedia or the Tor Project IdP, * and probably a bunch of other horrible stuff. 2. We could make a version based on the so-called "native" Persona implementation within Firefox. This would result in fewer privacy issues, however it would be incompatible with all the rest of existing Persona infrastructure. Mozilla's "native" Persona implementation is already incompatible with the legacy version currently deployed on all Persona-enabled websites and IdPs today. If we decide to go this route, and create a version of Persona which does not redirect our users through third-party IdPs, we would need to try to force every website that wants to allow anonymous users to login to source custom Javascript that we make available, [3] which is specific to allowing logins from our IdP. In addition, sites which include this Javascript would no longer be compatible with the regular (non-Tor Browser) Firefox userbase and any existing Persona infrastructure (both Persona-enabled websites and other Persona IdPs). For a more verbose explanation, please see [4]. I think we can all agree that Option #1 is unacceptable. If we were to do Option #2, we would essentially be taking over maintenance of Persona from Mozilla *and* creating an entirely new, incompatible authentication system on top of the dilapidated remains. Before going that route we should pay attention to the fact that Mozilla pulled support for the project because of lack of adoption. If our goal was to save work by using Persona for this purpose, I estimate that we would be doing more work by using Persona than if we were to build something completely from scratch. [0]: https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… [1]: https://trac.torproject.org/projects/tor/ticket/12193 [2]: https://trac.torproject.org/projects/tor/ticket/12193#comment:12 [3]: https://github.com/isislovecruft/browserid-certifier/blob/master/srv/login.… [4]: https://trac.torproject.org/projects/tor/ticket/12193#comment:13 -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Understanding Tor and SOCKS
by spriver 27 Oct '14

27 Oct '14

Hi everyone! I am trying to understand the communication between an application and Tor (especially connecting to a hidden service). I am tracing packets on loopback between a torified netcat request to connect to a .onion address. When the connection gets granted I am getting a response from the socks server: (hex data of the tcp payload) 0x05 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Regarding to the SOCKS specification this means that the request is granted. But I don't understand the 0x01 in byte no 4. It means IPv4 address in the SOCKS specification, but the following part of the destination address and port (the following 0x00's) are empty. So what does that 0x01 mean? Can someone explain me that? Thank you! Cheers, spriver

4 5

Vidalia Relay Bundle(win) Tor version, obfs4proxy package in deb.tp.o
by s7r 26 Oct '14

26 Oct '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 1. I have noticed that the Vidalia Relay Bundles for Windows available to download on torproject.org are using Tor 0.2.4.23, while we are on 0.2.5.10 as stable branch. I know 0.2.4.23 is still on the recommended list in the consensus, but since someone is downloading the bundles fresh from the Tor home page, I think it is expected to include the latest stable Tor version. 2. Configured some obfs4 bridges using obfs4proxy. They work very good, however it's a little bit complicated since package obfs4proxy exists in Debian sid, but not in deb.torproject.org, so you have to add sid repo to sources.list, install obfs4proxy and then make sure you edit apt preferences or comment the sid repo from the list in order not to upgrade you entire Debian system with packages from unstable/testing branch. Received couple of emails from users wanted to deploy obfs4 bridges and were confused. Is it possible to include obfs4proxy in deb.torproject.org for Debian, and while at it also make a rpm package for RHEL/CentOS? obfsproxy (python based pluggable transport) was easy to install in RHEL/CentOS using EPEL repo and `pip` but obfs4proxy should come as a rpm from deb.torproject.org. 3. Last thing, the page https://bridges.torproject.org/ does not contain obfs4 in the drop-down list where the user needs to select the pluggable transport. It only allows requests for obfs2, obfs3, scramblesuit and fteproxy bridges. Don't know about fteproxy, but shouldn't obfs2 be deprecated or is it still working/used? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUTRBeAAoJEIN/pSyBJlsR2zwH/2mnA2GNomxNQZI7Eeumt1sM uA6iXvlUiILJdQRG8EcHx8sfHU5MD20V5mOH774XsX7elAG47/ePL+/SKL69OfuR nl/X4IzH34CaqbMLGVHotl9Bcugfgw71fAF+Gm5nymM8VRxsdQnS51nnz7pwphon /DeeMfCE45eCYpVYyOqXZcSM4DA6Hr5bWG5TlCVJXTOl67fMr/pEBFgfpc6RIAL/ 8GXk+Cv6k/vW0AsEb/XoHBNbIzfHhOlb9O9q3giq3kGmJahMheKKLVOP5FNiEWi1 S6AhlxOYNnoAc9jhSAmNsMmJCteVVBV96c9jgeP9QOF2WtLnq6md8/uFocOelUc= =iUXk -----END PGP SIGNATURE-----

3 4