tor-dev

tor-dev@lists.torproject.org

3581 discussions

Re: [tor-dev] working back to socks_request_t
by teor 05 May '15

05 May '15

> Date: Mon, 4 May 2015 16:07:20 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > Thanks for going into so much detail, you've given me a lot to think about. > The real solution is probably the one that nobody wants to take on - having > an application HTTP port that could take direct input from HTTP aware stuff > and utilize a richer set of information then SOCKS allows for. I've spent a > couple evenings looking to see if I could take the code stuff from the > dirport and use it for that purpose. I need to spend another couple > evenings and and go back and look at the SOCKS4 stuff, I've just recently > realized that the state machine for that is closer to an http > request/response. CJ, Pluggable transports are designed to arbitrarily change how tor makes outgoing connections. The existing transports are used for obfuscation, but they could be used for dynamic proxy authentication as well. (Some do take authentication arguments.) You'd just have to work out which user to authenticate each tor connection with - which is a difficult question of policy. This arises because tor only makes a small number of long-term connections to a few guard nodes, and multiplexes multiple streams over these connections. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

Re: [tor-dev] working back to socks_request_t
by teor 04 May '15

04 May '15

> Date: Sun, 3 May 2015 12:34:51 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > On Sun, May 3, 2015 at 11:06 AM, teor <teor2345(a)gmail.com> wrote: > >>> Date: Sun, 3 May 2015 02:50:46 -0400 >>> From: CJ Ess <zxcvbn4038(a)gmail.com> >>> >>> So I'm doing a bit of an experiment, the idea being that if you have a >>> group of tor users sharing common infrastructure then its a slightly >>> different situation then one lone user, and you wantto emphasize that >>> resources should not be shared, caching should be minimal and >>> non-persistent, you need to keep usage from standing out, etc. … >>> So plan B is everyone involved runs their socks speaking browser on their >>> desktop/laptop, everyone runs a tor client on the same device as their >>> browser, we use the HTTPProxy/HTTPSProxy feature of the clients to navigate >>> the firewall, everyone uses their own credentials instead of having one ID >>> draw attention for high utilization, and the presence of >>> the Proxy-Authorization header takes care of any caching/session sharing >>> issues along the way. >>> >>> To make that work, the one question I have for tor-dev is if its possible >>> Here: >>> >>> https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc7… >>> >>> To work back to the socks_req, so that I can pass through the username and >>> password to the upstream proxy instead of the one global username/password? >> >> Hi CJ, >> >> It sounds like you're looking for one of the HTTP(S)ProxyAuthenticator >> options - you can configure a different username and password in the torrc >> file on each client's desktop/laptop. >> >> … >> >> If these options aren't what you're looking for, can you explain what you >> want done with the SOCKS request in a bit more detail? > > So underlying idea in this case is to pass thru the proxy credentials from > the browser, so they don't have to be had coded in plain text in the tor > config - you exit the browser and the credential goes away (or maybe its > encrypted in the browser password manager), if you change your password you > don't have to go update the tor config and bounce it, if its a shared > device you don't have to reconfigure and possibly leave your credentials > around, etc. > > That sounds good conceptually, but to implement I somehow need to work back > from the connection_t passed into the function I mentioned to something > that has the socks info (circuit? associated edge connection?) I tried to > trace it though and nothing jumped out at me but maybe there is some type > casting happening and I'm missing it. The other option would be to pass the > info down through extra arguments or copied into extra field members. > Either way I'm speculating there might be a really simple way to do this > and worth the time writing up the question. If I get it working I'd be > happy to send in a patch to the this list. Hi CJ, There isn't a one-to-one correspondence between web browser SOCKS connections and Tor connections: 1. Each SOCKS connection results in a stream, and tor multiplexes multiple streams over multiple circuits through the same connection to the first hop in the path. 2. tor also initiates streams, such as directory fetches, without any corresponding SOCKS connection from the browser. 3. tor pre-emptively launches circuits, then uses them for client connections once a SOCKS request is received. 4. tor sometimes cannibalizes existing circuits by adding a hop to them. tor makes a connection to 1-3 guard nodes, and those connections carry the majority of the web browser SOCKS traffic. They are authenticated at tor launch, before any browser makes a request, and I'm pretty sure that's it for authentication from then on. If you could get authentication passthrough working, you'd still run into the following compatibility issues: 5. Tor Browser uses the input SOCKS username (I think) to manage stream-based isolation for different tabs, based on the URL. This would prevent you using Tor Browser with your modified version of tor, leaving you with a browser with fewer anonymity protections. 6. Some pluggable transports use the output proxy username to pass arguments. This would prevent you using pluggable transports with your modified version of tor. And the following anonymity / usage issues: 7. If each SOCKS connection has a corresponding circuit, and you identify the user who initiated the circuit, you make it easier to de-anonymise the user behind the circuit. 8. Given that tor can multiplex multiple users over each circuit, who is responsible for bandwidth over-use? If you're still keen on continuing, the closest that the socks authentication details get to where you need them is in conn->socks_request in circuit_get_open_circ_or_launch(). The call stack from then on is: circuit_launch_by_extend_info() circuit_establish_circuit() circuit_handle_first_hop() channel_connect_for_circuit() channel_connect() channel_tls_connect() connection_or_connect() Which initialises the or_connection_t struct "conn", then makes the connection to the proxy (if set). You could add the username and password to the conn data structure here. When the connection has finished connecting, the callback is: connection_or_finished_connecting() Which calls: connection_proxy_connect() Which could then use the username and password from the conn data structure, if they exist - otherwise, it could use the default set in the config. I still think you'll get the default authentication most of the time, because of tor's pre-emptive guard connections. When you reply, can you avoid top-posting? Some mail clients top-post by default. But it's easier to follow the conversation if replies come after the initial email. Feel free to reply in the middle of the email as well. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

