[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] "Trawling for Tor Hidden Services: Detection, [...]"
Hi,
> As for the deanonymization attack, I think it is pretty novel in that it
> uses a custom traffic signature to make the attack from
> http://freehaven.net/anonbib/cache/hs-attack06.pdf more reliable, but
> otherwise that is why we introduced guard nodes.
I'm still pretty sure this only makes people more secure in theory;
the basis appears to be that instead of connecting to a random node
every time a circuit is built, you instead connect to only one
entry/guard node for 30-60 days. I think on paper that reduces the
probability, but it seems to presume an attacker that doesn't modify
their attack and doesn't appear to account for a keyspace of sorts
that has reduced by over 50% and the introduction of a "touch me here"
flag that says you're not only a relay, but you're guaranteed to be an
entry point relay.
Looking at the numbers from a snapshot a few days ago: 839 exits, 865
guards, 1676 generic relays.
Previously for entry you'd be looking at a 'keyspace' of
n/(839+865+1676), with the obvious problem that connecting to them at
random every time you create a circuit is going to increase the
probability that you hop through a compromised node. However, you need
a fairly large value of N to make that realistic, I think the number
cited was approaching 50%, but I could be remembering that
incorrectly.
Now, you're at 865 _guaranteed_ entry points, which automatically
reduces the required value for N and increases the value of each rogue
node that gains the guard flag, which appears to be strictly based on
bandwidth and stability. I'm hardly an expert on math or probability,
but it seems like the 'weight' so to speak of a compromised node was
never increased to account for the reduced number of nodes or
guarantee that being a guard will always yield entry point traffic,
which is to say that N is actually going to be some value multiplied
by N instead of just N/C^2, (N*nWeight/C or possibly even
N^nWeight/C). It at least seems like the probabilities were only
worked for the state the network was in, and not for the
state/behavior of the network after the modifications. So now you have
a network where one can setup two boxes that are fast and stable and
be guaranteed to receive exit and entry traffic and only needing about
half as many boxes to reach the same 50% mark as before.
The math behind this concept is not overly compelling or I'm just
dumb, both are probable and neither are mutually exclusive, but if I
were looking for a state-based backdoor, I'd imagine it to look a bit
like this (which is not to imply that is the case here by any means).
Jon
On Thu, May 23, 2013 at 11:35 PM, <tor-dev-request@xxxxxxxxxxxxxxxxxxxx> wrote:
> Send tor-dev mailing list submissions to
> tor-dev@xxxxxxxxxxxxxxxxxxxx
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> or, via email, send a message with subject or body 'help' to
> tor-dev-request@xxxxxxxxxxxxxxxxxxxx
>
> You can reach the person managing the list at
> tor-dev-owner@xxxxxxxxxxxxxxxxxxxx
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of tor-dev digest..."
>
>
> Today's Topics:
>
> 1. Hidden services performance (Petter Solberg)
> 2. Re: Hidden services performance (Jeroen Massar)
> 3. Chrome browser and sand boxing. (Andrew F)
> 4. Re: Chrome browser and sand boxing. (Andrew Lewman)
> 5. Re: Chrome browser and sand boxing. (Andrew F)
> 6. "Trawling for Tor Hidden Services: Detection, Measurement,
> Deanonymization" (Tom Ritter)
> 7. Re: "Trawling for Tor Hidden Services: Detection,
> Measurement, Deanonymization" (Mike Perry)
> 8. Re: "Trawling for Tor Hidden Services: Detection,
> Measurement, Deanonymization" (Nick Mathewson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 23 May 2013 14:46:12 +0200
> From: Petter Solberg <pettersolberg88@xxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: [tor-dev] Hidden services performance
> Message-ID:
> <CAPnamRP==01+HkQQWbg_mQv0uF=f3hK02jvffXDJBW8UfyMueQ@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi.
>
> We are two master thesis students at the Norwegian University of Science
> and Technology (NTNU) which is looking into the performance of hidden
> services. We have already set up 19 physical Linux servers connected by
> gigabit Ethernet to be able to benchmark hidden services in a private tor
> network. We have also some public servers that we plan to utilize (
> https://atlas.torproject.org/#search/disasterTor ). This mail is to inform
> you of our work and a request for ideas in where some bottlenecks are and
> if someone have done some previous research before.
>
> Without any modifications to Tor we have been able to have a throughput of
> 180Mb/s through a single hidden service.
>
>
> If you have some Ideas or a comment. Please reply.
>
>
>
> Regards
>
> Petter Solberg (pettso AT stud.ntnu.no ) & Bram Bezem ( bezem AT
> stud.ntnu.mo )
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130523/8b9b0139/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 23 May 2013 14:53:14 +0200
> From: Jeroen Massar <jeroen@xxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-dev] Hidden services performance
> Message-ID: <519E113A.3010200@xxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On 2013-05-23 14:46 , Petter Solberg wrote:
>> Hi.
>>
>> We are two master thesis students at the Norwegian University of Science
>> and Technology (NTNU) which is looking into the performance of hidden
>> services. We have already set up 19 physical Linux servers connected by
>> gigabit Ethernet to be able to benchmark hidden services in a private
>> tor network. We have also some public servers that we plan
>> to utilize ( https://atlas.torproject.org/#search/disasterTor ). This
>> mail is to inform you of our work and a request for ideas in where some
>> bottlenecks are and if someone have done some previous research before.
>>
>> Without any modifications to Tor we have been able to have a throughput
>> of 180Mb/s through a single hidden service.
>>
>>
>> If you have some Ideas or a comment. Please reply.
>
> Describing your test scenario would be a good start.
>
> You give a number above, but where that number comes from is totally
> unspecified. As your 'throughput' (of what? HTTP, SFTP?) is quite high,
> I'll assume you have done the above with the "19 servers" you mention
> above and that you just tested this in a local network and not the tor
> network itself.
>
> But that is an assumption, as you are not specifying which version(s) of
> Tor where used or even the kernel version or distribution release
> details, nor how these hosts where connected (all on the same switch?
> what kind of switch? what IP protocols where used, IPv4/IPv6?)
>
> There are lots of papers on the performance of Tor, though most do not
> specifically target Hidden services, the network itself tends to be the
> bottleneck.
>
> You might want to check out http://freehaven.net/anonbib/ if you did not
> so yet as that contains a large list of papers concerning Tor performance.
>
> "Performance" can mean a lot of things though, throughput and latency
> tend to be the more important factors.
>
> Greets,
> Jeroen
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 23 May 2013 15:35:28 +0000
> From: Andrew F <andrewfriedman101@xxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: [tor-dev] Chrome browser and sand boxing.
> Message-ID:
> <CAMnnSdgy5s55D-pq2mSNWFE-qSgef7W9Zzs16WEqnDSNga-Ucg@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I have Googled and searched the Tor website, but I have not found any
> information on chrome's sandbox feature and Tor. Specifically with flash.
> Is there any information out their on this?
>
> Thanks
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130523/4950ffc6/attachment-0001.html>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 23 May 2013 13:00:00 -0400
> From: Andrew Lewman <andrew@xxxxxxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-dev] Chrome browser and sand boxing.
> Message-ID: <20130523130000.47e35c62@kilik>
> Content-Type: text/plain; charset=US-ASCII
>
> On Thu, 23 May 2013 15:35:28 +0000
> Andrew F <andrewfriedman101@xxxxxxxxx> wrote:
>
>> I have Googled and searched the Tor website, but I have not found any
>> information on chrome's sandbox feature and Tor. Specifically with
>> flash. Is there any information out their on this?
>
> https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs
> that's all we've looked at so far.
>
> --
> Andrew
> http://tpo.is/contact
> pgp 0x6B4D6475
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 23 May 2013 17:55:20 +0000
> From: Andrew F <andrewfriedman101@xxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-dev] Chrome browser and sand boxing.
> Message-ID:
> <CAMnnSdigOAPTH0E163pZNc6Hhej1KoHy8AMCBW9tJg_PRFfr6Q@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks.
>
>
>
> On Thu, May 23, 2013 at 5:00 PM, Andrew Lewman <andrew@xxxxxxxxxxxxx> wrote:
>
>> On Thu, 23 May 2013 15:35:28 +0000
>> Andrew F <andrewfriedman101@xxxxxxxxx> wrote:
>>
>> > I have Googled and searched the Tor website, but I have not found any
>> > information on chrome's sandbox feature and Tor. Specifically with
>> > flash. Is there any information out their on this?
>>
>> https://trac.torproject.org/projects/tor/wiki/doc/ImportantGoogleChromeBugs
>> that's all we've looked at so far.
>>
>> --
>> Andrew
>> http://tpo.is/contact
>> pgp 0x6B4D6475
>> _______________________________________________
>> tor-dev mailing list
>> tor-dev@xxxxxxxxxxxxxxxxxxxx
>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130523/833faa89/attachment-0001.html>
>
> ------------------------------
>
> Message: 6
> Date: Thu, 23 May 2013 22:18:43 -0400
> From: Tom Ritter <tom@xxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: [tor-dev] "Trawling for Tor Hidden Services: Detection,
> Measurement, Deanonymization"
> Message-ID:
> <CA+cU71=nBM8v+jFpmYuL6B9j7Vrb8KXrbiOp_k55HgdL+s-F5Q@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1
>
> RPW's, et al's paper was made public today, and demonstrates several
> practical attacks on Hidden Services.
> http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf
>
> I was wondering if there were any private trac tickets, discussions,
> or development plans about this that might be also be made public.
>
> -tom
>
>
> ------------------------------
>
> Message: 7
> Date: Thu, 23 May 2013 20:26:28 -0700
> From: Mike Perry <mikeperry@xxxxxxxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-dev] "Trawling for Tor Hidden Services: Detection,
> Measurement, Deanonymization"
> Message-ID: <20130524032628.GA30637@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset="us-ascii"
>
> Tom Ritter:
>
>> RPW's, et al's paper was made public today, and demonstrates several
>> practical attacks on Hidden Services.
>> http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf
>
> Sweet. I was waiting for a public version of this to appear. It was
> shared with a few Tor people, but as I don't work on hidden
> service-related things, I had not seen it yet.
>
>> I was wondering if there were any private trac tickets, discussions,
>> or development plans about this that might be also be made public.
>
> There have been a few discussions on this list about making hidden
> service descriptors harder to harvest. Sysrqb pointed out that a lot of
> the ideas are captured here:
> https://trac.torproject.org/projects/tor/ticket/8106
>
>
> As for the deanonymization attack, I think it is pretty novel in that it
> uses a custom traffic signature to make the attack from
> http://freehaven.net/anonbib/cache/hs-attack06.pdf more reliable, but
> otherwise that is why we introduced guard nodes.
>
> One immediate thought: what about changing hidden services to maintain a
> small pool of service-side rend circuits were reused for as long as
> possible (perhaps until they simply failed)? This would give a similar
> effect to multiple layers of guard nodes, but without adding all of that
> complexity or extra hops.
>
> We would have to create some logic that prevented DESTROY cells from
> being allowed to travel across all 6 hops in that case, though, but
> there are actually multiple reasons to make that change.
>
> In general, a client shouldn't be allowed to manipulate a service's
> circuits' lifetimes as a general matter, nor should a service be able to
> manipulate a client's circuits' lifetimes.
>
> In fact, this ability for remote manipulation of the other party's
> circuits caused me to decide that the Path Bias detection code should
> not perform accounting on these circuits, because a malicious
> counterparty could use that ability to cause you to erroneously lose
> faith in your Guard nodes.
>
> Unfortunately this also means that if a path bias/route capture
> adversary can differentiate these circuit types, they could fail the
> ones we can't do accounting on at will.
>
> So there's now more than one reason to change that DESTROY behavior at
> the very least, I think.
>
>
> --
> Mike Perry
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 198 bytes
> Desc: Digital signature
> URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130523/de67d859/attachment-0001.pgp>
>
> ------------------------------
>
> Message: 8
> Date: Thu, 23 May 2013 23:35:31 -0400
> From: Nick Mathewson <nickm@xxxxxxxxxxxx>
> To: tor-dev@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [tor-dev] "Trawling for Tor Hidden Services: Detection,
> Measurement, Deanonymization"
> Message-ID:
> <CAKDKvuwHhfTBwHoSbuCtcqTJuWb=RzOEZqAdXGUmF_BGKFTd8w@xxxxxxxxxxxxxx>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, May 23, 2013 at 10:18 PM, Tom Ritter <tom@xxxxxxxxx> wrote:
>> RPW's, et al's paper was made public today, and demonstrates several
>> practical attacks on Hidden Services.
>> http://www.ieee-security.org/TC/SP2013/papers/4977a080.pdf
>>
>> I was wondering if there were any private trac tickets, discussions,
>> or development plans about this that might be also be made public.
>
> Most (all AFAIK) of what we have to do about this is public already.
> For stuff that's already done, see tickets #8146 and #8147 and #2286
> and #8273 and #8435 for stuff that's already implemented at the
> directory authority level to make cheap HS-targeting attacks harder,
> and #8207 for fixing a bug in hidden service user authentication
> (which is a pretty good countermeasure if you want to avoid
> enumeration). See #8240 for making Guard node lifetime configurable,
> and raising the default.
>
> For stuff we'd still like to do, have a look at #8106 for a good
> crypto idea from rransom that would form the basis of a way to make
> service enumeration impossible, and some discussion with
> hyperelliptic. See #8244 for some anti-censorship ideas from arma. See
> #6418 for an important last step.
>
> (These numbered tickets are all at trac.torproject.org. For example,
> #8106 is https://trac.torproject.org/projects/tor/ticket/8106 and
> #8244 is https://trac.torproject.org/projects/tor/ticket/8244 .
>
> All of the current tickets tagged with "tor-hs" are:
> https://trac.torproject.org/projects/tor/query?status=accepted&status=assigned&status=needs_information&status=needs_review&status=needs_revision&status=new&status=reopened&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&keywords=~tor-hs
>
> Sorry about the enormous URL.
>
> George had a good blog post summarizing security issues and related
> issues with hidden services at, which should have some good opsec
> suggestions: https://blog.torproject.org/blog/hidden-services-need-some-love
> . This week, he started some discussions about migrating to future
> hidden service protocols on tor-dev too.
>
> And that's what we've got now. George and Roger will probably have
> more thoughts; this is just me trying to do a braindump.
>
>
> hth,
> --
> Nick
>
>
> ------------------------------
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
> End of tor-dev Digest, Vol 28, Issue 39
> ***************************************
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev