- tor-dev - lists.torproject.org

Re: [tor-dev] Advice regarding Cloudflare
by Ryan Carboni 03 Apr '16

03 Apr '16

> > (as opposed to the people that seem to think that Exits > should actively combat abuse by having the capability for censorship). > > Well, a large number of exit nodes already have the capability for a man-in-the-middle attack. This capability could very well be a default option. b) In your magic world, how would accessing any site that uses > multiple hosts for content to work? > > Yes, yes. It is you who is being imposed upon, not Cloudflare, not the businesses that serve content. In my magic world, people produce things for free! This might seem patronizing, but you seem genuinely ignorant. Cloudflare runs a business. They also get paid for it. That business is to protect email addresses from scrapes, and so forth. If they tell their customers that malicious actors can do those things, but only through Tor, because Tor does good work, their customers will take their business elsewhere. In a libertarian world, people can bar entry to their property from people who seem suspicious. You do not believe that Cloudflare should be allowed to bar entry out of some egocentric concern. By any reasonable definition of ethics, one must find a middle ground, and essentially, Cloudflare has all the negotiating power, unless you plan on personally battering down the doors of Cloudflare. A good step would be to ask Cloudflare for statistics on Tor misuse. Perhaps a maximum of 63 domain names (forgot Cloudflare only has a dozen IPs) per Tor circuit could be done.

3 2

Advice regarding Cloudflare
by Ryan Carboni 03 Apr '16

03 Apr '16

I could see why cloudflare is annoyed with you, you are annoying activists from their perspective, although you folks aren't chaining yourselves to coal power plants . But I also use Tor from time to time, so I'll offer some advice. On the Tor side, a way to minimize abuse is for exit nodes not to allow multiple IP addresses from a single circuit. This would make web crawling with Tor expensive, although it will disable the ability for a single tab to use a single exit node. Another method is to request a sort of proof of work on the Cloudflare side. Given current protocols, the simplest would be to require ECDHE with secp521r1 with each Tor connection and disallow unencrypted connections. It will be more bearable than a captcha.

2 1

Re: [tor-dev] Quantum-safe Hybrid handshake for Tor
by Ryan Carboni 03 Apr '16

03 Apr '16

I just want to note you only need an algorithm that protects against 2^80 quantum operations for short-term keys. Regardless, I doubt anyone is going to be spending a billion dollars to crack data sent over a single Tor connection.

1 0

(no subject)
by Nick Mathewson 28 Mar '16

28 Mar '16

Hi, folks! The Tor git master branch is now 0.2.9.0-alpha-dev. Development on 0.2.8.x continues in the branch "maint-0.2.8". I expect that 0.2.8.2-alpha will be the last 0.2.8.x-alpha, and then we can move on to rc and stable. We now return you to your semiregularly semischeduled Tor development. yrs, -- Nick

1 0

Re: [tor-dev] Should we disable the collection of some stats published in extra-infos?
by Karsten Loesing 28 Mar '16

