Re: [tor-relays] new relays
This is why we need to implement extended exit flags for exits that want to run post-exit filtering/enhancement policies, say for example noporn that way we can get all the religious groups dumping their tithes into not just beaming reruns of the 700 club around the world, but a pile of uber fast exits too. What a disastrous notion; the exit policy system works because clients can predict in advance whether an exit will pass a given connection; it depends only on the destination host/port. It works because clients can reject some exits they figure they shouldn't waste their time on trying and can proceed trying matching ones. And because the matching ones have historically not been much problem. Predicting the future behavior of exits based on their past, or their current statements, is an odds game some wouldn't put much faith in. That could never be the case for any of these. As with dest ip:port, clients could similarly manage exits based on their postfilter flags. It could work for various purposes but it was more meant ... And how about novirus delivered by microsoft doublesyourcoins propped up by the donations of fools trusted run by legit governments Oh, please, do tell where you expect to find a 'legit' government and why one should 'trust' it? ... forthelols ... which would replace all web pages with (re-read as humor) proposals like this when tor-*@ is busy being too serious, flips the occaisional bird to each other in threads, etc ;) Hopefully all the plaintext protocols will die soon and some replacement for the CA cert model is agreed upon so that there isn't much left to bet on exitwise but the dest ip:port working. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Overload data for Exit vs Non-Exit (and Guard vs Middle)?
Am Freitag, 30. August 2013, 18:25:54 schrieb Mike Perry: To try to get to the bottom of the recent influx of clients to the Tor network, it might be useful to compare load characteristics since 8/19 for nodes with different types of flags. People with Munin setups: it would be especially useful if you could post links/graph images for connection counts, bandwidth, and CPU load since 8/19. I'm particularly interested if people with just the Exit flag (w/o Guard) are seeing increased connection counts that aren't explained by uptime or ramp-up. So far the only datapoint I have for this is https://www.torservers.net/munin/torservers.net/psilotorlu.torservers.net/in dex.html#network but it looks like that node just rebooted and possibly rekeyed, so it's connection increase could just be due to that. It would also be interesting to see if Guard+Exits are seeing a greater increase in connection counts than just Guards. I'm also wondering if any aspects of the load has any other relation to node flags. https://elrippoisland.net/public/load-month.png https://elrippoisland.net/public/fw_forwarded_local-month.png -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5
Re: [tor-relays] always this way?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thu, 29 Aug 2013 19:19:48 -0700 Gordon Morehouse gor...@morehouse.me wrote: That Guy: nodes. People running non-exit relays getting booted out by their VPS/ISP provider. I am just curious if it is getting worse or has it This is rarely due to anything other than bandwidth issues, although some backwards ISPs do not like *any* sort of P2P traffic. I chalk this up to ignorance. Give your money to a better provider if this happens. With VPS providers, there is also the issue of CPU usage. If the host machine does not have the AES-NI acceleration or does not expose it to the VPS guest (and this is extremely common), a relay even at some 50Mbit in + 50Mbit out will already consume 100% of a modern 2.3 GHz CPU core, 24x7. Many or even most VPS providers will not be okay with that. - -- With respect, Roman -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlIhq44ACgkQTLKSvz+PZwhVrQCfREGY5ckpg+EYZUgXLVb5b4dQ JQgAn2ly2Jh6U+QgL+cXIw9r3zXLT5xJ =5aTE -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] Option to restart TOR automatically after it did crash?
If you have systemd(*), you can just change your unit file to contain the following: [service] TimeoutSec = 60 Restart = always RestartSec=60 StartLimitInterval=10 StartLimitBurst=500 and it will always restart the service. * Hard to tell on debian. On Sat, Aug 31, 2013 at 1:10 PM, Paul Staroch paulc...@rueckgr.at wrote: Am 2013-08-31 12:06, schrieb AFO Server Operator: I search for a option to restart my TOR relays after the TOR process did crash on them? Im running TOR alpha on Debian Just add something like */5 * * * * root /etc/init.d/tor start to /etc/crontab. This will launch the init script for tor every five minutes. If tor is running, nothing will happen; if it is not running, it will be started. Paul ___ 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] ???? getting silly now
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The Tor devs go to great lengths to try to keep evil governments from using Tor against itself. Why not devote some effort toward keeping evil traffic off of Tor? Given the fact that we need more relays is the common mantra, it seems to me that if the Tor community could come up with a technical answer to address at least some of the most egregious abuses of Tor--things like child porn, or even porn in general, that either have nothing to do with Tor's foundational mission, or (like child porn) are antithetical to it--the result would be greater public support for the technology, and a wider depl Never thought I would see the day that Senetor Nanny-State would be participating in a tor-relay related mailing list... Sen. Feinstein? That you? M Bloom? too the guy who said What the epic fucking fuck? +1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIcBAEBAgAGBQJSIdlsAAoJEGPr8mk3uIZEZosP/iKWY1Y5NXf2cM5IybyqynAx yUt1oCT/3UU9QiOvt8i6OVa26NIOZyNHzprVQwWCDJk+K9A55CFPqbiQmCQBfZgD bl8dr9ybTYjLWgT/v5dQmTxJzsGtmUx7v53nG3zio33DdWZ6A6HnvSAFOM2qmEvq yo2GBC56Eg3p/x1FvqFwrL+4vM+ZtUPKR3bRIJuXBJjl03iJ8dvHKEKdPaGXQmjd 33OyGo+2Dxp6NfRKPgorURpwENQdngAjm0oJTbT8ox0hAOWtUbl88UDr3Urz+QNs p9fe6NetgKu2w7myUeKovckO8CWXzOw0+FCtsj+0/r24FPEJGqUe8b7MyC6xyvDH RgI3e1SYEuUUIwpUFZ8vlKf70qJNpmyseL9CV0snp1gDT5Xy2tUZ7Q3BPsn7Kl2e 0r6ItZ4rNHFnKFpaZNbg21Cdx/W0MKbPB0FEImzHKGxV3XNwKqY+g3VJ8lIasnQ1 GVLUpBEAMB6v0ONF5elfF4lnvvOqhP7c0MhY95s13Tz7YW/QgzOQpxdpgFGI29l7 /VMsjC7smVEHOB2119hVdImMn9p6hYgJlz2XiofnjvNVSWKgc1O6Rdsu0XlzJgKf ChifpDB93NpFoLdsoyNecbjFuNCYjC0JLQerIGI1dCJxSm3lTu/YV5MNuBCiCzs6 F2mx2wNC/STiDetSlMft =Gy6Y -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] new relays
On 08/30/2013 08:05 PM, Andrea Shepard wrote: [snip] If I were going to work on filtering by technical means, it'd be filters to keep neo-Puritans like you out of my life, thanks. Well said. This whole thread is example 87653478965432 of the censorship is A-OK if I don't like it mindset. Maybe we need a competitor to Tor, a privacy network that only allows pictures of cute kittens and puppies as traffic. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relays
This thread did go goofy and bad (and off-topic, given the subject in the emails). It seems clear that there are important reasons Tor could never begin examining/taking direct responsibility for/filtering the content that flows through it (as opposed with disallowing specific ports, which is different). Asking for this seems naive. On Saturday 31/08/2013 at 8:54 am, Steve Snyder wrote: On 08/30/2013 08:05 PM, Andrea Shepard wrote: [snip] If I were going to work on filtering by technical means, it'd be filters to keep neo-Puritans like you out of my life, thanks. Well said. This whole thread is example 87653478965432 of the censorship is A-OK if I don't like it mindset. Maybe we need a competitor to Tor, a privacy network that only allows pictures of cute kittens and puppies as traffic. ___ 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] Node specialization
http://torstatus.blutmagie.de indicates that only 21.4% of Tor nodes are exit nodes. Are we wasting this precious resource by running non-exit traffic through these nodes? -Pascal ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node specialization
On Sat, Aug 31, 2013 at 11:32:55AM -0500, Pascal wrote: http://torstatus.blutmagie.de indicates that only 21.4% of Tor nodes are exit nodes. Are we wasting this precious resource by running non-exit traffic through these nodes? More important than what percent of nodes are exits is: what percentage of throughput is provided by exit nodes? Based on my (probably wrong) hacking at the stats, exit nodes handle a bit over a third of the actual traffic in the Tor network, 36% in the last snapshot I have at hand. Small nodes tend not to be exits, and exits tend to be quite large (100 Mbps or greater), so limiting exit nodes to only handling exit traffic would actually decrease the overall throughput of the network. -andy ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node specialization
On Sat, Aug 31, 2013, at 05:32 PM, Pascal wrote: http://torstatus.blutmagie.de indicates that only 21.4% of Tor nodes are exit nodes. Are we wasting this precious resource by running non-exit traffic through these nodes? -Pascal No. The non-exit traffic masks which relay the exit traffic is being handled for - which would be quite obvious most of the time. -- http://www.fastmail.fm - The way an email service should be ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node specialization
31.08.2013 18:32, Pascal: http://torstatus.blutmagie.de indicates that only 21.4% of Tor nodes are exit nodes. Are we wasting this precious resource by running non-exit traffic through these nodes? Hi, whenever or not these numbers are accurate or not, yes exit nodes transport all Tor related traffic. They transport client traffic into the network (if they are guards) and back to the client, relay it to exits (where traffic exits) and exit-traffic to and from the destination. The question is whenever or not it beneficial to change the role of nodes to achieve better ... what... performance... anonymity. For example I thought myself if exits should be guards, because if I ran two exits which both got the guard flag and I don't set family on them there is some probability that traffic enters at one point (my exit no.1) and exits to my other exit. Well Tor people are well educated and have more experience in that field. Exits only transporting exit-traffic seems to be beneficial for performance, but to what expense on the anonymity side of things? Best, Sebastian G. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] huge increase in relay traffic
On 2013-08-30 20:39, Yoriz wrote: [..] Aug 29 23:19:59.000 [warn] Received http status code 504 (Gateway Time-out) from server '154.x.x.x:80' while fetching /tor/server/d/54BDF368367470FCBF015...067.z. I'll try again soon. Aug 30 00:14:52.000 [warn] http status 504 (Gateway Time-out) reason unexpected while uploading descriptor to server '154.x.x.x:80'). That likely is the following ticket: https://trac.torproject.org/projects/tor/ticket/8458 Greets, Jeroen ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A bit more evidence on circuit creation storms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Andreas Krey: My main question: How do circuit creation requests on one's Tor relay cause load on one's network infrastructure? Is it DNS requests? Is it TCP connection state entries? It's not bandwidth, we observed that above, and my router can handle far faster pipes than the one it's on currently. The DNS failing is a sign that the router is under severe stress. Possibly your uplink is full (supposing you're on some DSL), and is starting to build up ping time; then DNS requests to the outside can start to timeout. Andreas Unlikely - I do pseudo-QoS such that my uplink should never be full. It's possible, but I believe it's more likely that my router is thrashing for whatever reason and starts to be real slow at responding to DNS. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSIi9ZAAoJED/jpRoe7/ujL2EH/0O7HxgB/g5nEKFxgz114cYC gnlNzKXc2xUYZ92vv7BnNwuZ6TuFvW1qNBXT+9T1ObYWngnn/e3Jz8QOF6axmTd3 C+l2asKurD6M4dqkY53miLzrd783JTkgiPYaW6bNdFrmy+hzYjTbHuShccFYgncb SWRXIMk6OXDqLhCyMAUjlR6Dd0yq6uJMAefmgLyEc9stvrRcrK8de0xD2/qVnHCi RNJVQXAjKk5NvOIiONBilDl1jQsGgUkENz0Rh9naN9tjOE+Ev0lWbhUZpA09+2is T2/IbXQXS8m9c4KfL6Z+aSufD9ALjQrYLNQBs6vzk+SEl4ghyCoMOMzPMGS2JvE= =z+Zl -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] A bit more evidence on circuit creation storms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 krishna e bera: On 13-08-29 10:35 PM, Gordon Morehouse wrote: What on earth is causing so many circuit creation requests in such a short timespan? One possibility, if i recall correctly, is that the Tor that comes with the PirateBrowser bundle is configured to build single hop circuits. Make sure that these defaults are still set in your relay: The DDOS - because that's what it obviously is - managed to kill my Pi-based node last night, so I've finally restarted with all these except RefuseUnknownExits 1, just because of your caveat. I had some of the statistics already enabled, so it's continuing to collect those. Is there a way to give Tor a hard memory cap, so it won't chew up all available RAM on the system? AllowSingleHopExits 0 AllowSingleHopCircuits 0 You can also try RefuseUnknownExits 1but maybe auto is better And these may help sketch the circuit storms: EntryStatistics 1 ExitPortStatistics 1 ConnDirectionStatistics 1 Best, Gordon M. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSIjJoAAoJED/jpRoe7/ujuicH/Au5NXr/q5MTYH54mPPuE/OJ 9jOkT/M34O0+U9gqYH8ja2gzTFf3CdxESraS6A7A+r2DWUX9R6l+zia5YX/SYCUu dWWNB843vXhcjNqhw01h05c70QgKStKrm6sLCjliVxhcovfMnkmMxLxk3EmQ3OzW nOdHQT2QGV+xCXqYz7FS9OtCnRmjTjI3bb8PJ1xcL76IjPGlCKr5vt7cDO3Y7x80 o0hnPJxMhYs0MhS5sNXfHIifDNT6LlCuZvIT0GLe3w9Gg15BUYKgn5bi1iNEtoSV J/2DbxvmT23Tv6E2WnpxEoOu/yupbHAiDcYbwIT1ig4mePA/xCgjdm7mEdqrXpE= =AiLg -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] A bit more evidence on circuit creation storms
On Thu, Aug 29, 2013 at 11:30:33PM -0400, krishna e bera wrote: On 13-08-29 10:35 PM, Gordon Morehouse wrote: What on earth is causing so many circuit creation requests in such a short timespan? One possibility, if i recall correctly, is that the Tor that comes with the PirateBrowser bundle is configured to build single hop circuits. As far as I can tell from the configuration files people have posted here, this is not so. The Pirate Browser makes normal 3-hop circuits. It just includes a bunch of config lines that make you think it's doing 1-hop circuits -- but we haven't written any Tor config options to make you build 1-hop circuits. You'd have to hack your controller on the client side (or the Tor software directly), and even then you could only use the handful of relays that have allowed it. As for the circuit create storm phenomenon... if this is in fact a botnet signing up the million new users, and they're connecting to a hidden service CC site, then I would expect even fiercer create storms. See also https://trac.torproject.org/projects/tor/ticket/9574 --Roger ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node specialization
On Sat, 31 Aug 2013 09:58:12 -0700 Andy Isaacson a...@hexapodia.org wrote: On Sat, Aug 31, 2013 at 11:32:55AM -0500, Pascal wrote: http://torstatus.blutmagie.de indicates that only 21.4% of Tor nodes are exit nodes. Are we wasting this precious resource by running non-exit traffic through these nodes? More important than what percent of nodes are exits is: what percentage of throughput is provided by exit nodes? https://compass.torproject.org has some of these stats. -- Andrew http://tpo.is/contact pgp 0x6B4D6475 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A bit more evidence on circuit creation storms
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Roger Dingledine: On Thu, Aug 29, 2013 at 11:30:33PM -0400, krishna e bera wrote: On 13-08-29 10:35 PM, Gordon Morehouse wrote: What on earth is causing so many circuit creation requests in such a short timespan? [snip] As for the circuit create storm phenomenon... if this is in fact a botnet signing up the million new users, and they're connecting to a hidden service CC site, then I would expect even fiercer create storms. See also https://trac.torproject.org/projects/tor/ticket/9574 Hi Roger, and thanks for taking the time to respond. I've definitely seen an increase in the storms compared to the baseline I established on my Raspberry Pi after upgrading to 0.2.4.16-rc; but so far only one crash. There has been a ripple or two on my bigger VPS relays. If I could bug you for a sec, I do have some questions about how circuit creation works in Tor. I hope you have a moment to answer. The full message is at: https://lists.torproject.org/pipermail/tor-relays/2013-August/002589.html Here is the main set of questions (the numbers are in the full message): My main question: How do circuit creation requests on one's Tor relay cause load on one's network infrastructure? Is it DNS requests? Is it TCP connection state entries? It's not bandwidth, we observed that above, and my router can handle far faster pipes than the one it's on currently. The DNS failing is a sign that the router is under severe stress. Back in the 0.2.3.x days, I often had to reboot the *router* after one of these storms, not just the Tor relay. And again - do we really know what is causing this? Something seems seriously wrong with the kind of numbers I'm seeing coming in to a node with MaxAdvertisedBandwidth 250KB. Thanks much, - -Gordon M. -BEGIN PGP SIGNATURE- iQEcBAEBCgAGBQJSIqe3AAoJED/jpRoe7/ujFKsH/A6zDg7QnvWF+n+hqFFao890 RO6BqcVnwgfqYaHNvgeQy+8IX16OT+4ccdmXWqAqa7LoJKTzXkAG9X2pQ60V5wNx PfeXR/sf9N0ZEiQFrC4mhJB+n7RImjiDflpgMKZnVUnGdalRG/b8ht2hpcAf/PfE RCqPn0DzEwOQUav8sG1pkc0Ii3iu1Xuo288lHjwElXEBo6SSMZ21X2EPUxJPCFtd Qp4TJ+pVYf6RJPX1amYdEbVcAGlIYELVXo4opSiqc4Bklng2vrZYwwpUU2KRWjqx Fq3CcKa+naXFm4JZXn8FtqrEb8LZhObOFDrjD6MlxPuwBL0GN9SOrV205ByJ+Sk= =s+9T -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
