July 2018 - cypherpunks-legacy

Re: [tor-talk] OneSwarm
by Matej Kovacic 06 Jul '18

06 Jul '18

Hi, sorry for just posting URL. OneSwarm is a P2P file sharing service which uses anonimisation. It is great because: - it promotes anonimisation, - it is open source and multi platform, - it is user friendly, - it is likely it will attract a lot of new users (promotion of anonimisation!) - is is faster than P2P over Tor, which means people will stop using Tor for P2P (and Tor will be more useful for web browsing). bye, Matej _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[Freedombox-discuss] Interesting talks for FreedomBox at DebConf
by Stefano Maffulli 06 Jul '18

06 Jul '18

There are going to be lots of interesting occasions to learn about FreedomBox and start hacking on the system during Debian's DebConf 2011, starting officially on July 24th. We have selected a few talks related directly or indirectly to FreedomBox from the full agenda: * FreedomBox Progress Report: Using Debian to Create and Preserve Freedom, by Bdale Garbee http://penta.debconf.org/dc11_schedule/events/704.en.html * ARM BoF:Porting, news and discussions, by Steve McIntyre http://penta.debconf.org/dc11_schedule/events/795.en.html * Delivering Multi-Platform Applications:Build on Debian, run anywhere, by Bdale Garbee http://penta.debconf.org/dc11_schedule/events/705.en.html * Debian as though cryptographic authentication mattered, by Daniel Kahn Gillmor http://penta.debconf.org/dc11_schedule/events/775.en.html * Bootstrapable Debian: Cyclic dependencies, staged builds and cross-compiling, by Wookey http://penta.debconf.org/dc11_schedule/events/745.en.html * Blending Debian: Debian Pure Blends as a way to structurise the project, by Andreas Tille http://penta.debconf.org/dc11_schedule/events/711.en.html All the talks will be streamed live and there will always be an IRC channel live to ask questions to the speakers. Stay tuned for more details, follow @freedomboxfndn on Identi.ca. http://www.freedomboxfoundation.org/news/FreedomBox_at_DebConf2011/index.en… _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [tor-talk] OneSwarm
by Matej Kovacic 06 Jul '18

06 Jul '18

Hi, sorry for just posting URL. OneSwarm is a P2P file sharing service which uses anonimisation. It is great because: - it promotes anonimisation, - it is open source and multi platform, - it is user friendly, - it is likely it will attract a lot of new users (promotion of anonimisation!) - is is faster than P2P over Tor, which means people will stop using Tor for P2P (and Tor will be more useful for web browsing). bye, Matej _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[extropy-chat] UK police surveillance cameras catch criminals
by BillK 06 Jul '18

06 Jul '18

<http://networks.silicon.com/mobile/0,39024665,39128974,00.htm> English and Welsh police forces are developing a national network of thousands of cameras that will scan number plates and check them against police databases, a move they say will keep criminals off the road. The cameras use automatic number plate recognition technology (ANPR) to check a vehicle's identity against the Police National Computer, records at the DVLA and local intelligence systems. Cars flagged by the system can then be stopped by police and, in a trial of the technology by 23 forces last year, police stopped 180,543 vehicles and made 13,499 arrests, bagging 1,152 stolen vehicles and 13 firearms. <snip> Chief Constable of Hertfordshire Frank Whiteley said: "The launch of the ANPR strategy for the police service is a key step in grasping the opportunities ANPR provides for denying criminals use of the roads." ------------ This sounds as though they have at last started using surveillance cameras pro-actively to stop crime. The police also respond to city centre crimes that are spotted on camera, like fights and personal attacks. - There are a lot of them when the bars close on Saturday night. :) Criminals often steal cars to use in crime, so stopping cars that have been reported stolen should catch a lot. One problem in UK is the large number of unregistered cars (to avoid taxes and insurance, etc.) so they are working harder to get rid of them. Unregistered parked cars that traffic wardens notice are now towed away. I suspect that initially a lot of the police stops on this new system will be unregistered cars not known on their database. So they will just impound the car and charge the driver with minor offences. But even this is a big improvement - as anyone who has been crashed into by an unregistered car and had to pay for all the repairs themselves will agree. BillK _______________________________________________ extropy-chat mailing list extropy-chat(a)lists.extropy.org http://lists.extropy.org/mailman/listinfo/extropy-chat ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Tor 0.1.1.18-rc is out
by Roger Dingledine 06 Jul '18

