- tor-relays - lists.torproject.org

Hetzner - "no.spam@example.com" relays
by nusenu 29 Jan '19

29 Jan '19

Hi, to the operator of the relays listed bellow. You care currently not setting the MyFamily option on your relays, which puts tor users at risk. Please configure your relays with MyFamily to avoid getting your relays rejected. more information: https://medium.com/@nusenu/some-tor-relays-you-might-want-to-avoid-5901597a… https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays#Whatis… 2019-01-28 | Up | Ext | JoinTime | Nickname | Version | IP | AS | CC | ORp | Dirp | OS | Contact | eFamMembers | FP | |------+-------+------------+---------------------+-----------+----------------+---------------------+------+-------+--------+-------+---------------------+---------------+------------------------------------------| | 0 | 0 | 01:34:19 | somerelay | 0.3.3.7 | 116.203.57.161 | Hetzner Online GmbH | de | 9001 | 9030 | Linux | no.spam(a)example.com | 1 | 24C3BC672621D6FCB7923DE031738B23EE0C1819 | | 0 | 0 | 01:48:53 | somerelay | 0.3.3.7 | 116.203.57.161 | Hetzner Online GmbH | de | 9001 | 9030 | Linux | no.spam(a)example.com | 1 | CBDCA8B16E2D4111A6618BAB3F114C358B8E35DB | | 1 | 0 | 05:00:50 | somerelay1IHcuer9Cn | 0.3.3.7 | 116.203.57.161 | Hetzner Online GmbH | de | 9001 | 9030 | Linux | no.spam(a)example.com | 1 | CA307A53194D6DE8B033226C541654117AFCF5F2 | | 1 | 0 | 02:54:44 | somerelayId8wPoBbRJ | 0.3.3.7 | 116.203.57.160 | Hetzner Online GmbH | de | 9001 | 9030 | Linux | no.spam(a)example.com | 1 | F9578C192A76062C2B49F938A53291AA5CE3CFBF | | 1 | 0 | 02:54:49 | somerelayT7WbYRznBW | 0.3.3.7 | 116.203.59.81 | Hetzner Online GmbH | de | 9001 | 9030 | Linux | no.spam(a)example.com | 1 | CFDF026F3FC52BF347A395A1224D70D9ACBEF9C5 | | 1 | 0 | 02:55:45 | somerelayung2AiqzXu | 0.3.3.7 | 116.203.66.45 | Hetzner Online GmbH | de | 9001 | 9030 | Linux | no.spam(a)example.com | 1 | 97F47C07A3DEA4C1A885C2C15008592635DA54B6 | | 1 | 0 | 02:54:46 | somerelayvpoDStFnGZ | 0.3.3.7 | 94.130.184.189 | Hetzner Online GmbH | de | 9001 | 9030 | Linux | no.spam(a)example.com | 1 | 5CD0F83B59229F86419757FE54CFF6EE859EA0ED | https://nusenu.github.io/OrNetRadar/2019/01/28/a7 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

Having Trouble With Speed Of OBFS4 Bridge
by Keifer Bly 29 Jan '19

29 Jan '19

Hello, So my OBFS4 bridge at https://metrics.torproject.org/rs.html#details/148BD64BED9F2C27637D986DE032E CF14E5B9E9A seems to be having some speed issues, only reaching about 40-50 kb/s of speed. This is strange, as it should be much faster than this. My thoughts on why this is happening: Where I living, am probably nowhere near the bridge authorities for one. I am running an obfuscated bridge (which as this requires an additional process to be running alongside the tor process, could this be a part of it?) I am running off of the only internet provider available in my area (Charter / Spectrum) which is an isp that uses cable structure so maybe they have some kind of limitation in place? My router is a Netgear Orbi router which should be able to handle up to 60,000 connections at once so there should be no issue there. Any help is appreciated, thank you. --Keifer

3 8

diff-cache OOM
by notatorserver 28 Jan '19

28 Jan '19

I am running tor 4.0.1-alpha inside a docker container with a memory limit (6GB). Tor runs out of memory and aborts or crashes periodically. Usually I see an error message like this: Could not mmap file "/var/lib/tor/data/diff-cache/1149": Out of memory ...(repeated some number of times) followed by segfault Sometimes I see a message: Out of memory on malloc(). Dying followed by abort. Am I correct to assume the diff-cache is the issue here? Looking at the files it seems they are all pretty small (~500K). Is some badly behaved client requesting 12,000 of these diffs causing my relay to mmap them all at once? or is it just expensive to generate and generating 30-60 at once is enough to use all the memory? Are there any config options to reject expensive queries or otherwise limit concurrency? Thanks

2 2

