Damian Johnson wrote:
> Yesterday Jake met with me to discuss this proposal, making the very
> good points that both:
> 1. It's completely ineffectual for the auditing purposes I've
> mentioned since either (a) these results can be fetched from netstat
> already or (b) the information would only be provided via tor and
> can't be validated.
> 2. The things I'm really interested in can be fetched with much less
> (and safer) information.
I still think that anything that can be used to track circuits (and the
clients associated with them) is not a good idea - in Tor or using arm.
We shouldn't encourage people to log, look or otherwise track Tor.
>
> In particular we discussed making the proposal circuit based rather
> than connection based, being something like the following:
>
> "circ/<Circuit identity>" -- Provides entry for the associated circuit,
> formatted as:
> CIRC_ID IN_TYPE OUT_TYPE READ WRITE UPTIME
>
> none of the parameters contain whitespace, and additional results must be
> ignored to allow for future expansion. Parameters are defined as follows:
> CIRC_ID - Unique identifier for the circuit this belongs to.
> IN_TYPE/OUT_TYPE - Single character flags indicating the purpose of the
> inbound or outbound connection. If no connection is established then
> this provides an empty string. Otherwise, it consists of one from each
> of the following categories (this may become longer in future
> expansion):
> Usage Type:
> C: client traffic, R: relaying traffic,
> X: control, H: hidden service, D: directory
> Destination:
> I: inter-tor connection, O: outside the tor network, L: localhost
> For instance, "RO" would indicate that this was an established
> 1st-hop (or bridged) relay connection.
> READ/WRITE - Total bytes read/written over the life of this connection.
> UPTIME - Time the connection's been established in seconds.
>
> "circ/all" -- Newline separated listing of all current circuits.
Both of these seem useful for an administrator that wants to see what's
happening in a very general way. I think that it shouldn't be a
(tracking/logging/etc) risk but I'd like Nick or Roger to comment here.
>
> This would be almost just as useful for the purposes I'm interested in
> while also stripping the most sensitive data entirely (ip addresses,
> ports, and connection based bandwidth breakdowns). In particularly
> this information could still address the following:
>
> - Basic Relay Usage Questions
> How is the bandwidth I'm contributing broken down? Is it being evenly
> distributed or is someone hogging most of it? Do these circuits belong
> to the hidden service I'm running or something else? Now that I'm
> using exit policy X am I desirable as an exit, or are most people just
> using me as a relay?
>
Agreed.
> - Debugging
> Say a relay has a restrictive firewall policy for outbound
> connections, with the ORPort whitelisted but doesn't realize that tor
> needs random high ports. Tor would report success ("your orport is
> reachable - excellent") yet the relay would be nonfunctional. This
> proposed information would reveal numerous RELAY -> YOU ->
> UNESTABLISHED circuits, giving a good indicator of what's wrong.
>
I'm not sure that I follow this? You're saying that Tor can make
circuits to other Tor nodes but not arbitrary things on the internet?
> - Visualization
> This would still yield the benefits mentioned in the last proposal of
> helping to demystify behavior the operator isn't expecting (see the
> client example from before).
I agree.
>
> ----------------------------------------
>
> Second, Jake made a great point that at present if a malicious party
> gets ahold of the control port then the relay's quite effectively
> screwed. The current capabilities of the control port are overkill for
> many controllers (like arm) which are just interested in retrieving
> information from tor (GETINFO options, event listening, etc). To make
> the control port safer we could include a torrc option that makes the
> control port read-only...
>
> SafeControlPort 0|1
> Restricts access of the control port to only include read-only operations.
> (Default: 0)
>
> Making this the default would be a no-go due to vidalia (though still
> a nice option to have...). If this is implemented its setting should
> be part of the PROTOCOLINFO response.
Ah - I'm sorry, I should have been clearer! I meant to suggest another
control port _entirely_:
SafeControlPort Port
SafeControlListenAddress IP[:PORT]
SafeHashedControlPassword
This would mean that you could expose a second control port that is
designed to give generalized, rounded, perhaps even delayed statistical
information to a visualization engine. The first I had in mind was arm
but there could be useful stuff for mrtg or another graphing program. I
don't need or want my graphing programs to have the ability to control
Tor - I just want to get some data out to help me manage my relay.
With that said - I don't think it's a good idea to focus on such a
feature at this time. Work on getting the statistics to your controller
first. When you have a good case for the features being available in a
different, more safe way, you can make it happen.
>
> ----------------------------------------
>
> Finally, the other proposed GETINFO options still seem useful (with
> the possible exception of "info/uptime-reset"), and could be improved
> with the addition of:
>
> "info/user" -- User under which the tor process is running, providing an
> empty string if none exists.
>
You may also want something like the following:
"info/uid"
"info/euid"
"info/gid"
"info/egid"
> "info/pid" -- Process id belonging to the tor process, -1 if none exists for
> the platform.
>
> * this one is both useful and surprisingly difficult for me to
> retrieve at present (arm attempts to get it from pidof, ps, and
> netstat yet still fails on some systems...)
The good news is that it's pretty easy to do in C:
pid_t pid;
pid = getpid(); // see also getppid();
printf("PID is: %d\n", pid);
>
> In addition Jake mentioned the possibility of making info/* options
> for all limits and capabilities (though I'd hold off until we have use
> cases needing them...) and the following entries for getting activity
> snapshots:
>
> "info/relay/[read, write]/avg/[1, 5, 15]" -- Provides the average traffic
> (bytes read or written per second) over the last 1, 5, or 15 minutes.
>
> "info/relay/circ/avg/[1, 5, 15]" -- Provides the average number of circuits
> established in the last 1, 5, or 15 minutes.
>
This allows you to make a nice 'uptime' visualization within an instant
of connecting to the control port.
It was good to talk with you yesterday, I think you're on the right path.
All the best,
Jake
Attachment:
signature.asc
Description: OpenPGP digital signature