[tor-dev] meek works again in 4.5-alpha-3

[David Fifield]

On Sat, Dec 06, 2014 at 02:57:19PM -0800, David Fifield wrote:
> What's a good way to inform support of issues that users might run into?
> Should I just send email to h...@rt.torproject.org, or is there a better
> way?
> 
> I was thinking about this today because meek is broken in the 4.5-alpha
> series, but not in the main 4.0 series. I don't know if anyone told
> support workers about it, even though it might matter to them.
> 
> https://trac.torproject.org/projects/tor/ticket/13788
> https://blog.torproject.org/blog/tor-browser-45-alpha-1-released#comment-79244
> https://blog.torproject.org/blog/tor-browser-45-alpha-2-released#comment-81358

Dear support, the meek pluggable transport works again in 4.5-alpha-3
(and 4.0.3).

David Fifield
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Running doctor's sybil checker over archived consensuses

[grarpamp]

On Mon, Jan 19, 2015 at 11:47 AM, Philipp Winter  wrote:
> On Thu, Jan 15, 2015 at 06:11:25PM -0500, grarpamp wrote:
>> FYI, between here there was thread tor-talk 'many new relays' of possible
>> event around end 2009-06 to begining 2009-07. Along with usual posts
>> of people about potential things to detect.
>
> Interesting, thanks for pointing this out.  This event is visible in
> the diagram but not as a sudden spike but more as a temporary increase
> in the base rate:
> 

Cool, nice to see this graphed, really obvious something happened.

> This event also shows why a simple threshold-based detection mechanism
> is insufficient: Sybils can be added slowly over several hours or days
> in order to stay under the threshold.

Re detection methods, consider some examination of exceeded bounds
within first and second derivatives of various data you are
collection, RRD, etc.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] high latency hidden services

[grarpamp]

On Mon, Jan 19, 2015 at 6:08 PM, Michael Rogers
 wrote:
> Thanks for the explanation.

I think I have more comment address this subsection...

>> If anyone knows of networks (whether active, defunct or
>> discredited) that have used link filling, I'd like a reference.
>> Someone out there has to have at least coded one for fun.

> [list of relevant papers]

Chakravarty et al of Aug 2013 was going to go back (page 13) and
write and test dummy traffic as defense to this passive observation.
Being recent, some followup and sharing there may be oppurtune...
Netflow Traffic Analysis of Anonymity Networks
http://hdl.handle.net/10022/AC:P:21763
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] high latency hidden services

[Michael Rogers]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 08/01/15 06:03, grarpamp wrote:
>> If that's what you're suggesting, then what happens if a client
>> wants to extend a circuit from relay A to relay B, but A and B
>> aren't exchanging chaff with each other?
> 
> This doesn't happen. You have a lower layer of nodes doing fill 
> guided by knowledge of who their own guards are (in this model 
> relays must have notions of their own guards / first hops).
> Circuits are then strung unaffected and unaware over that as usual.
> Relays know the difference between their own action doing p2p for
> fill, and non fill (circuit) data trying to leave them... so they
> can make room in their existing first hop links, or negotiate new
> ones with where that data is trying to go.

Thanks for the explanation.

If relays A and B negotiate a new link between them when a client
wants to extend a circuit from A to B, then A and B must each subtract
some bandwidth from their existing links to allocate to the new link
(since they're already using their full bandwidth allowance, by design).

I suspect the details of how that reallocation is done will be
important for anonymity. If bandwidth is subtracted from existing
links without taking into account how much wheat the existing links
are carrying, then any circuits using those links will feel the
squeeze - the adversary will be able to tell when a relay's opening a
new link by building a circuit through the relay, filling the circuit
with wheat, and waiting for its throughput to get squeezed.

On the other hand, if bandwidth is subtracted from existing links in
such a way that existing wheat is never affected - in other words, if
you only reallocate the spare bandwidth - then it's possible for an
adversary observing a relay to find out how much wheat each link is
carrying by asking the relay to negotiate new links until it says no
because it can't reallocate any more spare bandwidth, at which point
any links that weren't requested by the adversary are now carrying
nothing but wheat.

> If anyone knows of networks (whether active, defunct or
> discredited) that have used link filling, I'd like a reference.
> Someone out there has to have at least coded one for fun.

PipeNet was a proposal for an onion-routing-like network with
constant-rate traffic:
http://cypherpunks.venona.com/date/1998/01/msg00878.html

Tarzan was an onion-routing-like network in which each relay exchanged
constant-rate traffic with a fixed set of other relays called its
mimics, and circuits could only be constructed over links between mimics:
http://pdos.csail.mit.edu/tarzan/docs/tarzan-ccs02.pdf
http://pdos.csail.mit.edu/tarzan/docs/tarzan-thesis.pdf

George Danezis looked at the anonymity properties of paths chosen from
a restricted graph rather than a complete graph (this was in the
context of mix networks, but the findings may also be relevant to
onion routing):
http://www.freehaven.net/anonbib/cache/danezis:pet2003.pdf

Cheers,
Michael
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBCAAGBQJUvY5eAAoJEBEET9GfxSfMRxMH/RbjCt0hVitb8dHcSaKNLzoS
Jz6M9hX71RWO7wDbRpcoKwOKAG9WnlMYbbLrPzRaORrfzetiQRiQ9P4lhZojXXSc
fXr3YmDHxrfDxjGI2pzw+jt9hBH1XKG/CdPZLUmnYTdsdgNa6WJBhz9346QzHOdq
ifPE1IQ9u6ExoRuRYvy9jiEXGnrYa8LC+cD6+dmyMVqBcD6chNFuUY+lqEh7D10m
te2x7wRvV+23wqghM8rKkTy7VKnYGnjDzA5zKIybvMf9TqPGI6t+zRIRsHj8xNnK
RDSV+dGs3AGvz0ysNumlqvdcP3/Nm6PYdMCIGBq8WgqwYSXIrVnToiPRezlPdY0=
=Hzc6
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Consensus weight dropped

[Bram de Boer]

All,

In December consensus weight of many nodes suddenly dropped. Using the
onionoo database I have calculated the average consensus weight during
18-25 october 2014, and the average consensus weight during 11-18 january
2015 of all relays that exist longer than half a year and sorted them by
the amount the consensus weight has dropped:
http://nosur.com/consensus.txt

Almost all of the relays at the top of the list show the same drop in
December and the short spike around januari 6th. The exits I operate used
to contribute around 80 Mbps to the network but are now down to no more
than 0.05 Mbps.

I am aware of the Lizard Squad annoyance around that time, but the
disruption seems to continue for many old relays. Has there been a change
in the consensus calculation that might be causing this?

Thanks,
Bram de Boer


___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Running doctor's sybil checker over archived consensuses

[Philipp Winter]

On Thu, Jan 15, 2015 at 06:11:25PM -0500, grarpamp wrote:
> On Thu, Jan 15, 2015 at 10:25 AM, Philipp Winter  wrote:
> > The median amount of new fingerprints in a consensus is six.  The
> > Here are some preliminary notes about the most significant spikes.  I'll
> 
> > 2008-10-25: Missing consensuses.
> 
> FYI, between here there was thread tor-talk 'many new relays' of possible
> event around end 2009-06 to begining 2009-07. Along with usual posts
> of people about potential things to detect.

Interesting, thanks for pointing this out.  This event is visible in
the diagram but not as a sudden spike but more as a temporary increase
in the base rate:


This event also shows why a simple threshold-based detection mechanism
is insufficient: Sybils can be added slowly over several hours or days
in order to stay under the threshold.

Cheers,
Philipp
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Running doctor's sybil checker over archived consensuses

[Philipp Winter]

On Thu, Jan 15, 2015 at 01:34:01PM -0800, David Fifield wrote:
> Maybe the checker should also check for when a lot of relays go away at
> once. It looks that happened in mid-April, where relays that had been
> started at different times in the beginning of the year all stopped at
> once.
> 
> (Oh, on further reflection, that must have been Heartbleed!)

That's a good idea.  Here's the visualisation:


Some of the spikes represent the same sybils already present in the
previous visualisation.  That makes sense because it's not surprising
that these group disappeared just as quickly as they appeared.

However, there are some additional groups which were not present in the
previous visualisation:

- 2008-05-14: More than 200 relays disappear.  I am not sure why.
- 2008-08-19: More than 150 relays disappear.  Also not sure why.
- 2009-09-24: About 60 relays disappear.  There's a group of 10 relays
  with the same nickname, so this might be a false positive.
- 2012-01-23: About 100 relays disappear.  Not sure why.
- 2012-09-16: More than 150 relays disappear.  Many of them are in the
  same /24 and many have the same nickname pattern.
- 2013-04-11: Same as above.
- 2014-04-17: 247 relays disappear.  These relays were rejected from the
  consensus because of the heartbleed bug.
- 2014-04-18: 906 relays disappear.  These relays were rejected from the
  consensus because of the heartbleed bug.

In the next step, I'll work on a similarity metric to compare and
cluster relay descriptors.  That should help with manual analysis.

Cheers,
Philipp
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev