[tor-talk] on the topic of tor's weaknesses
Joe Btfsplk
joebtfsplk at gmx.com
Sat Feb 25 22:30:42 UTC 2012
On 2/25/2012 3:23 PM, Chris Wheeler wrote:
> Joe, I don't think that the order that the packet are sent
> and received from the exit relay really changes the ease of correlation,
> since they will arrive to the other end of the network in the same order.
1st, thanks for reply. You misunderstood (I think). I didn't mean the
order packets are sent / received to & from the EXIT node (from final
destination site). I meant the order of packets being switched BETWEEN
the exit node (receiving pkts back from destination site) AND the
original entry node (now delivering pkts back to Tor user's ISP. I
meant mixing order of pkts INSIDE the Tor network. Perhaps also adding
enough junk pkts to make it impossible to correlate pkts returning from
destination site to exit relay, with those leaving the entry node, back
to user's ISP.
Now, router firewalls know what data was requested & typically deny
anything - inbound - that wasn't requested. But, could there be a way
around the pkts being in the exact same order when they left the website
as when they leave the entry node back to the ISP? TCP? We don't need
no stinking TCP.
> But maybe the middle relay could be the one who re-arranges the packets.
> Delaying some and expediting others randomly. TCP handles out of order
> packets badly by my understanding, it just requests them again in the
> correct order.
This is where looking at changing the fundamental way Tor network
handles the pkts comes in.
> There would need to be a protocol wrapped around the TCP
> stream being proxied that puts them back in order at the exit and entrance
> relays transparent to the TCP stream. Sounds possible to me. But you know,
> even if you didn't rearrange them and just randomly delayed each packet
> (but kept them in order) at each hop it seems that would make
> it impossible to correlate. Unless maybe if there were only one stream
> passing through a node at a given time (which is pretty likely to happen on
> new bridges). To solve that problem you could have each node always sending
> and receiving by just sending "junk" packets (whole packets of padding)
> around the network. Once they hit an exit node the exit would decrypt them,
> see they were just padding and toss them out. That would create more
> overhead but might be worth it.
Your reply is the type of beginning to look at completely different ways
the Tor network would handle data. It will take a lot of people
thinking outside the box.
>
> On Sat, Feb 25, 2012 at 3:49 PM, Joe Btfsplk<joebtfsplk at gmx.com> wrote:
>
>> On 2/25/2012 12:41 PM, Xinwen Fu wrote:
>>
>>> Chris,
>>>
>>> An attack may only work under its own threat model (capabilities and
>>> resources an adversary has). If entries and exit are all secure, some
>>> correlation attacks may not work. However, if the adversary can still
>>> observe (not need to compromise Tor routers) the traffic into and out of
>>> entries and exits, some attacks may still work, e.g., by correlating the
>>> traffic patterns at the two sides of a circuit. Here is a paper describing
>>> such possibility:
>>> http://www.cs.uml.edu/~**xinwenfu/paper/TorCellSize_**ICC11_Fu.pdf<http://www.cs.uml.edu/~xinwenfu/paper/TorCellSize_ICC11_Fu.pdf>
>>> .
>>>
>>> Hope it helps a bit.
>>>
>>> Xinwen Fu
>>>
>> Thanks for the link, Xinwen. I have a more basic question regarding the
>> original question of adversaries somehow getting access to BOTH entry&
>> exit nodes, that lots of users probably are curious about. Re: getting
>> enough data (even if they could break encryption, if using * SSL *) to do
>> any good. Since Tor / Vidalia changes nodes often (is it at least every 10
>> min, at most? -& more often if a circuit fails), could an adversary get
>> enough data about ONE user to do any good?
>>
>> In this case, is the threat that the adversary will ONLY be able to
>> identify that one is USING Tor network (not capture the actual data
>> transferred), assuming they have access to the * originating IP address,*
>> going to the entry node AND also to the exit node? I suppose (for now),
>> adversaries in repressive countries determining that one is USING Tor is a
>> big problem. Not so much in "free" societies, but that could change.
>>
>> What effect, if any, would Tor changing relays more frequently than the
>> current default time, have on ability of adversaries tracking users (in a
>> meaningful manner) from entry to exit nodes?
>>
>> In Tor network, does the data packet size& order, in& out of entry or
>> exit nodes necessarily HAVE to be the same? Would it be possible to make
>> the in& out packet sizes different sizes, or mix the order of packets at
>> an exit vs entry node? (I don't know the technicality of how this would
>> work). If you d/l a torrent (as an example), you don't receive the file
>> pieces in order. Is it theoretically possible the Tor network could
>> develop a way to mix up the packets (of a file), within the network, so
>> that even if an adversary had complete access to a given entry& exit
>> node(s), the data going in one end could never be matched w/ data coming
>> out? (don't answer too quickly! Never say never)
>>
>> This is also somewhat similar in concept to the old data correction
>> process, where pieces of a file might be re transferred (due to
>> corruption), much later in the d/l process, after most of the file was
>> already downloaded.
>>
>> The theoretical concept I'm pondering is, could all pieces of data
>> transmission through Tor be scrambled (the order and / or size) on purpose?
>> Adversaries generally can't read the actual data because of encryption (if
>> I understand). If there was also no correlation of packets (to an outside
>> observer) at one end vs the other, how could they ever track a user by
>> traffic analysis? Adversaries would theoretically have to monitor ALL
>> relays, ALL of the time.
>>
>> Even then, how would they track a user, end to end, if the packet order is
>> purposefully& randomly jumbled within the network? It seems that the
>> current Tor network model will come under ever increasing attacks /
>> monitoring& needs to change the fundamental way it operates.
>>
>> To some avg users, it might seem there is no way around a determined
>> adversary determining they are using Tor (with current Tor network
>> technology).
>> If an ISP sets up an entry relay or bridge& exit relay, you could be
>> screwed.
>> If a user goes through a proxy to Tor, and an adversary runs the proxy
>> (how do we really know?), you could be screwed.
>>
>> I could go on& on w/ scenarios. Lots of people throw around the phrase,
>> "Users have to determine their threat model..." Quite honestly, most
>> people wouldn't know how. For avg users, advanced users may as well say,
>> "We have no idea. You're own your own. Don't assume you'll be anonymous,
>> even if you follow directions exactly for using Tor / TBB."
>>
>> OK, so instead of everyone shooting down my ideas, modify them so they
>> might work, or come up w/ other better ideas, instead of continuing to put
>> band aids on the current technology that seems to be fraught w/ problems.
>>
>> ______________________________**_________________
>> tor-talk mailing list
>> tor-talk at lists.torproject.org
>> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk<https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>
>>
> _______________________________________________
> tor-talk mailing list
> tor-talk at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
More information about the tor-talk
mailing list