Proposal: GETINFO controller option for connection information

[Jacob Appelbaum]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100416/e7b00dfb/attachment.pgp>