Shutdown of fallback directory mirror armbrust: E781F4EC69671B3F1864AE2753E0890351506329
by Michael Armbruster 27 Jan '19

27 Jan '19

Dear tor-relay list, After a long time maintaining an exit relay that was also chosen to be a fallback directory mirror, I decided that the time has come to shut the relay down. It has only financial reasons (being a cheap server, but still using money out of my own pocket) and I will stay a happy user of Tor and, of course, will provide a new relay as soon as my financial situation gets better. How should we proceed and how long should I still let the fallback mirror run in order to gracefully migrate the fallback status away from my server? I do not want to disappear immediately without any further notice, so I wanted to ask how to further proceed. Kind regards, Michael Armbruster

2 1

Overlay Networks: Research Improvements and Attacks [was: planetlab butterfly relays]
by grarpamp 23 Jan '19

23 Jan '19

On 1/23/19, nusenu <nusenu-lists(a)riseup.net> wrote: > thanks for adding tor relays. > If you are using them for research purposes please ensure > you follow the safety guidelines: > https://research.torproject.org/safetyboard.html > https://medium.com/@nusenu/some-tor-relays-you-might-want-to-avoid-5901597a… > https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays > | Up | Ext | JoinTime | Nickname | Version | IP | > AS | CC | ORp | Dirp | OS | > Contact | eFamMembers | FP | > https://twitter.com/nusenu_ > https://mastodon.social/@nusenu As many know, many guidelines regarding the stronger distributed encrypted overlay and messaging networks out there are naturally voluntary, and research and attacks are often generally unenforceable and or undetectable when undertaken by qualified adversaries. Many parties [publicly] subscribe to such guidelines, many [silently] don't. That's the nature [and one of the risks] of such networks, indeed of any network. Such adversaries exist and are highly active and capable. Know your adversary. Strengthen your designs to match and best them. As to the nodes, they're all planet-lab.net hosts, planetlab has at least two known tor slices "okstate_tor" and "uml_ZhenLing", some public research outputs [or not] of which might be listed below... https://www.cs.uml.edu/~xinwenfu/paper/TorCellSize_ICC11_Fu.pdf https://www.cs.uml.edu/~xinwenfu/paper/TorWard14_Fu.pdf http://cse.seu.edu.cn/PersonalPage/zhenling/publications_files/infocom2014_… http://cse.seu.edu.cn/PersonalPage/zhenling/publications_files/infocom2013_… http://cse.seu.edu.cn/PersonalPage/zhenling/publications_files/infocom2012_… https://news.okstate.edu/articles/communications/2015/tedx-returns-oklahoma… https://www.youtube.com/watch?v=9QsjkJcUznA MEMEX Christopher White ‎Jiangmin yu, Eric Chan-Tin: Realistic Cover Traffic to Mitigate Website Fingerprinting Attacks DOI: 10.1109/ICDCS.2018.00175 Conference: 2018 IEEE 38th International Conference on Distributed Computing Systems (ICDCS) Identifying Webbrowsers in Encrypted Communications DOI: 10.1145/2665943.2665968 Revisiting Circuit Clogging Attacks on Tor DOI: 10.1109/ARES.2013.17 Conference: Availability, Reliability and Security (ARES), 2013 Eighth International Conference on https://chantin.cs.luc.edu/~chantin/ARES2013.pdf Application Of Data Analytics - Case Studies https://shareok.org/bitstream/handle/11244/54637/Yu_okstate_0664D_15098.pdf

1 0

planetlab butterfly relays
by nusenu 23 Jan '19

23 Jan '19

