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

[Mike Perry]

Sharif Olorin:
> Mike,
> 
> Additionally, I should clarify that bro and netflow have some
> fundamental differences and are usually used for different things (but
> both are common in large networks). Bro's very stateful and is more
> focused on IDS-type applications, whereas netflow is more directed
> towards traffic accounting, which is why bro has all the stateful
> stuff about TCP connections. bro would be more commonly found at
> a university, but netflow's probably more relevant if you're looking
> at what the typical ISP will retain for a long time.

Yes, unfortunately this is why "just set up bro/netflow at home and try
it!" is not really helpful. It is obvious that these systems can in
theory be configured to log+analyze all data for all time, especially if
it is just my tiny DSL line with one person browsing the web over Tor
and I have a few TB worth of disk to burn.

However, speculation about the evil BOFH who twiddles his mustache and
tunes netflow to deanonymize all Tor users forever is rather boring to
me. It's a scenario that's unlikely to happen at scale, or be practical
for full analysis of the entire Tor network. Even if we are looking at
such a BOFH in the Utah case, we have yet another datapoint against the
evil BOFH correlation theory: These logs were useless!


The important question to me is: "If we assume honest Tor nodes, what
level of logging is likely to be practiced at their ISP or AS today
without their knowledge, and what technical measures are available to us
to reduce that potential impact?"

In this Utah exit case, the exit operator in question is indeed honest,
and we're looking at an upstream admin who just happened to be logging
stuff, likely as per some standard (if heavy-handed) connection-level
logging policy.

I suspect that type of adversary will be possible to defeat with similar
amounts of padding that will defeat hidden service circuit setup
fingerprinting, website traffic fingerprinting, traffic type
classification, and a host of other low-resource attacks...


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20150813/ce4a9d10/attachment.sig>