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. :)