28 Mar '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/01/16 23:00, Rob Jansen wrote: > Hello, Hi Rob, I'm moving this discussion from metrics-team@ to tor-dev@, because I think it's relevant for little-t-tor devs who are not subscribed to metrics-team@. Hope you don't mind. > I was recently reviewing the statistics that Tor allows relays to > collect and report to the dir servers [1], which then get published > in extra-info documents [2]. Most of this can be enabled by simply > setting a torrc option. There are quite a few statistics that I > feel should not be collected. I'm wondering if the original purpose > for collecting many of these statistics still exists, and if we > still feel that the privacy compromises that were made when the > collection was implemented are still valid in most cases. > > Here are the stats I am most worried about, and why: > > [unique ips per country code] *-ips (there are many of these, e.g. > "entry-ips") Usually this involves storing individual user IP > addresses in memory (in order to track uniqueness) over some period > of time (usually 24 hours), sometimes for longer than the user > would have otherwise been known to Tor (if a user's session is 1 > hour, Tor could remember the IP for at most 23 additional hours). > This is reported, e.g., per entry; there are many cases in the data > where it is very likely that only one user is connecting to a guard > from a given country (because it is rounded up to 8). Users in > small countries have the greatest risk (intersection attacks become > really easy). I agree that might just lose these statistics. We used them in the past as first approximation to counting users, but obviously that only works as long as clients only connect to a single relay. The only place where we're still using them is in a workaround for estimating bridge users. See #15469 for more details and #8786 for something we'd have to implement before taking these statistics out. > [exit statistics by port number] exit-kibibytes-written > exit-kibibytes-read exit-streams-opened Tor is classifying its > traffic into ports, which could uniquely identify the application > being used by the client. They also track bandwidth usage per port > (and per exit); again, this is bad for those using a random or > unique looking ports (that a given exit does not see very often) > because it could be used to create a fingerprint. Intersection > attacks become easier with this information. Agreed, I can see us dropping these statistics, too. We're currently not using them. But also see my suggestion below. > The less problematic stats: > > [circuit-based cell statistics] cell-processed-cells > cell-queued-cells cell-time-in-queue cell-circuits-per-decile This > provides queue timings and number of cells being processed at a > relay. The number of cells can be used to compute bandwidth of > circuits. It may be possible to launch some attacks that create > several circuits with the intent of moving which decile buckets > some legitimate circuits get placed into, but this is less > worrisome of an attack than the others. I'm less worried about this one. But, suggestion below. > Should Tor still be collecting these things? Should Tor disable the > collection of these statistics until we have a more > privacy-preserving way to collect and aggregate them? > > The good news is that privacy-preserving techniques exist that can > reduce information leakage. I'm developing a tool based on the > secret-sharing variant of PrivEx [3] to collect some of these types > of statistics while providing privacy guarantees. We are currently > using it to collect only those stats that are useful for producing > Tor traffic models. A great advantage of this tool is that the > various counters that we store during the collection phase get > noise added and are randomized during initialization; only the > aggregates are ever known and revealed by the aggregation server, > limiting the information that is lost if a relay is compromised. > This is a large improvement over the current collection method, > which only adds noise before publication and reveals statistics on > a per-relay basis. Suggestion: How about we evaluate these statistics published by relays in the past years to see if there are other benefits or risks we didn't think of, and then we decide whether to leave them in, modify them, or take them out? The reason is that I'd want to avoid removing this code only to realize shortly after that we overlooked a good reason for keeping it. These statistics are being collected for years now, and it might take another year or so for relays to upgrade to stop collecting them. So what's another month. Thanks for (re-)starting this discussion! > All the best, Rob All the best, Karsten > [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt [2] > https://collector.torproject.org/recent/relay-descriptors/extra-infos/ > > [3] www.cypherpunks.ca/~iang/pubs/privex-ccs14.pdf > > > > _______________________________________________ metrics-team > mailing list metrics-team(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team > -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWnffFAAoJEJD5dJfVqbCrSREH/1G3nZDwC7a8FGFEySgQX3MZ n1dlMcylDU6kypgGMEYs2KmMRwhNYmCVFn6fRJgrFN/KgJ0oZJG1pRcglnIFwNwH 5VUWDZp3+frhY5jBbJ3JXqA4Exhi/0mUYCTRwfcFQ/JOyzjlcFbLRW/rkqFHn62H wLidaVeagiJ+TI/T8zgwtqQjTDSZrZPpmlxvlO57D1bGhW1ZPJVbOeUzuudhNpRS WVu//MH51juCzcML32MeiMV6wWYYOm1irKZ8lZHVCPbsL98qoh3ewtO6fb62THIa sWcQZlwMQdcC0+509PmMeYwkRn+40MUwkk84/glyP57dfpgtOwzZCohL3yQRQ1s= =F6F+ -----END PGP SIGNATURE-----

2 4

guide to start developing tor
by RAJAT MODI 28 Mar '16

28 Mar '16

hi i am new to tor and want to contribute to tis development .i have already browsed the volunterr page on your website .However i am unable to decide from where should i start ,Kindly guide me for the same . -- RAJAT MODI

1 0

Remember: Network Team/tor core dev meeting Monday at new time!
by Nick Mathewson 28 Mar '16

28 Mar '16

Hello! Tomorrow on Monday, we will be having our meeting on the new time: 1700 UTC (1pm eastern, 10am Pacific). The patch party will be Tuesday at 2300 UTC. If you like hacking Tor, set an alarm and stop on by! Peace, -- Nick

1 0

Sibyls: introducing AS-level sign-up rate limits, per relay caps, family-level caps
by nusenu 27 Mar '16

27 Mar '16

Hi, there is a strict limit on the number of relays that one can run on a single IP address to make Sybil attacks harder, but there are no limits on sign-up rates. Such sign-up rate limits would prevent many of the known and simple Sibyls of the past months and probably reduce the manual actions required by dir auth ops to mitigate them (but I've little inside on that part). In the past 8 months the proposed AS sign-up rate limit thresholds (see below) triggered on ~27 events [some-examples]. I consider all of them to be true-positives, but 15 (vs total: >750) likely unrelated relays signed up on the same ASes during these events. AS-level sign-up rate limit thresholds --------------------------------------- max new relays per 24 hours per AS per OS family: 9 (default); value for OVH/ONLINE/Digital Ocean ASes: 14 I deduced to these threshold values by watching the past 8 months of OrNetRadar emails while keeping false-positives at a minimum (at the price of more false-negatives). How does a well behaving operator (aka Brian) add more than 9 relays per AS per day? All relays in an effective family should be treated as "1 new relay". (In my opinion a reason to keep the family [0] functionality and implement prop242). denial of service risk To prevent trivial dos attacks where an attacker with a single IP generates several new relay fingerprints until the entire AS is blocked from adding new relays for a few hours these relays should come from distinct IP addresses. Pros: + automatically enforced + less manual action required by dir auth ops (maybe some dir auths can commend on that.) + address more (and smaller) Sibyls (I assume that many small Sibyls are currently ignored due to risk/effort trade-offs) Cons: - maxmind AS-IP mapping db becomes crucial and needs to be in sync across dir auths - false-positives - non-dir auths will not notice if an AS run into this limit unless they publish some kind of transparency reports - dir auths must keep more state (not sure if they know all existing FPs of the past already) Feasibility Initially the idea was to provide immediate feedback to the relay that tries to publish its descriptor to the dir auth via the HTTP response (an important point), but since descriptors are not uploaded to a single central dir auth that does not work I guess. So before thinking on how one would actually achieve that or something similar I wanted to gather the general opinion about something like this. single relay caps ------------------ 250000 consensus weight (to prevent [1]) family-level caps ------------------ max cw fraction: 2.5% [2] max. exit probability: 10% [3] guard probability: 5% [4] AS-level caps: --------------- max cw fraction/guard/exit probability: 15% [5] AS12876 (ONLINE SAS) and AS16276 (OVH) are already past that value, so if you do not want to change the game for them you would have to set it to ~20%. [0] https://trac.torproject.org/projects/tor/ticket/6676 [1] https://lists.torproject.org/pipermail/tor-talk/2015-December/039696.html https://trac.torproject.org/projects/tor/ticket/17810#comment:8 [2] https://raw.githubusercontent.com/ornetstats/stats/master/o/main_operators_… [3] https://raw.githubusercontent.com/ornetstats/stats/master/o/main_exit_opera… [4] https://raw.githubusercontent.com/ornetstats/stats/master/o/main_guard_oper… [5] https://compass.torproject.org [some-examples] http://article.gmane.org/gmane.network.onion-routing.ornetradar/1135 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1132 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1100 http://article.gmane.org/gmane.network.onion-routing.ornetradar/1030 http://article.gmane.org/gmane.network.onion-routing.ornetradar/939 http://article.gmane.org/gmane.network.onion-routing.ornetradar/943 http://article.gmane.org/gmane.network.onion-routing.ornetradar/898 http://article.gmane.org/gmane.network.onion-routing.ornetradar/856 http://article.gmane.org/gmane.network.onion-routing.ornetradar/813

1 1

[GSoC 2016] Roster - Gamification for Tor Operators (Sean Saito)
by Sean Saito 26 Mar '16

26 Mar '16

Hi! I have finished and submitted my final proposal for GSoC yesterday. This summer I would like to complete Roster, a Tor Project initiative I’ve been working on since last year. It is basically a social incentivization scheme to gamify operating a Tor relay. All the details are included in the Google doc, and, while the deadline for edits has passed, I would appreciate any comments and feedback. https://docs.google.com/document/d/1wOBUhOPAAWTLfQIt4ChKixLMgIrZlO3YBQ-eixh… Thanks a lot! Best, Sean

1 0

Tor 0.2.8 and Fallback Directory Mirrors
by Tim Wilson-Brown - teor 26 Mar '16

26 Mar '16

Dear Tor App Developers, Just a heads' up that tor 0.2.8 includes a fallback directory mirrors feature, where tor clients bootstrap from a set of hard-coded long-lived directory mirrors. This makes bootstrap more reliable, and makes it harder to block tor. The wiki has an entry with more details. [0] We're currently trying to finalise a list of around 100 fallback directory mirrors by the time tor 0.2.8-stable is released. [1] If we have this many mirrors, I am confident we won't overwhelm any of the mirrors when an app like Orbot, Tor Browser, or Tails switches to tor 0.2.8. (Are there any other tor apps with millions of users that I've missed?) If this feature does cause problems, or if your app needs to bootstrap only from the authorities (Tails time syncing? [2]), the fallback directory mirrors feature can be disabled using the tor config option "UseDefaultFallbackDirs 0". Tim [0]: https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors <https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors> [1]: https://trac.torproject.org/projects/tor/ticket/17158 <https://trac.torproject.org/projects/tor/ticket/17158> [2]: https://tails.boum.org/contribute/design/Time_syncing/ <https://tails.boum.org/contribute/design/Time_syncing/> Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

2 2