06 Jul '18

This is the fourth release candidate for the 0.1.1.x series. Please let us know if you find bugs, because I expect only one more release candidate before the real thing. It adds a fifth authoritative directory server, and fixes a lot of bugs in threshold decisions around directories. http://tor.eff.org/download.html Changes in version 0.1.1.18-rc - 2006-04-10 o Major fixes: - Work harder to download live network-statuses from all the directory authorities we know about. Improve the threshold decision logic so we're more robust to edge cases. - When fetching rendezvous descriptors, we were willing to ask v2 authorities too, which would always return 404. o Minor fixes: - Stop listing down or invalid nodes in the v1 directory. This will reduce its bulk by about 1/3, and reduce load on directory mirrors. - When deciding whether a router is Fast or Guard-worthy, consider his advertised BandwidthRate and not just the BandwidthCapacity. - No longer ship INSTALL and README files -- they are useless now. - Force rpmbuild to behave and honor target_cpu. - Avoid warnings about machine/limits.h on Debian GNU/kFreeBSD. - Start to include translated versions of the tor-doc-*.html files, along with the screenshots. Still needs more work. - Start sending back 512 and 451 errors if mapaddress fails, rather than not sending anything back at all. - When we fail to bind or listen on an incoming or outgoing socket, we should close it before failing. otherwise we just leak it. (thanks to weasel for finding.) - Allow "getinfo dir/status/foo" to work, as long as your DirPort is enabled. (This is a hack, and will be fixed in 0.1.2.x.) - Make NoPublish (even though deprecated) work again. - Fix a minor security flaw where a versioning auth dirserver could list a recommended version many times in a row to make clients more convinced that it's recommended. - Fix crash bug if there are two unregistered servers running with the same nickname, one of them is down, and you ask for them by nickname in your EntryNodes or ExitNodes. Also, try to pick the one that's running rather than an arbitrary one. - Fix an infinite loop we could hit if we go offline for too long. - Complain when we hit WSAENOBUFS on recv() or write() too. Perhaps this will help us hunt the bug. - If you're not a versioning dirserver, don't put the string "client-versions \nserver-versions \n" in your network-status. - Lower the minimum required number of file descriptors to 1000, so we can have some overhead for Valgrind on Linux, where the default ulimit -n is 1024. o New features: - Add tor.dizum.com as the fifth authoritative directory server. - Add a new config option FetchUselessDescriptors, off by default, for when you plan to run "exitlist" on your client and you want to know about even the non-running descriptors. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[Freedombox-discuss] Interesting talks for FreedomBox at DebConf
by Stefano Maffulli 06 Jul '18

06 Jul '18

There are going to be lots of interesting occasions to learn about FreedomBox and start hacking on the system during Debian's DebConf 2011, starting officially on July 24th. We have selected a few talks related directly or indirectly to FreedomBox from the full agenda: * FreedomBox Progress Report: Using Debian to Create and Preserve Freedom, by Bdale Garbee http://penta.debconf.org/dc11_schedule/events/704.en.html * ARM BoF:Porting, news and discussions, by Steve McIntyre http://penta.debconf.org/dc11_schedule/events/795.en.html * Delivering Multi-Platform Applications:Build on Debian, run anywhere, by Bdale Garbee http://penta.debconf.org/dc11_schedule/events/705.en.html * Debian as though cryptographic authentication mattered, by Daniel Kahn Gillmor http://penta.debconf.org/dc11_schedule/events/775.en.html * Bootstrapable Debian: Cyclic dependencies, staged builds and cross-compiling, by Wookey http://penta.debconf.org/dc11_schedule/events/745.en.html * Blending Debian: Debian Pure Blends as a way to structurise the project, by Andreas Tille http://penta.debconf.org/dc11_schedule/events/711.en.html All the talks will be streamed live and there will always be an IRC channel live to ask questions to the speakers. Stay tuned for more details, follow @freedomboxfndn on Identi.ca. http://www.freedomboxfoundation.org/news/FreedomBox_at_DebConf2011/index.en… _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Interoperating with p2p traffic
by Brian C 06 Jul '18

06 Jul '18

Hi, Matt Thorne wrote: >That isn't a bad Idea, and possibly something that They (with help >ofcourse :-) could build into their P2P software. Probably not a bad >thing for them to lookinto just for their own use, not because We ask >them to, but becuase that would really mess with the heads of the people >at (Insert 4 letter accronym here). > >question: > >how do the people who feel posesive towards tor think about this idea? > >-=Matt=- > >On 10/12/05, *Arrakistor* wrote > What if we designated some type of tor family specifically for p2p > content, and coordinated with the software developers? > If an anonymizing service based on Tor were integrated into some p2p project or if a fork of Tor were to devote itself to serving p2p, then that should only be encouraged by the current Tor community if 1. It didn't take away any current tor servers or tor resources. 2. It used another name and was clearly its own standalone effort. The reason for 1 is obvious. If the point is to make Tor more usable, then we shouldn't support a migration of its resources elsewhere. The reason for 2 should also be obvious. Tor is a neutral technology that allows privacy. Some people use their privacy for uses we want to support; others for uses we wish they wouldn't engage in. But, if something were called "Tor" and were devoted to p2p traffic then it would taint the whole Tor project. Don't get me wrong. p2p also has legitimate uses. But in the current climate anything remotely associated with file-sharing is assumed to be illegal. Let's not let that shadow be cast upon Tor. It has enough reputational problems already. Also, Tor is open source. If someone wants to take the code and change it to use their own farm of servers exclusively for p2p traffic then there's nothing the Tor community can do to stop them. I'm not suggesting we should try to stop them. Rather, I'm suggesting we insist that if someone does do that, then they should not call it "Tor" or anything confusingly similar. Brian ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: Active Attacks - Already in Progress?
by Damian Johnson 06 Jul '18

06 Jul '18

Hi Theodore. The reason the operators of the largest tor relays (Blutmagie, TorServers, and Amunet) operate multiple instance is because this is the best way in practice for utilizing large connections. Robert and others are right and you should call people out if they operate multiple relays without setting the family entry. However, both of the relays you cite [1][2] not only have their families set, but contact information too so you're perfectly able to ask them if you have concerns. In particular Moritz, the operator of TorServers, both discussed his plans to get funding for running large relays on this list [3] and with several of us at PETS. I for one am thilled he's had success with it! Lastly, it sounds like you're discussing a Sybil attack. This sort of threat is the reason I wrote a script for monitoring the consensus and sending alerts when large additions to the tor network are made. You are more than welcome to keep an eye on this too by subscibing to the script's email list [4]. Also, this script has discovered this type of attack in the past, so your concerns are certainly understandable. For details see the bit about trotsky on the bad exits wiki [5]. So in short, we are well aware of this sort of attack and your vigilance would certainly be welcome. However, please try to investigate relays a bit and contact their operators before worrying too much about them. Cheers! -Damian [1] http://torstatus.blutmagie.de/router_detail.php?FP=cf91fba32fdac4c500f3a356… [2] http://torstatus.blutmagie.de/router_detail.php?FP=34a46b317dcad4ca52c449d3… [3] http://archives.seul.org/or/talk/May-2010/msg00058.html [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/consensus-tracker [5] https://trac.torproject.org/projects/tor/wiki/badRelays On Wed, Nov 24, 2010 at 9:51 PM, Robert Ransom <rransom.8774(a)gmail.com> wrote: > On Wed, 24 Nov 2010 18:38:23 -0800 > "Theodore Bagwell" <toruser1(a)imap.cc> wrote: > >> We recently discussed an attack on onion-routing anonymity, wherein a >> well-funded adversary overwhelms the network with compromised relays, >> thereby increasing his chances of monitoring anonymity-compromising >> data. >> >> I don't mean to alarm anyone, but I just did some quick-and-dirty >> research that suggests such an attempt may already be under way. I hope >> to be proven wrong. >> >> I postulated that such an attacker would mass-deploy his relays in a way >> that did not lend a whole lot of uniqueness to the name of each relay*. >> The relay names would probably be random characters, numbers, or words >> at best. At sloppiest, they would just be one name with sequential >> numbers after it - "AnonymityAttacker001, AnonymityAttacker002, >> AnonymityAttacker003, etc." >> >> So, I decided to look for such patterns in the list of Relays available >> in my Tor console. A quick scan revealed what appeared to be either (A) >> mass-deployments of Tor relays by a singular entity, or (B) >> astronomically-unlikely coincidental naming schemes adopted by dozens of >> disparate and unconnected individuals.** > > Several people and organizations run multiple Tor relays with obviously > similar names. B They generally do not try to hide their identities or > the connections between their relays. B See > <http://torstatus.blutmagie.de/> for an easily browsable list; click on > the name of a relay to see more detailed information about it, > including the ContactInfo value, if any, specified by the relay's > operator. > > Entities which operate multiple Tor relays can, usually should, and > often do use the MyFamily torrc option to indicate that their relays > are run by a common operator. B If two relays list each other in their > MyFamily directives, your Tor client will not include them in the same > circuit. Unless you have turned off the EnforceDistinctSubnets torrc > option, your Tor client will also not include two relays in the same /16 > network in a single circuit. > > >> But it wasn't just finding these relays that concerned me. It was Tor's >> affinity for routing through them. >> >> See, I began closing my open circuits systematically. I kept records of >> any circuits which contained PPrivCom___ or torserversNet_ relays in it. >> I closed and recorded 43 circuits. Here are my findings: >> >> While Tor indicated it had 1665 relays to choose from, 79% of my >> circuits used one of the suspicious relays. 2% of my circuits used two >> suspicious relays. 0% of my circuits used three suspicious relays. >> >> Of the circuits I recorded, only 21% did not route through a suspicious >> relay. > > Tor weights its node selection according to node bandwidth, as > specified in the consensus. B The consensus, in turn, provides bandwidth > values measured by the bbandwidth authoritiesb. B This weighting is > necessary to balance load fairly throughout the Tor network. > > There should be multiple bandwidth authorities running, operated by > people whom the Tor Project and the directory authority operators > trust; as I understand it, there is currently only one running > bandwidth authority, but the Tor Project is working on getting others > back online. > > >> My conclusion is that someone (a security researcher? A hobbyist? A >> government?) is actively toying with the feasibility of attacking Tor's >> anonymity. According to my statistics, they may also be gaming Tor's >> affinity for choosing relays*** because they have, unquestionably, >> succeeded in relaying 79% of my circuits despite controlling a mere 2.8% >> of the relays in the Tor network. > > The relay families which you have complained about are most likely not > controlled by a single organization, and the organizations that control > them are most likely not trying or planning to attack Tor or its users. > > >> How dangerous is it if two of the three circuit relays are compromised? > > A passive attacker can use some combination of the following > capabilities to try to link you to the Internet server you access using > a Tor circuit: > > * The ability to monitor the TLS connection from your computer to your > B guard node for the circuit. > * The ability to monitor the Tor circuit at your middle node (by > B controlling the middle node and monitoring/logging its internal > B state). > * The ability to monitor the TCP connection from your exit node for the > B circuit to the server you are accessing. > > There are other capabilities which an attacker could have, but I think > the three I have listed are sufficient for this discussion. > > > An attacker who monitors the TLS connection from you to your guard node > and the TCP connection from your exit node to the server can link the > endpoints of your connection using timing alone. B There is no point in > considering the more precise attacks that can be performed by > controlling your guard node and/or exit node themselves; if an attacker > monitors both you and the server you are connecting to, you lose. > > > An attacker who monitors the Tor circuit at your middle node and the > TCP connection from your exit node to the server can link the > connection at the server to your guard node for the circuit. B This will > not provide your IP address to the attacker. B However: > > * An attacker who knows one of your guard nodes may be able to begin > B monitoring the guard node's incoming connections. > * An attacker who knows all three of your current guard nodes, can > B monitor the middle node on another Tor circuit, and sees that it > B originates from a guard node you are not currently using, can > B determine that you did not open that Tor circuit. B This is a > B surprisingly damaging attack, especially if your Tor client has > B chosen one or more low-bandwidth (and therefore relatively unpopular) > B guard nodes. > > > An attacker who monitors the TLS connection from you to your guard node > and the Tor circuit at your middle node may later gain access to logs > kept by the server you are accessing, match the IP address and times of > connections to the server with the times at which you opened TCP > connections through the Tor circuit, and thereby determine what > requests you sent to the server. > > >> What recourse do we have? Can someone more knowledgeable shed more light >> on this? > > There are several torrc options that you can set if you are afraid of > certain relays -- ExcludeNodes, ExcludeExitNodes, StrictNodes, > StrictExitNodes, NodeFamily, and perhaps others. B ExcludeExitNodes may > be useful if you find that an exit node is misbehaving and is not yet > flagged as a BadExit. B I strongly recommend that you DO NOT set any of > these directives, with the possible exception of ExcludeExitNodes, if > you are *very* certain that a particular exit node is actively > malicious. > > All of the above options will change the probability distribution from > which your Tor client chooses circuits. B If you blacklist a few > low-bandwidth relays, you probably won't change the distribution > noticeably, but you won't improve your security noticeably, either. B If > you blacklist one or more of the major families of high-bandwidth Tor > relays and/or exits, you will change the distribution quite noticeably, > and you will make yourself quite distinguishable from normal Tor users. > > The most obvious way in which choosing circuits from an unusual > probability distribution can hurt you is through the distribution from > which you choose exit nodes. B An adversary can capture and examine a > particularly sensitive server's logs, notice that someone is accessing > it only through relatively low-probability Tor exits, and then go look > for logs from less sensitive servers to which you might have given > information that readily identifies you. B If the adversary knows that > someone is posting information they want to suppress to a blog or forum > through low-probability Tor exits, and then finds that Fred Foobar > routinely accesses a shopping site through the same low-probability Tor > exits, Fred Foobar is in trouble. > > There is another, somewhat less obvious way in which choosing circuits > from an unusual distribution can hurt you -- if you routinely download > large files from an adversary-monitored server through high-bandwidth > exit nodes, but low-probability, low-bandwidth middle nodes, the > adversary may be able to detect this fact from the server alone, and > use it to link your connections together. > > I assume that choosing circuits from an unusual distribution can allow > other attacks as well. B In general, the Tor developers try to avoid > making different clients' circuit distributions distinguishable, and > would prefer that you not make your Tor client's circuit distribution > distinguishable yourself, even if there is no obvious way that your > particular change will allow an attack on your anonymity. > > >> * Of course, the well-organized attacker would go to the trouble to >> construct names that truly blended in with the Tor namescape - such >> as,"MrSpudRelays, QueenAnnesRevenge, SteveKenpIsMyHero, and so forth." > > The Adversary would like to thank you for providing those names. B They > will be *very* useful. > > > Robert Ransom > *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Active Attacks - Already in Progress?
by Damian Johnson 06 Jul '18

06 Jul '18

Hi Theodore. The reason the operators of the largest tor relays (Blutmagie, TorServers, and Amunet) operate multiple instance is because this is the best way in practice for utilizing large connections. Robert and others are right and you should call people out if they operate multiple relays without setting the family entry. However, both of the relays you cite [1][2] not only have their families set, but contact information too so you're perfectly able to ask them if you have concerns. In particular Moritz, the operator of TorServers, both discussed his plans to get funding for running large relays on this list [3] and with several of us at PETS. I for one am thilled he's had success with it! Lastly, it sounds like you're discussing a Sybil attack. This sort of threat is the reason I wrote a script for monitoring the consensus and sending alerts when large additions to the tor network are made. You are more than welcome to keep an eye on this too by subscibing to the script's email list [4]. Also, this script has discovered this type of attack in the past, so your concerns are certainly understandable. For details see the bit about trotsky on the bad exits wiki [5]. So in short, we are well aware of this sort of attack and your vigilance would certainly be welcome. However, please try to investigate relays a bit and contact their operators before worrying too much about them. Cheers! -Damian [1] http://torstatus.blutmagie.de/router_detail.php?FP=cf91fba32fdac4c500f3a356… [2] http://torstatus.blutmagie.de/router_detail.php?FP=34a46b317dcad4ca52c449d3… [3] http://archives.seul.org/or/talk/May-2010/msg00058.html [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/consensus-tracker [5] https://trac.torproject.org/projects/tor/wiki/badRelays On Wed, Nov 24, 2010 at 9:51 PM, Robert Ransom <rransom.8774(a)gmail.com> wrote: > On Wed, 24 Nov 2010 18:38:23 -0800 > "Theodore Bagwell" <toruser1(a)imap.cc> wrote: > >> We recently discussed an attack on onion-routing anonymity, wherein a >> well-funded adversary overwhelms the network with compromised relays, >> thereby increasing his chances of monitoring anonymity-compromising >> data. >> >> I don't mean to alarm anyone, but I just did some quick-and-dirty >> research that suggests such an attempt may already be under way. I hope >> to be proven wrong. >> >> I postulated that such an attacker would mass-deploy his relays in a way >> that did not lend a whole lot of uniqueness to the name of each relay*. >> The relay names would probably be random characters, numbers, or words >> at best. At sloppiest, they would just be one name with sequential >> numbers after it - "AnonymityAttacker001, AnonymityAttacker002, >> AnonymityAttacker003, etc." >> >> So, I decided to look for such patterns in the list of Relays available >> in my Tor console. A quick scan revealed what appeared to be either (A) >> mass-deployments of Tor relays by a singular entity, or (B) >> astronomically-unlikely coincidental naming schemes adopted by dozens of >> disparate and unconnected individuals.** > > Several people and organizations run multiple Tor relays with obviously > similar names. B They generally do not try to hide their identities or > the connections between their relays. B See > <http://torstatus.blutmagie.de/> for an easily browsable list; click on > the name of a relay to see more detailed information about it, > including the ContactInfo value, if any, specified by the relay's > operator. > > Entities which operate multiple Tor relays can, usually should, and > often do use the MyFamily torrc option to indicate that their relays > are run by a common operator. B If two relays list each other in their > MyFamily directives, your Tor client will not include them in the same > circuit. Unless you have turned off the EnforceDistinctSubnets torrc > option, your Tor client will also not include two relays in the same /16 > network in a single circuit. > > >> But it wasn't just finding these relays that concerned me. It was Tor's >> affinity for routing through them. >> >> See, I began closing my open circuits systematically. I kept records of >> any circuits which contained PPrivCom___ or torserversNet_ relays in it. >> I closed and recorded 43 circuits. Here are my findings: >> >> While Tor indicated it had 1665 relays to choose from, 79% of my >> circuits used one of the suspicious relays. 2% of my circuits used two >> suspicious relays. 0% of my circuits used three suspicious relays. >> >> Of the circuits I recorded, only 21% did not route through a suspicious >> relay. > > Tor weights its node selection according to node bandwidth, as > specified in the consensus. B The consensus, in turn, provides bandwidth > values measured by the bbandwidth authoritiesb. B This weighting is > necessary to balance load fairly throughout the Tor network. > > There should be multiple bandwidth authorities running, operated by > people whom the Tor Project and the directory authority operators > trust; as I understand it, there is currently only one running > bandwidth authority, but the Tor Project is working on getting others > back online. > > >> My conclusion is that someone (a security researcher? A hobbyist? A >> government?) is actively toying with the feasibility of attacking Tor's >> anonymity. According to my statistics, they may also be gaming Tor's >> affinity for choosing relays*** because they have, unquestionably, >> succeeded in relaying 79% of my circuits despite controlling a mere 2.8% >> of the relays in the Tor network. > > The relay families which you have complained about are most likely not > controlled by a single organization, and the organizations that control > them are most likely not trying or planning to attack Tor or its users. > > >> How dangerous is it if two of the three circuit relays are compromised? > > A passive attacker can use some combination of the following > capabilities to try to link you to the Internet server you access using > a Tor circuit: > > * The ability to monitor the TLS connection from your computer to your > B guard node for the circuit. > * The ability to monitor the Tor circuit at your middle node (by > B controlling the middle node and monitoring/logging its internal > B state). > * The ability to monitor the TCP connection from your exit node for the > B circuit to the server you are accessing. > > There are other capabilities which an attacker could have, but I think > the three I have listed are sufficient for this discussion. > > > An attacker who monitors the TLS connection from you to your guard node > and the TCP connection from your exit node to the server can link the > endpoints of your connection using timing alone. B There is no point in > considering the more precise attacks that can be performed by > controlling your guard node and/or exit node themselves; if an attacker > monitors both you and the server you are connecting to, you lose. > > > An attacker who monitors the Tor circuit at your middle node and the > TCP connection from your exit node to the server can link the > connection at the server to your guard node for the circuit. B This will > not provide your IP address to the attacker. B However: > > * An attacker who knows one of your guard nodes may be able to begin > B monitoring the guard node's incoming connections. > * An attacker who knows all three of your current guard nodes, can > B monitor the middle node on another Tor circuit, and sees that it > B originates from a guard node you are not currently using, can > B determine that you did not open that Tor circuit. B This is a > B surprisingly damaging attack, especially if your Tor client has > B chosen one or more low-bandwidth (and therefore relatively unpopular) > B guard nodes. > > > An attacker who monitors the TLS connection from you to your guard node > and the Tor circuit at your middle node may later gain access to logs > kept by the server you are accessing, match the IP address and times of > connections to the server with the times at which you opened TCP > connections through the Tor circuit, and thereby determine what > requests you sent to the server. > > >> What recourse do we have? Can someone more knowledgeable shed more light >> on this? > > There are several torrc options that you can set if you are afraid of > certain relays -- ExcludeNodes, ExcludeExitNodes, StrictNodes, > StrictExitNodes, NodeFamily, and perhaps others. B ExcludeExitNodes may > be useful if you find that an exit node is misbehaving and is not yet > flagged as a BadExit. B I strongly recommend that you DO NOT set any of > these directives, with the possible exception of ExcludeExitNodes, if > you are *very* certain that a particular exit node is actively > malicious. > > All of the above options will change the probability distribution from > which your Tor client chooses circuits. B If you blacklist a few > low-bandwidth relays, you probably won't change the distribution > noticeably, but you won't improve your security noticeably, either. B If > you blacklist one or more of the major families of high-bandwidth Tor > relays and/or exits, you will change the distribution quite noticeably, > and you will make yourself quite distinguishable from normal Tor users. > > The most obvious way in which choosing circuits from an unusual > probability distribution can hurt you is through the distribution from > which you choose exit nodes. B An adversary can capture and examine a > particularly sensitive server's logs, notice that someone is accessing > it only through relatively low-probability Tor exits, and then go look > for logs from less sensitive servers to which you might have given > information that readily identifies you. B If the adversary knows that > someone is posting information they want to suppress to a blog or forum > through low-probability Tor exits, and then finds that Fred Foobar > routinely accesses a shopping site through the same low-probability Tor > exits, Fred Foobar is in trouble. > > There is another, somewhat less obvious way in which choosing circuits > from an unusual distribution can hurt you -- if you routinely download > large files from an adversary-monitored server through high-bandwidth > exit nodes, but low-probability, low-bandwidth middle nodes, the > adversary may be able to detect this fact from the server alone, and > use it to link your connections together. > > I assume that choosing circuits from an unusual distribution can allow > other attacks as well. B In general, the Tor developers try to avoid > making different clients' circuit distributions distinguishable, and > would prefer that you not make your Tor client's circuit distribution > distinguishable yourself, even if there is no obvious way that your > particular change will allow an attack on your anonymity. > > >> * Of course, the well-organized attacker would go to the trouble to >> construct names that truly blended in with the Tor namescape - such >> as,"MrSpudRelays, QueenAnnesRevenge, SteveKenpIsMyHero, and so forth." > > The Adversary would like to thank you for providing those names. B They > will be *very* useful. > > > Robert Ransom > *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: Interoperating with p2p traffic
by Brian C 06 Jul '18

06 Jul '18

Hi, Matt Thorne wrote: >That isn't a bad Idea, and possibly something that They (with help >ofcourse :-) could build into their P2P software. Probably not a bad >thing for them to lookinto just for their own use, not because We ask >them to, but becuase that would really mess with the heads of the people >at (Insert 4 letter accronym here). > >question: > >how do the people who feel posesive towards tor think about this idea? > >-=Matt=- > >On 10/12/05, *Arrakistor* wrote > What if we designated some type of tor family specifically for p2p > content, and coordinated with the software developers? > If an anonymizing service based on Tor were integrated into some p2p project or if a fork of Tor were to devote itself to serving p2p, then that should only be encouraged by the current Tor community if 1. It didn't take away any current tor servers or tor resources. 2. It used another name and was clearly its own standalone effort. The reason for 1 is obvious. If the point is to make Tor more usable, then we shouldn't support a migration of its resources elsewhere. The reason for 2 should also be obvious. Tor is a neutral technology that allows privacy. Some people use their privacy for uses we want to support; others for uses we wish they wouldn't engage in. But, if something were called "Tor" and were devoted to p2p traffic then it would taint the whole Tor project. Don't get me wrong. p2p also has legitimate uses. But in the current climate anything remotely associated with file-sharing is assumed to be illegal. Let's not let that shadow be cast upon Tor. It has enough reputational problems already. Also, Tor is open source. If someone wants to take the code and change it to use their own farm of servers exclusively for p2p traffic then there's nothing the Tor community can do to stop them. I'm not suggesting we should try to stop them. Rather, I'm suggesting we insist that if someone does do that, then they should not call it "Tor" or anything confusingly similar. Brian ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0