Re: [tor-dev] design for a Tor router without anonymity compromises
by teor 04 May '15

04 May '15

> Date: Sun, 3 May 2015 16:23:08 -0700 > From: coderman <coderman(a)gmail.com> > >> I suggest also adding mandatory audit logging to the scope of the >> router software. In my opinion any and all state changes, whether >> automatic (Tor circuit change) or manual (administrator changing >> configuration) must be logged. > > this is an important detail; thank you for bringing it up. i will add > the expected run logging and troubleshooting logging output collected > on device and available to the owner via privacy director > administrative access. Some users will want as little logging as possible, as it can lead to privacy leaks if the device is compromised - may I suggest you turn it off by default? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

Damian's Status Report - April 2015
by Damian Johnson 04 May '15

04 May '15

Hi all! My April was split between SoP prep and Nyx. Changes for the later unfortunately aren't yet ready so this is gonna be a shorter status report than usual. -------------------------------------------------------------------------------- Tor Summer of Privacy -------------------------------------------------------------------------------- It's a thing! Of our twenty-two applicants sadly we only had funding for four, but all have great projects and we look forward to working with them this summer! https://blog.torproject.org/blog/tor-summer-privacy-projects Personally I'm particularly excited since this will be the first time I've mentored since 2012. Cristobal's working on a web dashboard for relay operators - think nyx, but ajax... https://leivaburto.github.io/sop-proposal/ -------------------------------------------------------------------------------- Few other noteworthy things were... * Built on David's hidden service descriptor work by adding a get_hidden_service_descriptor() method to Stem. Next up is support for Yawning's ephemeral hidden services... * Sambuddha revised Stem's Twitter example to support Twitter's v2 API. (#9003) * Stem test for installation via our setup.py. (#15258) Cheers! -Damian

1 0

Re: [tor-dev] working back to socks_request_t
by teor 03 May '15

03 May '15

> Date: Sun, 3 May 2015 02:50:46 -0400 > From: CJ Ess <zxcvbn4038(a)gmail.com> > > So I'm doing a bit of an experiment, the idea being that if you have a > group of tor users sharing common infrastructure then its a slightly > different situation then one lone user, and you wantto emphasize that > resources should not be shared, caching should be minimal and > non-persistent, you need to keep usage from standing out, etc. The problem > with my original idea is that everything that does HTTP <> SOCKS is one or > two decades old, and draws a lot of attention because it forks for every > connection or is some strange process that nobody has ever seen before. > > So plan B is everyone involved runs their socks speaking browser on their > desktop/laptop, everyone runs a tor client on the same device as their > browser, we use the HTTPProxy/HTTPSProxy feature of the clients to navigate > the firewall, everyone uses their own credentials instead of having one ID > draw attention for high utilization, and the presence of > the Proxy-Authorization header takes care of any caching/session sharing > issues along the way. > > To make that work, the one question I have for tor-dev is if its possible > Here: > > https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc7… > > To work back to the socks_req, so that I can pass through the username and > password to the upstream proxy instead of the one global username/password? Hi CJ, It sounds like you're looking for one of the HTTP(S)ProxyAuthenticator options - you can configure a different username and password in the torrc file on each client's desktop/laptop. If you are going to run a SOCKS-speaking browser, why not run the Tor Browser? It does a lot more to protect your anonymity than most. From the tor manual page: HTTPProxyAuthenticator username:password If defined, Tor will use this username:password for Basic HTTP proxy authentication, as in RFC 2617. This is currently the only form of HTTP proxy authentication that Tor supports; feel free to submit a patch if you want it to support others. HTTPSProxyAuthenticator username:password If defined, Tor will use this username:password for Basic HTTPS proxy authentication, as in RFC 2617. This is currently the only form of HTTPS proxy authentication that Tor supports; feel free to submit a patch if you want it to support others. If these options aren't what you're looking for, can you explain what you want done with the SOCKS request in a bit more detail? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

working back to socks_request_t
by CJ Ess 03 May '15

03 May '15

So I'm doing a bit of an experiment, the idea being that if you have a group of tor users sharing common infrastructure then its a slightly different situation then one lone user, and you wantto emphasize that resources should not be shared, caching should be minimal and non-persistent, you need to keep usage from standing out, etc. The problem with my original idea is that everything that does HTTP <> SOCKS is one or two decades old, and draws a lot of attention because it forks for every connection or is some strange process that nobody has ever seen before. So plan B is everyone involved runs their socks speaking browser on their desktop/laptop, everyone runs a tor client on the same device as their browser, we use the HTTPProxy/HTTPSProxy feature of the clients to navigate the firewall, everyone uses their own credentials instead of having one ID draw attention for high utilization, and the presence of the Proxy-Authorization header takes care of any caching/session sharing issues along the way. To make that work, the one question I have for tor-dev is if its possible Here: https://github.com/torproject/tor/blob/24f170a11f59e26dec3a24d076b749c8acc7… To work back to the socks_req, so that I can pass through the username and password to the upstream proxy instead of the one global username/password?

1 0

onionoo: historic details.json data
by Nusenu 02 May '15

02 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Karsten, can one download historic onionoo documents (details.json) archived somewhere or would one have to setup onionoo + feed old data into it to achieve that? thanks, Nusenu -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVIaqIAAoJEFv7XvVCELh0OQgP/3FiBM3uMifPW9A0u8sMuh1E 7iFDmU52MNmkeToBUnuxuUK+7ig96tz/p5Ds6OyaAtC0Ld/IzRlIU5ELjqDwRqMD LPaafWm21QHO8y4fgW5FfGDfFTeLL/b3Lm1E9VmJ8wpOsgpzNnBMUoeDrpDyE3Ow zHXM/IfCSROqmO9lOeU6YGQTwInucc0HSveAWQ9i/x6iks9kMguzGnuWTxgfwA61 RQT4KUKZI+b5w//8V3/IpR5jlQ2N4OJrURpVhaKKNYMy+mqOfl5/a1ZPyQhhDaxj eLfg0qQmsk9IJY/6dZa0XogsmAzRCcEO/Ha0b0ZoiWs+VFo97cczoWdVWHoKpsyS X/qeehkOS13l22mw8va+yuj4zoRBrgK2chzcG2iPgVBeTu1H7B+x57PQrQXaCdaf rq8wwlS7mgaMQ6mgHyOQ1niZDTnvJaY0e3gVsgucR7YOTdALxnnHhQkyNboCWq/E 180SetWZfIHbL3cV38DRxYKzijwSu1gqmkwTJWffylb5SMja1TdW9cCq/RzidqyF v7vLXHQwmrRQ0XOy9UULe5XtU0Fe4YCm/zMNzBHHGIrePd664mYKqqXP2dlempwb BbbVgMLuFC2sy2eqxtwyQrrDUoWrEovUxg/BeoKO8RYXzNhPtha8eQkAhexhNux2 2mosesv/fooaQnt17qAo =q6LM -----END PGP SIGNATURE-----

