[tor-relays] US Investigators seem to learn

Matt Joyce toradmin at mttjocy.co.uk
Fri Feb 22 06:42:39 UTC 2013


On 18/02/13 10:05, Andrea Shepard wrote:
> On Mon, Feb 18, 2013 at 04:59:09AM -0500, grarpamp wrote:
>>> I thought I would let you know: Our US hoster is regularly contacted by
>>> law enforcement about our exits there. Some agents ask if the traffic
>>> pattern is balanced, ie. if the same amount of traffic enters and leaves
>>> the box.
>>>
>>> I always argue that this is a good indicator for Tor traffic, and that
>>> it is bad to mix Tor traffic with other traffic for that exact reason.
>> Due to encryption and compression it might only be balanced to
>> within some typical ratio. I'm sure you have a handle on that number.
>> But that any non 1:1 ratio could make it appear to be serving (or
>> receiving) continual amounts of data. Which in the eye of agents
>> could raise question. Another question is whether these US hosts
>> are just volunteering this data to whoever comes asking, with or
>> without your instruction, or complying with formal legal orders?
>>
>> On the plus side, hopefully everyone is coming away with the
>> fact that it's just an uninteresting, agnostic, relay service and
>> time is better spent elsewhere.
> Interesting; I'm pretty sure we do not use TLS compression.  Nick M., that's
> true, yeah?
>
> On the other hand, it could also be unbalanced because of:
>
>  * Using that Tor process as a client
>  * Running a hidden service on that Tor process
>  * Running a directory mirror
>
>
>
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I would guess also that being an exit is going to lead to a bit of an
imbalance also as on the one side it is dealing with the plaintext
unwrapped data on the other side cyphertext wrapped in onion protocol
all in fixed sized cells which I would suspect means sometimes adding
padding where the data to be sent to a specific nexthop destination is
not an exact multiple of the cell payload size.  I'm not sure how much
of a difference this would all add up to or if some of those effects
might cancel part of it out but it would seem to me that it could have a
statistically noticeable effect on the balance and one that would be
variable between relays and even with the same relay depending on the
balance of exit versus relay traffic which at least with the two exits I
am running that seems to be the case.

Of course the easiest way to deal with those problems from the
perspective of someone trying to identify potential suspicious activity
(And to produce provide probable cause for the same) would be to
statistically compare the balance of node x with the set of nodes of the
same class that could even be why they keep requesting data, samples for
comparison to look for evidence of statistical anomalies.  Also I wonder
what level of detail they are really requesting and or receiving such
data at, they could have other interests too like performing network
analysis on the flows between nodes if they had data on the volume per
peer ip address.

I suspect in this case though that whatever their purposes are they are
approaching the service provider and seeking their co-operation doesn't
sound like they have anything specific let alone a warrant here as it
seems to me more often than not when a warrant is issued in the US
requesting information on a user from a service provider it usually
tends to come with an attached court order forbidding the service
provider from disclosing the details to their subscriber.  It would
surprise me if they would stop at merely asking about traffic balances 
if they had enough to seek a warrant also, would make more sense to at
the least put an ethernet tap on it if not attempt to access the
plaintext through installing something onto the host or the hypervisor
if it's a VPS.

Either way it sounds to me like they are probably fishing in this instance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20130222/2a9d17f8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 295 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20130222/2a9d17f8/attachment.pgp>


More information about the tor-relays mailing list