- tor-dev - lists.torproject.org

Tor Browser IsolateSOCKSAuth behavior questions.
by Yawning Angel 01 Jun '15

01 Jun '15

Hello, I've been working on a dumb hack that lets me do things like this: https://imgur.com/3mah244 (Yes, that's a single Tor Browser instance, separate windows used for illustrative purposes.) It's still very raw and doesn't do everything I want it to do, so I'm not really releasing the code yet, but I have some questions regarding how Tor Browser behaves when setting the SOCKS username for isolation purposes. Ideally I want my shim to enforce isolation between the various upstreams (Tor, I2P, whatever) correctly to avoid cross-protocol probing (and to shield the I2P administration interface from eeevil websites). This appears to be straight forward if the application is Tor Browser because IsolateSOCKSAuth is always used at first glance (I will assume for now that if users decide to use things like torsocks that do not use isolation this way that they know what they are doing). My question is, what causes Tor Browser to set the SOCKS username to "--unknown--" and what the behavior should be in that case if: * The destination is a ".onion" address. * The destination is a ".i2p" address. * The destination is the I2P management console. I'm fairly sure this should be "deny". * The destination is any other address (will be dispatched over Tor if running, I don't think I will attempt to support I2P outproxies because they suck). (I think allow because things break otherwise?) For destinations that are ".onion"/".i2p", I plan to be fairly strict about making sure the SOCKS5 target and the username matches (I need to be more relaxed for sites on the regular intertubes since cross-site resources are loaded (I may make this behavior configurable...). Is this dumb? Is it common for "foo.onion" to load resources off "bar.onion"? How about in I2P land? The final form of my shim will support running with any combination of "nothing" (Tor Browser just for the "privacy benefits", probably unsafe, I may reconsider this), I2P, and Tor (Though the most useful configuration is probably I2P + Tor). Thanks in advance, -- Yawning Angel

2 2

Re: [tor-dev] valid MyFamily syntax variations ('$FP=nick' ?)
by l.m 31 May '15

31 May '15

Hi again, Although, as you've noticed, the the node you mention, Konata lists *itself* in the Family Members. That would be a bug. At least compared to the other possibilities. Onionoo checks for the bidirectional relationship and, in other cases, excludes the current node being viewed. If the current node being viewed lists itself... --leeroy

1 0

valid MyFamily syntax variations ('$FP=nick' ?)
by nusenu 31 May '15

31 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, according to the spec [1] relay ops can choose between fingerprint (with and without $ prefix) and nicknames when constructing their MyFamily configs. The man page recommends fingerprints. Now I'm faced with [2][3] families that use a combination: $fp=nick Are they actually valid or is this a bug or can one actually specify arbitrary strings there? (dir auths and onionoo apparently accept them) thanks [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n504 [2] https://atlas.torproject.org/#details/2B76359D3AAA94CA107F447D2D14E481A99EB… (search for KosakaKirino) [3] https://collector.torproject.org/recent/relay-descriptors/server-descriptor… (this url has a lifetime) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVa2WkAAoJEFv7XvVCELh0jEwQAJqdeZaFpRWPfI9/17o7aEKI Jx8Lp811GGwr4STO41ixwOIQ69hjNuav47apcmR4AsUVAq8zkSnzljKyYtVnp7qH 4EHx0kqIop92s9de1AFKg2XDnZ3u4eSN6z53VXeO2+/jFl2CgMVarzLYPHNBBF/x ev3zMk8gYsGA7K5TowZ+HnMalXhHLpTvO+iPPzNF6eY3/pG31hImFfHvhkJ5nrzB gex9wmCTXigM6I1mcT8mK8OH/2+MkNFra2h4tcEmqzmzRdWx1UWDTgl97Jp2injL UxuHL1RkoGLqlZ/MDiMiZPa4JurNRKgBXdZNsASOvcX8ZiPiCzqbbCm4hN4Rsidi ROWR8AcadA/9a5Ovi0z8IhxUiF8Ks2Wadeovp4w+E2NuYvFNmUpvkH0jVSViSE8n v+XClj0DX8oHirRqp80M0o5GpOB2hsRzT0+QhRFKYbikW2CRziM1ECWknw3aj3/z VPohoo6bkkLLBfrrXdgqclvgtoG/zPl8Ef203pmyTjPCFEdx4mJTLzq+hmjoaPsI h+RweF+HvDc0qM+6fiYeHExQl7YMNuT6GbG58lK6V8c+r++FIrPwfyOepAddoE0p dTAHfqYMYhDL952z916tmNNPnHXsUu8hVaIVuB9RvYjAU9FpPAz5Q5CDaIu+F4TY kb9dxHK1c8IHOGamYMOD =tbZE -----END PGP SIGNATURE-----

3 3

Damian's Status Report - May 2015
by Damian Johnson 31 May '15

31 May '15

Squirrels! Five newborn squirrels are in our tree! And they... oh right, code. Talk about code, Damian, like a professional. ... awww, but damn they're cute. -------------------------------------------------------------------------------- Stem Release 1.4.1 -------------------------------------------------------------------------------- Though not as adorable as baby squirrels the new release of Stem is still pretty sweet. Ephemeral hidden services, substantially faster descriptor parsing, and a host of other improvements can all be yours with a simple upgrade! https://blog.torproject.org/blog/stem-release-14 -------------------------------------------------------------------------------- Nyx Log Panel Rewrite -------------------------------------------------------------------------------- No, Nyx isn't done but its log panel is! This is the third major curses component to be rewritten, and I'm delighted to say it now sucks less! How did it suck, you ask? Though casual users may not have noticed arm had a laughably inefficient O(n^3) approach to log deduplication. This was in fact so terrible arm simply turned off deduplication when it started bogging down the system too much. This is just one of they myriad of improvements, but in Nyx deduplication is O(n^2) and can easily be made linear (... though fuzzy matching makes this grosser than I'd like so first seeing if further improvement is warranted). -------------------------------------------------------------------------------- Few other noteworthy things were... * Thanks to DonnchaC Stem's tor message parsing is now a dramatic 300x faster when using python3! https://github.com/DonnchaC/stem/pull/1 * Wrote a simple bandwidth scanner to exemplify manual circuit construction for our tutorials... https://stem.torproject.org/tutorials/to_russia_with_love.html#custom-path-… * Sambuddha both made our tutorial examples downloadable (#10411) and more easily testable (#16191)! Cheers! -Damian

