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

[Xinwen Fu <xinwenfu@xxxxxxxxx>]

On Sun, Feb 26, 2012 at 8:36 PM, Chris Wheeler <grintor@xxxxxxxxx> wrote:

> I imagine that you would only need to reorder packets end-to-end since
> those are the points on the network where
> a correlation attack compromises identity. If the packets being sent from a
> public web server on the internet travel through the tor network in
> a different order than they were seen entering the exit node by the
> attacker, then they shouldn't be able to use statistical analyses to find
> out where the packets went; even if they had a view of the whole network.
>  When those packets arrive at the client side (right before they leave the
> SOCKS5 server running on the client) they would be re-arranged back into
> the order they entered the exit server; this way it would be transparent to
> the application using the SOCKS server - such as a web browser. This
> would definitively increase overhead, but mostly processor overhead (to
> rearrange each packet), not too much bandwidth overhead which is
> more precious. Since the only servers rearranging packets at all would the
> ends, non-exit relays would not experience any processor overhead.
>  The total bandwidth overhead would be from having to now deliver two TCP
> headers, one from the large TCP packet that is traveling across the
> internet carrying the smaller, out-of-order packet which has the real data,
> and the other from that smaller TCP packet that is embedded in the data
> section of the larger TCP packet.
>
>
The problem is what attacks you want to fight against. What is your threat
model? Correlation can be done via different features of a traffic flow.
TCP and Tor protocols try to make the traffic rate stable from the sender
to the receiver. At least, this is the result of these protocols.
Therefore, the rate of a traffic flow into Tor and out of Tor should be
similar, at least more similar to each other than to other traffic flows.
Therefore, traffic rate can be used for correlating flows. Then your
strategy may not work. Many of my papers are on using traffic rate as
features correlating flows. You can refer to them.

Hope it helps a bit.

Xinwen Fu





> I think that could work. What do you think?
>
> On Sun, Feb 26, 2012 at 1:31 PM, Xinwen Fu <xinwenfu@xxxxxxxxx> wrote:
>
> > 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
> >
> _______________________________________________
> 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