Hi bf@ctct, thanks for adding tor relays. If you are using them for research purposes please ensure you follow the safety guidelines: https://research.torproject.org/safetyboard.html You care currently not setting the MyFamily option on your relays, which puts tor users at risk. Please configure your relays with MyFamily. more information: https://medium.com/@nusenu/some-tor-relays-you-might-want-to-avoid-5901597a… https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays#Whatis… | Up | Ext | JoinTime | Nickname | Version | IP | AS | CC | ORp | Dirp | OS | Contact | eFamMembers | FP | |------+-------+------------+--------------+-----------+-----------------+------------------------------------------+------+-------+--------+-------+---------------+---------------+------------------------------------------| | 1 | 0 | 08:03:03 | butterfly002 | 0.3.5.7 | 200.129.132.19 | Associa\u00E7\u00E3o Rede Nacional de En | br | 9001 | 9030 | Linux | bf(a)ctct.org | 1 | 508BDBDA23A6B76D3C5B2D17DBEA2A4E170859BD | | 1 | 0 | 09:40:10 | butterfly003 | 0.3.5.7 | 216.48.80.12 | University of Ottawa | ca | 9001 | 9030 | Linux | bf(a)ctct.org | 1 | 09F83FDF39A459D91AB8EC18B44A7F389BB5D87C | | 1 | 0 | 09:47:23 | butterfly004 | 0.3.5.7 | 200.17.202.195 | Fundacao da UFPR para o DCTC | br | 9001 | 9030 | Linux | bf4(a)ctct.org | 1 | 7BA8CCC7EFE0D6ED1386173631CC825CB39D6F6F | | 1 | 0 | 11:12:56 | butterfly005 | 0.3.5.7 | 129.97.74.12 | University of Waterloo | ca | 9001 | 9030 | Linux | bf5(a)ctct.org | 1 | ECFFC5A820CBFD37AC2F85AA2C8DC77F87796F16 | | 1 | 0 | 12:07:56 | butterfly006 | 0.3.5.7 | 200.19.159.35 | Associa\u00E7\u00E3o Rede Nacional de En | br | 9001 | 9030 | Linux | bf6(a)ctct.org | 1 | F1F92CC70007DB1EB63B28623B8481863ED3B29F | | 1 | 0 | 12:22:19 | butterfly007 | 0.3.5.7 | 128.8.126.111 | University of Maryland | us | 9001 | 9030 | Linux | bf7(a)ctct.org | 1 | FCA01B39D2CA5DAE896EAAABDB010B0040D068EF | | 0 | 0 | 11:56:55 | butterfly008 | 0.3.5.7 | 192.33.90.67 | SWITCH | ch | 9001 | 9030 | Linux | bf8(a)ctct.org | 1 | 2447A5A12AC3DB748317F97E3317814C42BF0380 | | 1 | 0 | 13:10:27 | butterfly008 | 0.3.5.7 | 133.69.32.131 | Asia Pacific Advanced Network - Japan | jp | 9001 | 9030 | Linux | bf8(a)ctct.org | 1 | 748653AF527B393EFB5870DFA840F8FD578E19BA | | 1 | 0 | 12:36:30 | butterfly009 | 0.3.5.7 | 188.44.50.106 | Federal State Educational Institution of | ru | 9001 | 9030 | Linux | bf9(a)ctct.org | 1 | DCC2DD20CC44DC617A859EA9EFE1A40C5215CAC0 | | 1 | 0 | 13:28:32 | butterfly010 | 0.3.5.7 | 134.117.226.180 | Carleton University | ca | 9001 | 9030 | Linux | bf10(a)ctct.org | 1 | FD82A15B62B73DF4CE20003B651CBB7384C37539 | -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

DNS Server
by dns1983＠riseup.net 23 Jan '19

23 Jan '19

Hello, i'm a student, so I lack many networking notions. Which are the most privacy reliable public dns servers? I don't exactly know how choose a third part DNS server. I read that cloudfare servers are audited by third parties but I'm not sure that I can trust. do you think that audition is trustworthy? Thanks -- Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.

4 11

Tor meetup @ RADIX hacklab, Athens
by Vasilis 19 Jan '19

19 Jan '19

Dear Tor friends and relay operators, Next Friday (25.01.201) a Tor relay operators meetup will take place at RADIX hacklab, Athens. When: Friday, January 25th, 2019 Time: 19:00 / 7:00 PM Where: Kaniggos 34 & Stournari, Athens 10682, Greece Event link: https://blog.torproject.org/events/tor-meetup-athens Hope to see many of you there. Cheers, ~Vasilis -- Fingerprint: 8FD5 CF5F 39FC 03EB B382 7470 5FBF 70B1 D126 0162 Pubkey: https://pgp.mit.edu/pks/lookup?op=get&search=0x5FBF70B1D1260162

1 0

Leaky-pipe circuit topology
by marziyeh latifi 18 Jan '19

18 Jan '19

Hello, May you explain me what is Leak-pipe circuit topology? I studied Leaky-pipe circuit topology in "tor- design" document but I don't understand how it work! thanks best regards marzieh

2 1

Bandwidth limiting at relay or network?
by Isaac Grover, Aileron I.T. 18 Jan '19

18 Jan '19

Good evening fellow relay operators, I haven't ever taken the time to configure bandwidth limits in torrc, always preferring to manage it at the firewall as we have other bandwidth limits set there as well. However, I'm curious - what do other relay operators prefer? Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - " Because #ProactiveIsBetter " O: 715-377-0440<tel:715-425-0440>, F:715-690-1029<tel:715-690-1029>, W: www.aileronit.com<http://www.aileronit.com/> LinkedIn: https://www.linkedin.com/in/IsaacGrover/ YouTube: https://www.youtube.com/channel/UCqrwZNFKdR-guKtuQzFPObQ

3 2