6 16

#14995: systemd unit files - review
by Nusenu 02 May '15

02 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi weasel, following your comment [1] about your plans to use systemd instead of init.d scripts I prepared unit files [2] - tested with debian jessie. Would be great if you could comment on them. Since it feels a bit as if I would use the wrong communication channel (trac), please let me know if I should move this elsewhere. thanks, Nusenu [1] https://trac.torproject.org/projects/tor/ticket/14995#comment:14 [2] https://trac.torproject.org/projects/tor/ticket/14995#comment:24 https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… https://github.com/nusenu/tor-multi-instance-initscripts/blob/master/debian… -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVFqosAAoJEFv7XvVCELh0AjgQAIlLflC6f+mqUUiAyvQsTO/4 +fNK1MBFUNJUpEws3gqD/3OQfBnhuV9Po4SiRMPfQo0IHuLSB0jNHslOexVBWzpY s4ypeNAH+Eu58Pomexo9xOMCZTmM7Jmhm8HdCodSXBMSKlK1jMwqqmRRQDnijf3T hYos6yeJydwXnV2yDaeF6AOiuAzIQC2s+Mwu+tynX3ETCIyDzsDcQEOaDiwnmWBX 76kIqz0sF0N7tOeMiLoMvK1J9HhW+sMH4aaGwZFXPCMLEpziIB5spEmgvpa+SoQ0 dG2q3Hd7ryBaac/KSeX/Dyidur8LxheA9slVqwkdcorXWBdQd7Xnom2WTOs/2cSf Dy3ZFJD1vi3/y6Gq0DsWY3Z4XhPPs4gTVOL056Xc/GyZXmPvAVI5mk8EdtU7ezbu NxXqjVoEcX59IWhyMOjh2eaeEZvaxmyfP38ek2f6nH5pZv9FtmjKZ61LwYtL8qJx wEn+qIVXy1Zl+qU/NhUpMeUqn029Ci+mL+6x/JfNpaka81Rtqsb+6SKQQwPwGGu7 2SwsDjM+B6YsWSf3niL3rp23XWaT1mM830QBnTrMpE+kht/4b1ytgs7NV72E30+5 Ibi5y/F/TkTc6yExJd1qxKkpXY0gnEWIgf0l4ik5FOD3DK47lQgKYg4feAcPxLUo qFDT5Y0Fnhezh5DVnRp+ =mtYl -----END PGP SIGNATURE-----

3 5

Released BridgeDB-0.3.2
by isis 02 May '15

02 May '15

