[tor-relays] clarification on what Utah State University exit relays store ("360 gigs of log files")

[Sharif Olorin]

> So in the bro-based system (which sounds higher resolution) the final
> logged data was second-precision timestamps on full connection tuples?

It's not higher-resolution, it just has different defaults. I can
configure bro to capture/retain anything I want, up to and including
every datagram passing through the interface.

> So if I have a connection to a Tor Guard node opened for 8 hours, at the
> end of the session, your system would record a single record with:
> (my_ip,my_port,guard_ip,guard_port,tx,rx,timestamp_open,timestamp_close)

Not a single record, no. Have a read of the docs, or try it for
yourself: https://www.bro.org/documentation/index.html

You can just set bro up to capture packets on your local machine or network.

> I think any system that is storing connection-level data (as opposed to
> one record per timeslice of activity on a tuple) is likely to be rather
> easy to defend against correlation.

As I alluded to earlier, these systems typically work with network flows, not
TCP connections.

> Well, it seems harder to store a full connection tuple for open until
> close, because you have no idea when the connection actually closed
> (unless you are recording a tuple for every second during which there is
> any activity, or similar).

The raw capture is usually the latter; sometimes with stateful monitors these are
postprocessed/aggregated into connections, depending on configuration.
Again, the docs are out there and you can just run the system for
yourself - I recommend setting it up on your home network for a week
and seeing what you get. :)

-- 
OpenPGP: 6FB7 ED25 BFCF 3E22 72AE 6E8C 47D4 CE7F 6B9F DF57
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150814/131615e0/attachment.sig>