1 0

Visualising similarities between relay descriptors
by Philipp Winter 31 May '15

31 May '15

Visualising the similarity between two Tor relay descriptors helps with finding Sybil attacks. I added code to sybilhunter [0] that takes as input relay descriptors, determines all (n^2)/2 pairwise similarities, and outputs DOT code (part of Graphviz) that illustrates relay clusters and what makes them similar. For now, this functionality is just a set of hard-coded rules that determine, e.g.: - Do the relays have the same, non-default exit policy? - Do the relays have a similar uptime? - Do the relays run on the same platform? To give you an idea of what this looks like, I took all relay descriptors archived by CollecTor [1] for 2015-05-30 and calculated similarities by running: $ sybilhunter -data 2015-05-30/ -cumulative -matrix -threshold 6 -visualise > sim.dot $ dot -o sim.svg -Tsvg sim.dot The resulting graph is online [2]. Vertices are relays (nickname in the first line, followed by the first eight hex digits), and the edge labels show the similarities. Unsurprisingly, there are several relay clusters that probably should be in a family, but aren't. For example, the "startor*", "torpids*", "manningsnowden*", and "Montharkan*" relays. There are, however, also several relay clusters, often named "default", that share the first two hex digits of their fingerprint. This is unlikely to be a coincidence, so they might have wanted to position themselves in the DHT. Please let me know if you have any suggestions on how to improve the tool or its visualisation. [0] <https://gitweb.torproject.org/user/phw/sybilhunter.git/> [1] <https://collector.torproject.org/recent/relay-descriptors/server-descriptor…> [2] <https://www.nymity.ch/sybilhunting/svg/2015-05-30_similarities.svg> Cheers, Philipp

1 0

How to connect test tor network from remote host.
by Mohiuddin Ebna Kawsar 30 May '15

30 May '15

Hi, I setup Tor Test-Network in my laptop using chutney with basic-min configuration and i also configured tor-browser with this test network to browse internet. But now i want to bootstrap Test Tor-Network inside Virtual Machine. (Virtual Machine 1 = (3 AUTHORITY + 1 RELAY) IP= *10.0.2.11* (Virtual Machine 2 = (tor-browser) IP= *10.0.2.9* But this time tor-browser is not bootstrapping. I can ping from (11 to 9) torbrowser torrc config () ############################################### AllowSingleHopExits 1 CircuitIdleTimeout 100 DataDirectory tor-browser_en-US/Browser/TorBrowser/Data/Tor DirReqStatistics 0 DirAuthority test000a orport=5000 no-v2 hs v3ident=32D2EB75473AB923F63D0D3C4B6929FC1BB658AE *10.0.2.11*:7000 1DB6AEADE945A2EE1722A203CFED30478D0C8C82 DirAuthority test001a orport=5001 no-v2 hs v3ident=0D6042A1C288C7891888248CDDAA58D9B907ECF1 *10.0.2.11* :7001 84B06F3CF268D941CD11E725AACA287152C90C70 DirAuthority test002a orport=5002 no-v2 hs v3ident=AD22661D7D85F72D3D24B789092F8BE4454EFFAC *10.0.2.11* :7002 2AFD392AC496045351CCF8CBF148944FEF0AEAE4 DisableDebuggerAttachment 0 ExitNodes test000a GeoIPFile tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip GeoIPv6File tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip6 KeepalivePeriod 100 TestingTorNetwork 1 ProtocolWarnings 1 SafeLogging 0 StrictNodes 1 ########################################################################### Please help..

2 7

Adding a NotDir router status flag
by Matthew Finkel 29 May '15

29 May '15

Sadly it took a few months for me to get back to prop 237 (All relays are directory servers), but now I have a revised version of the proposal and updated tor[0] and torspec[1][2] branches. These will benefit from your review. Previously, proposal 237 took advantage of the V2Dir flag because Authorities already vote on it and it accomplished 90% of what we need. But I realized that's not exactly what we want. Now the proposal introduces a new status flag, NotDir. The reasoning for this is the V2Dir flag indicates a router (is expected to) respond to directory requests, usually, because the operator configured the router's DirPort. But, in a network where nearly all relays are directory servers, why are relays with the V2Dir flag special? Basically, after this proposal is implemented nearly every relay should receive the V2Dir flag, so the NotDir flag is the complement of V2Dir. This allows the V2Dir be deprecated at some time in the future. Thoughts? Thanks, Matt [0] https://git.torproject.org/user/sysrqb/tor.git, feature12538_rebased_6 [1] https://git.torproject.org/user/sysrqb/torspec.git, prop237_update [2] feature12538

2 1

Is it okay to use Debian Jessie for development?
by l.m 28 May '15

28 May '15

Hello, I probably should have asked this sooner. How quickly does tor project upgrade to the latest Debian stable on development machines [0] ? Thanks in advance. --leeroy [0] https://db.torproject.org/machines.cgi

1 0

[RELEASE] Torsocks 2.1.0
by David Goulet 28 May '15

28 May '15

Hi everyone! This is the release for version 2.1.0 of Torsocks. Special thanks to Yawning that helped a lot with the new features, finding bugs and providing patches! Also, thanks to all contributors and users out there providing us with feedbacks! :) Changes that are worth mentionning: - Support for TCP fast open. - AllowOutboundLocalhost option allows torsocks to connect to a localhost address. - IsolatePID is a new option that will make torsocks set the SOCKS5 username and password automatically to provide isolation on Tor side. You can use this with the -i,--isolate command added or TORSOCKS_ISOLATE_PID env. variable. - Fix initialization phase when used with C++. - Way less annoying warnings of syscall being denied. Most of them were harmless so we let them pass now. - Multiple fixes! (see changelog below) Here is the change log for this version. 2015-05-27 torsocks 2.1.0 * Fix: socks5 resolve wasn't sending data correctly * Fix: wrong label when auth_socks5 fail * Move SOCKS5 auth in a seperate function * Send the SOCKS5 authentication for RESOLVE/RESOLVE_PTR requests. * Change IsolatePID password from 42 to 0 * Add automatic per process isolation (IsolatePID) * Ensure that torsocks initializes itself in the presence of C++. * Merge remote-tracking branch 'yawning/getaddrinfo' into getaddrinfo * Fix: indentation in getpeername test * Merge remote-tracking branch 'yawning/getpeername' * Add support for the various inotify routines when invoked via syscall(). * Support the eventfd2(2) syscall. * Support the various epoll routines when invoked via syscall(). * Handle accept4(2) when invoked via syscall(). * Fix getaddrinfo() to respect AI_NUMERICHOST. * Fix the broken getpeername() implementation. * Support certain Linux specific syscalls. * Allow TCP Fast Open clients go through tor * Test: support out of tree make check * configure.ac: avoid tests which have both -pie and -static * Fix error messages about setuid/setgid executables * Fix: switch back to a syscall whitelist scheme * Add AllowOutboundLocalhost. * Fix: syscall mmap for NetBSD * Fix: use getsockname instead of getsockopt to get socket family * Stop denying syscall() and add dangerous ones * Fix: typo in the listen macro declaration * Fix: improve getpeername to actually works * Fix: improve Unix socket passing detection * Test: add missing connection destroy * Test: possible double free in onion test * Test: fix memory leak in DNS test * Add accept as an accepted value through syscall() * Add cscope files to gitignore Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://gitweb.torproject.org/torsocks.git Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.1.0.tar.bz2.asc) Cheers! David

4 4

Re: [tor-dev] [tor-talk] [RELEASE] Torsocks 2.1.0
by David Goulet 28 May '15

28 May '15

On 27 May (18:14:37), Yuri wrote: > On 05/27/2015 12:19, David Goulet wrote: > >Hi everyone! > > > >This is the release for version 2.1.0 of Torsocks. Special thanks to > >Yawning that helped a lot with the new features, finding bugs and > >providing patches! Also, thanks to all contributors and users out there > >providing us with feedbacks!:) > > Hi David, > > Why didn't you merge all pull requests for the release? Hello! What other pull requests are you talking about? There are a couple of open tickets that need more time and thinking so I released this one because of the amount of fixes that has been accumulating. Cheers! David > > Yuri

1 0