Hello all, Yesterday I released and deployed BridgeDB-0.3.2, which has several major fixes and changes. Major changes visible to users include: changing the default pluggable transport to obfs4, and users requesting bridges will note that they are again normally receiving the maximum number (3) of bridges. The temporary decrease in bridges was due to the fact that, while rewriting BridgeDB's bridge descriptor parsers (#9380), I implemented full verification of all cryptographic data involved, including signatures and descriptor digests, in order to validate the chain of bridge information from the networkstatus document (produced by the BridgeAuthority), to bridge server-descriptors, and finally to bridge `extrainfo` descriptors (which contain information on a bridge's pluggable transports). This turned out to be somewhat of a bad idea, because the BridgeAuthority appears to not producing good networkstatus documents (see #11216, #12254, #15707, and #15866). Changes in version 0.3.2 - 2015-05-01 * FIXES a problem with the calculation of Levenshtein distances between blacklisted email addresses and those on incoming email. This fixes a problem with the fuzzy matching implemented in #9385: https://bugs.torproject.org/9385. * FIXES #1839 https://bugs.torproject.org/1839 BridgeDB's distributors now rotate their hashrings at configurable scheduled intervals. * FIXES #4771 https://bugs.torproject.org/4771 BridgeDB now records which of the HTTPS Distributor's sub-hashrings are used for clients coming from Tor Exit nodes and other known proxies. * FIXES #12504 https://bugs.torproject.org/12504 Which Pluggable Transports BridgeDB distributes is now easily configurable via the bridgedb.conf configuration file. * FIXES #13202 https://bugs.torproject.org/13202 Old bridges running Tor-0.2.4.x with Pluggable Transports like scramblesuit and obfs4proxy have a bug which causes them to not include the PT arguments in the `transport` line they submit to the BridgeAuthority in their extrainfo descriptors. This causes BridgeDB to have broken bridge lines for these bridges. For example, scramblesuit requires a `password=` in the `ClientTransportPlugin` for clients to connect to it. If BridgeDB receives a line in that bridge's extrainfo which says `transport scramblesuit 1.2.3.4:1234` (without a password), then when BridgeDB gives clients a bridge line for that bridge, it'll look like "Bridge scramblesuit 1.2.3.4:1234" - meaning that it won't work. This fixes the issue by excluding broken transports from being distributed to clients. * FIXES #15517 https://bugs.torproject.org/15517 For all clients who are coming from IPv6 addresses and are not using Tor, who go to https://bridges.torproject.org, BridgeDB now groups these clients together by /32. This "grouping" causes all IPv6 clients within the same IPv6 /32 to get the same bridges. Previously, BridgeDB grouped IPv6 clients by /64 (which is ridiculously small, considering standard IPv6 allocation sizes). For all clients who are coming from IPv4 addresses and are not using Tor, BridgeDB now groups these clients together by /16. Previously, BridgeDB grouped IPv4 clients by /24. (This latter change was technically made as part of #4771.) * FIXES #15464 https://bugs.torproject.org/15464 The setup procedure for creating a BridgeDB Continuous Integration build machine is now simplified and generalised to include build environments like Jenkins, not just TravisCI. * FIXES #15866 https://bugs.torproject.org/15866 BridgeDB now ignores nearly all the information in the networkstatus-bridges file created by the BridgeAuthority. * ADDS benchmark tests to BridgeDB's test suite, and some of BridgeDB's algorithms have been revised to improve their speed. As per usual, the full CHANGELOG is available here: https://gitweb.torproject.org/bridgedb.git/tree/CHANGELOG -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

what capabilities does tor need for reloading?
by Nusenu 29 Apr '15

29 Apr '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, 'systemctl reload tor' fails due to hardening restrictions in tor's systemd service file [1]: CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE Removing that line "solves" the reload issue. Reloading with that line does not generate any tor debug loglines. What capability would one have to add to the list to make it work with CapabilityBoundingSet? thanks, Nusenu testing with: tor 0.2.6.4, jessie/systemd 215 [1] https://gitweb.torproject.org/tor.git/tree/contrib/dist/tor.service.in#n26 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVCVA7AAoJEFv7XvVCELh0bWIQAKfDZdhwrcWzwOHEP/o3FMoa BTkMxjHdEDezlaHd61/XWHC1cYNOi6kqe/xGL1HRMtDwl09tbn3lq0Vty9P9hBP5 ucLaS1Izz0w7VprEd4ZK+/G4pV8Ht6Kjd7LSaV8RsjdCfK9g5WaI/IDIVGbYKUnC NVJxY+XCxZsvMmkfCUo1un6yZ/p0eQEfksDwtDvf7EupIy3o5wYJhM1bcvVzm/3H UenP8t8VBb7TVOBRuZUyMzS173db/SKp2tY1IOiUktzyJqzzck8gPJvQ4l8DoeqM E2yVr+Qvex/IXRx379sJTyBJt9xthC9BS91uUJA0G3dbYVSvRoUN5XDjaqYztSN3 ctkjT3cocLDu43EslGo/Egh+xWTMdnTvcaTIoLkD5IN4FWu3IrjWnG0gOOyNyPf5 F4UfCty5xn9ztb0y7Zf2GOliR9CnkSB8PIuMt4ManvrMGOwYPZw1KsGsc49UYadn XhEUj1uzf3FBZw2LmbiBR5lNGX2WanWt83EwkiH03MsBkouD60+D/RJ5UQ8pVEwm JHLBqbT2GtBCda3OIPec1kdh3P5TFF+aN9aC1HkVsYRwoUJtIjxPg3wkrOVCU4VF ZJVbqlVuJQn8/3GnphkQgt+jJqTl3b4Ttksu+omGJgYU2Wu42VNFvCFraeQ75q4J D1NinH/G/3I3KBYP+JNu =/eJ6 -----END PGP SIGNATURE-----

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev