Re: [tor-talk] on the topic of tor's weaknesses

[Xinwen Fu <xinwenfu@xxxxxxxxx>]

Sorry, TCP over TCP is believed not a good idea in terms of performance.



On Sun, Feb 26, 2012 at 1:30 PM, Xinwen Fu <xinwenfu@xxxxxxxxx> wrote:

> Hi Chris,
>
> On Sun, Feb 26, 2012 at 12:09 PM, Chris Wheeler <grintor@xxxxxxxxx> wrote:
>
>> Dr Fu,
>>
>> About the paper you sent, particularly the section on the simulation
>> using continuous-time mix, by the looks of it much of your degradation
>> came
>> from packets arriving in the wrong order. I know the TCP doesn't handle
>> this well natively but what if a wrapper was written? The TCP stream would
>> travel inside of our wrapper (which would of course itself would be
>> running
>> on TCP across the internet - It would mean transporting a TCP stream over
>> layer 7 of the OSI model, I think this is how PPTP works) The inner TCP
>> stream would be mixed, and the packets out of order but the tor client,
>> before forwarding them on to their destination (a hidden service or, if we
>> are talking about an exit node, the internet) would rearrange them then
>> send them on.
>>
>>
>
> Are you going to do the reordering link-by-link or end-to-end? TCP over
> TCP is believed a good idea in terms of performance. Also what is the
> benefit for privacy enhancing if the client itself reorders everything
> back? What is the performance overhead?
>
> Tor is, I believe, a result after considering many possible options,
> including mixes. It evolves from mixes. Mixes use buffer and shuffling in
> various ways.
>
>
>
>> Another approach to stop correlation attacks might just be to constantly
>> send packets at set time intervals, regardless of if you have any data
>> to forward. Just pad it with zeros if you have nothing to forward and let
>> it get dropped by the client on the other side of the network and of
>> course
>> send real data when you have something to send. For example have a 5Kb
>> buffer, receive packets and place them in that buffer, send the buffer out
>> once per ms, if the buffer is not full pad it with zeros, if you have more
>> than 5Kb to send cache it for the next ms buffer.
>>
>>
> Traffic padding is also an old topic. Tor has an option of using padding.
> I actually did a lot of study on this. The major trouble is the overhead.
> Another question is how you set the overall rate of the padded traffic? You
> can refer to early papers on padding by my group and Matthew Wright at UT
> Arlington.
>
> Cheers,
>
> Xinwen Fu
>
>
>
>> What do you think?
>> Chris
>>
>> On Sat, Feb 25, 2012 at 9:49 PM, Xinwen Fu <xinwenfu@xxxxxxxxx> wrote:
>>
>> > Here is a paper of mine on TCP Performance in Flow-Based Mix Networks:
>> > http://www.cs.uml.edu/~xinwenfu/paper/MixPerf_Fu.pdf.
>> >
>> > If you are interested in why Tor performance is still not super, you an
>> > refer to http://www.cs.uml.edu/~xinwenfu/paper/IPDPS08_Fu.pdf.
>> >
>> > There are many other brilliant works on the performance problem.
>> >
>> > Cheers,
>> >
>> > Xinwen Fu
>> >
>> >
>> > On Sat, Feb 25, 2012 at 9:31 PM, Xinwen Fu <xinwenfu@xxxxxxxxx> wrote:
>> >
>> > > That is a lot of thinking. Many of the problems have been discussed
>> > > before. If you look at the bibliography on mixes, there are a lot of
>> > > discussions. Here is one of my papers on mixes:
>> > > http://www.cs.uml.edu/~xinwenfu/paper/fu_icdcs05.pdf. An adversary
>> may
>> > > choose different ways for correlation and attacks.
>> > >
>> > > What Tor achieves is phenomenal. It works against many attacks. Tor
>> > > performance has been improving. I'm saying this because a workable
>> system
>> > > is not easy. For example, changing packet orders may not be a good
>> idea.
>> > It
>> > > may not help much on security, but will deteriorate the TCP
>> performance
>> > Tor
>> > > relies on. TCP is very sensitive to packet ordering errors.
>> > >
>> > > Indeed, there are still a lot of things we don't know for sure.
>> However,
>> > > at least Tor is over there and you can test it on the real one or a
>> > private
>> > > Tor.
>> > >
>> > > Cheers,
>> > >
>> > > Xinwen Fu
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Sat, Feb 25, 2012 at 3:49 PM, Joe Btfsplk <joebtfsplk@xxxxxxx>
>> 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/%7Exinwenfu/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@xxxxxxxxxxxxxxxxxxxx
>> > >> 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@xxxxxxxxxxxxxxxxxxxx
>> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>> >
>> _______________________________________________
>> tor-talk mailing list
>> tor-talk@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>>
>
>
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk