[tor-dev] working back to socks_request_t
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/24f170a11f59e26dec3a24d076b749c8acc793ca/src/or/connection.c#L1865 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? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] design for a Tor router without anonymity compromises
On Sat, 2 May 2015 20:37:17 -0700 coderman coder...@gmail.com wrote: a friend and i are working on a Tor router design that doesn't compromise anonymity for convenience. [0][1][2][3][4] we're soliciting feedback as part of a go / no-go decision on continuing this effort. in particular, the design is intended to meet the scrutiny of Nick M., Roger, and Mike P. as the focus on support for Tor Browser and Tor on each client indicates. I am bored so I figured I would read this big document, here are some comments from somebody who doesn't matter: 1.3 Warning conditions: Is the Client privacy leak detected meaning the software would warn in the case of a LAN client attempting to make an unsecured connection or leak DNS data or somteihng like that? Provided the leak never makes it off the routing device, then I think that is an acceptable warning but if it leaves the device that's a pretty critical error in my opinion. 2.4 Device software and configuration technical requirements Require VPN on local WiFi and Ethernet network does this mean VPN connection to the router itself, as in establishing an IPSec tunnel from LAN_1 -- [Router] before any layer four traffic is allowed? I see the FAQ about Wifi, which makes sense, but extending the VPN requirement to the physical network I find odd. 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. 2.5/2.6 Privacy Directory Requirements Is the expectation that every client attached to the router would be running this privacy directory software or only the router administrator(s)? In the former case, is there any bad exit indication that could/would be made to the clients? How is authentication and authorization of this privacy director software going to be performed with the router? In 1.2 the router would be passwordlessly set up, but after that how would an administrator ensure that only they are able to mutate the device set up? Also Filter local traffic that is not Tor when active, does this mean that the privacy director software will require escalated privileges on the numerous platforms into order to modify local firewall states? Interesting effort, good luck -warms0x ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] design for a Tor router without anonymity compromises
On 5/3/15, warms0x warm...@riseup.net wrote: ... I am bored so I figured I would read this big document, here are some comments from somebody who took the time to care: thanks! :) 1.3 Warning conditions: Is the Client privacy leak detected meaning the software would warn in the case of a LAN client attempting to make an unsecured connection or leak DNS data or somteihng like that? correct. the client is filtering locally, and only expecting Tor Browser traffic to egress. if anything else is sent, not through Tor relays, it is dropped and warned about. Provided the leak never makes it off the routing device, then I think that is an acceptable warning correct. this leak traffic is dropped, then warned about. 2.4 Device software and configuration technical requirements Require VPN on local WiFi and Ethernet network does this mean VPN connection to the router itself, as in establishing an IPSec tunnel from LAN_1 -- [Router] before any layer four traffic is allowed? I see the FAQ about Wifi, which makes sense, but extending the VPN requirement to the physical network I find odd. this is for three purposes. 1. WiFi is inherently insecure, per the RC4 defect. 2. if using open WiFi (no WPA-2 Enterprise EAP-TLS, nor any lesser privacy setting) you avoid TCP and other injection DoS attacks. 3. the privacy director is better able to transition between Public networks / Tor enforcing network if the VPN up is used as successful signal of pairing to expected router. Otherwise un-authenticated details like IP, MAC, hostname provide only tentative indication of Tor enforcing router upstream. 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. 2.5/2.6 Privacy Directory Requirements Is the expectation that every client attached to the router would be running this privacy directory software or only the router administrator(s)? In the former case, is there any bad exit indication that could/would be made to the clients? only the owner is required to run this software. it is recommended that other users on the Local network also run it, for the additional support it provides keeping Tor Browser current and handling local egress filtering when on a Tor enforcing network. bad exit reporting requires the privacy director software, either as owner or normal user. there is no way to report bad exits through captive portal web UI on device. How is authentication and authorization of this privacy director software going to be performed with the router? In 1.2 the router would be passwordlessly set up, but after that how would an administrator ensure that only they are able to mutate the device set up? as device owner, the first time setup, which requires directly connecting to the device, provides key exchange for the remainder of administrative activities. if you're not owner of the owner keys, you don't get to perform any administrative actions on the device. Also Filter local traffic that is not Tor when active, does this mean that the privacy director software will require escalated privileges on the numerous platforms into order to modify local firewall states? yes to modify firewall state. it is possible to run without elevated privileges, however, filtering traffic and disabling services cannot be performed and some automatic behaviors become manual (e.g. auto detecting transition on or off of a Tor enforcing network does not work in some scenarios, and the privacy director menu must be used to explicitly update view.) it is possible to constrain the delegation of these privileges, like sudo for calling hooks around network changes, however this is currently outside scope given the poor state of client side security posture overall. Interesting effort, good luck thanks for the feedback! we'll need the luck... best regards, ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] working back to socks_request_t
Date: Sun, 3 May 2015 12:34:51 -0400 From: CJ Ess zxcvbn4...@gmail.com On Sun, May 3, 2015 at 11:06 AM, teor teor2...@gmail.com wrote: Date: Sun, 3 May 2015 02:50:46 -0400 From: CJ Ess zxcvbn4...@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/24f170a11f59e26dec3a24d076b749c8acc793ca/src/or/connection.c#L1865 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
[tor-dev] Damian's Status Report - April 2015
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] design for a Tor router without anonymity compromises
On 5/3/15, intrigeri intrig...@boum.org wrote: ... Just to clarify, the threat model explicitly doesn't include Attacker is able to reconfigure Tor on a client system to use an arbitrary set of bridges, right? correct. neither bridges nor pluggable transports are supported. i have added a FAQ entry for this. thanks! in the future, it would be useful to have a way to securely distribute bridges or obfuscated proxies to trusted user on the local network. however, this is not a trivial task, and you'd want to avoid compromising all of your bridges at once if a failure occurs. last but not least, if your attacker is coordinating the attack over Tor, obviously this cannot be thwarted at the local network level by a Tor router device. host security is critical, even with a Tor enforcing router as backup. that's a longer subject i need to think about more before writing anything useful. best regards, ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] working back to socks_request_t
Date: Sun, 3 May 2015 02:50:46 -0400 From: CJ Ess zxcvbn4...@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/24f170a11f59e26dec3a24d076b749c8acc793ca/src/or/connection.c#L1865 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] working back to socks_request_t
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. On Sun, May 3, 2015 at 11:06 AM, teor teor2...@gmail.com wrote: Date: Sun, 3 May 2015 02:50:46 -0400 From: CJ Ess zxcvbn4...@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/24f170a11f59e26dec3a24d076b749c8acc793ca/src/or/connection.c#L1865 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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
