Re: [tor-relays] Individual Operator Exit Probability Threshold
> Doesn't a lot of it depend on context anyway? Yes. > How can we quantify something like this? We can't. We don't have all the data. We have to assume the worst and plan accordingly.___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Individual Operator Exit Probability Threshold
dawuud: > >> I think it is worth remembering that there isn't evidence there is a >> global passive adversary at the moment, even if certain agencies and >> organizations clearly aspire to be one. > > Quite so. It is well established that these so called agencies do not > aspire to be passive. Or perhaps you simply typed the word "passive" by > shear force of habit and instead meant to convey "suffiently global > adversary". :) > I was mostly commenting on the use of the word "passive", but I agree with you that "sufficiently global adversary" is perhaps a better word. Doesn't a lot of it depend on context anyway? How can we quantify something like this? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Individual Operator Exit Probability Threshold
Roger, Thank you. Thats the concise answer I was looking for and I will hold at 5% and coordinate from there. I will be in Seattle mid-October, hoping I can connect with folks in Seattle area that do Tor and also visit the office to get some shirts and say hi! Any takers, Seattle Tor people? John On Sep 26, 2017, at 19:31, Roger Dingledine> wrote: On Fri, Sep 22, 2017 at 01:04:28PM +, John Ricketts wrote: I am about to fire up more Exit Relays and if I do so I will jump from my roughly 3% of Exit Probability to what technically could easily reach 6-8%. I would like to know everyone???s opinion on having an individual operator have that much exit share. In my case, all the traffic would be coming from the same AS as well, but distributed over four different cities with different upstream carriers. Hi John, I think 5% exit share is fine, and 10% is probably a bit too high. That means as you grow past 5%, you should work with the other big exit relay operator groups -- torservers, Nos Oignons, DFRI, Fr?mailto:tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Individual Operator Exit Probability Threshold
On Fri, Sep 22, 2017 at 01:04:28PM +, John Ricketts wrote: > I am about to fire up more Exit Relays and if I do so I will jump from my > roughly 3% of Exit Probability to what technically could easily reach 6-8%. > > I would like to know everyone???s opinion on having an individual operator > have that much exit share. In my case, all the traffic would be coming from > the same AS as well, but distributed over four different cities with > different upstream carriers. Hi John, I think 5% exit share is fine, and 10% is probably a bit too high. That means as you grow past 5%, you should work with the other big exit relay operator groups -- torservers, Nos Oignons, DFRI, Frënn vun der Ãnn, Hart Voor Internetvrijheid, NoiseTor, and the many more out there -- to get them to pick up the pace on their side. :) --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Individual Operator Exit Probability Threshold
>> :> what the current value of "global" is but I should hope it's well above >> 5%... >> :I'm curious about what you mean by "global" here, and how it relates to >> :[potentially] malicious operators (suspicious relays of which are >> :frequently thrown off the Tor network). >> >> "global" as in a global passive adversary Global is relative, it can mean at a scale having wide enough coverage physical or logical, to achieve your goals, against from 1 to all users, in sufficient time. It probably doesn't mean 1 node or tap, or quite 10, but up towards 100 / 500 / 1000 becomes interesting to think about. Similarly probably not for $5000, yet $5 to $10M becomes a project. Physical may mean literally distributed about the Earth. Logical may mean piled in one datacenter taking part in the random functions of a target network, such as DHT abuse. >> though I suppose running nodes is an active adversary. Depends on what's being done with those Sybil nodes. Listening, traffic analysis, recording, decryption... that's passive. Modification, inject / drop, perturb, exploit... that's active. There are successful attacks in both modes of operation. > If an adversary is a global passive adversary, surely that would mean > that they are for all intents and purposes seeing pretty much all of the > traffic? > > I think it is worth remembering that there isn't evidence there is a > global passive adversary at the moment, even if certain agencies and > organizations clearly aspire to be one. If anyone seriously thinks that GPA / GAA scale adversaries do not exist, or are not actively in effect and growing with intent, they need to get their head out of their ass and digest the news dating back to at least Snowden. Even simple University level research groups have published effective production low cost small scale Sybil attacks on tor. (Sybil may also include infiltration of global code repositories.) Learn about how internet backbones work, lack of per link level encryption and fill traffic, Tier-1 vantage points, dozens of suspect hops in a traceroute, etc. How entities and people bend over backwards to give data away under the legal or $dollar table with wink and nod. Read up what NSA, GCHQ, FVEY, DEA, et al are doing with $Billions, PATRIOT partnerships, manganese nodules, etc. In a sense, "global" may sometimes distill down to meaning the same "global amounts of money" spread at a problem via various vectors to achieve similar results. Threats involving large scale deployment of $money, nodes, and actors against tor and other networks are real and secretive. Secrecy requires gauging their effectiveness by analysis of leaks, court cases, parallel construction, whispers and canaries, whitepapers, human resources, code and deltas, and news media. The fun part beyond that is in figuring out how to defeat them and then doing exactly that :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] On some differences after upgrade to latest tor for Jessie
I am running jesse, too. Yes, it runs systemd; I find (at least some) tor info in: /var/log/daemon.log Having no experience with tor on an earlier debian, I don't know if that's all there is. HTH, --torix Sent with [ProtonMail](https://protonmail.com) Secure Email. > Original Message > Subject: Re: [tor-relays] On some differences after upgrade to latest tor for > Jessie > Local Time: September 24, 2017 6:12 PM > UTC Time: September 24, 2017 10:12 PM > From: nusenu-li...@riseup.net > To: tor-relays@lists.torproject.org > > a tor op: >> One thing that puzzles me is the log >> /var/log/tor/log >> >> I used to always see some useful info there, like number of connecting >> clients during the last 6 hours etc. > > Tor (from deb.tpo) on Debian logs to syslog (/var/log/syslog) by default > - but check your configuration to verify your configuration. > > -- > https://mastodon.social/@nusenu > https://twitter.com/nusenu_ > > ___ > tor-relays mailing list > tor-relays@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] MaxMemInQueues defends against 375000 circuits in 9 secs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi everybody Another circuit storm, right ? - MaxMemInQueues 2 GB - 2017-09-26_17-55-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 484M 427M uwait 0 907:02 11.77% tor 2017-09-26_18-59-00: PID JID USERNAME THR PRI NICE SIZE RES STATE C TIME CPU COMMAND 84847 2 256 6 20 0 2437M 2380M uwait 0 917:03 18.26% tor - On Tor 0.3.2.1-alpha 290274dbb5428bc5 Sep 26 18:24:37.000 [notice] Heartbeat: Tor's uptime is 4 days 18:59 hours, with 13714 circuits open. I've sent 2459.48 GB and received 2422.58 GB. Sep 26 18:24:37.000 [notice] Circuit handshake stats since last time: 4635/4635 TAP, 113271/113271 NTor. Sep 26 18:24:37.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 3 v3 connections, and 214559 v4 connections; and received 886 v1 connections, 24624 v2 connections, 60722 v3 connections, and 354411 v4 connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 106528 bytes by killing 14408 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. Sep 26 18:59:28.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:28.000 [notice] Removed 528 bytes by killing 7 circuits; 0 circuits remain alive. Also killed 0 non-linked directory connections. ... 2500 x removed some bytes by killing between single and 300 circuits (constantly increasing sawtoothy, average 150 circuits) average 150 circuits x 2500 = 375000 circuits avoided in 9 seconds ... Sep 26 18:59:37.000 [notice] We're low on memory. Killing circuits with over-long queues. (This behavior is controlled by MaxMemInQueues.) Sep 26 18:59:37.000 [notice] Removed 4624 bytes by killing 115 circuits; 0 circuits remain alive. Also killed 1 non-linked directory connections. [] https:// lists.torproject.org/pipermail/tor-relays/2017-July/012624.html - -- Cheers, Felix -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZyqCOAAoJEF1W24InZUQd/eAQAIK7IDNbnR+E1uTpvVwimUCJ jrSPr5sCXu8t4ly0Tci/tg7mCGTd9xKJvJgUHLei7pd6UmdDJvwajrX08tE/iBC/ uJPLEr69OBBqDICf7E+Y4oQGRz4ICY/4IGeb7lU/My6TzT00gHcs0/0tuww1actm P06uobAeRx+56GCg9hGopLavSOIHsR0bFC3k5kqin79qx40XwNuN6xkFCDni/fHW EO9GazD2iE4zJ3+1lIJsIzaA7fgu+Ack2GcLpaPKMNMwX3DagG/A619HsddOoBfH EFV2ZOhnR9XWytgIfPX4e/gErTHvWPshm0qaO4PzxwAlAoSKygvz497O1HZ3AlM+ fcn+C/fkfCcU2PYVPXKV3vDzupiZ17OJGfRNtAy1EqFLCK6q7xQAp1e3JuRJZBDO 3E/18FJM7JXCUz5StxwB+oAu9LGib50vXbtAOtuLwfX4OC3Nl0Fc/gw0ueYwWIPu QvsU0WNelwaUo3wWs47fJsMsJqjpt0Uywh8yvK809xvqogUFiQBF2ynIp5QzfaJ0 or/7axRHXglkxVaF+q84GFG8LAaspurGauQQFtzUdzl/ljWC963PyrGiOr0kCj/R OIc3TDSDYopFTllXeeVu2bysW7PrzL3vu5rcOHbbVAnUoRukA4Hh6qJFQuTk+Ndb tT8G8jk1QJjRqH/IaTLg =r7/i -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Individual Operator Exit Probability Threshold
dawuudwrote: > > > I think it is worth remembering that there isn't evidence there is a > > global passive adversary at the moment, even if certain agencies and > > organizations clearly aspire to be one. > > Quite so. It is well established that these so called agencies do not > aspire to be passive. Or perhaps you simply typed the word "passive" by > shear force of habit and instead meant to convey "suffiently global > adversary". :) Curiouser and curiouser! So, dawuud, you imply that habit has a velocity vector(!) and that it changes over distance(!!) in one or more dimensions, and thus exerts a shear force on...what? A typist's fingers and hand placed within the volume where shear is present? Strong enough, perhaps, to roll them up and maybe even break a wrist? Well, I guess one lives and learns! (Hint: you misplaced a homonym.:) Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at sdf.org *xor* bennett at freeshell.org * ** * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * *-- Gov. John Hancock, New York Journal, 28 January 1790 * ** ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays