- tor-relays - lists.torproject.org

The Assistance and Access Bill 2018
by Paul Templeton 05 Sep '18

05 Sep '18

On a satire note - https://www.youtube.com/watch?v=eW-OMR-iWOE But seriously - https://www.homeaffairs.gov.au/about/consultations/assistance-and-access-bi… And - https://www.homeaffairs.gov.au/about/national-security/five-country-ministe… The thing that worries me is that this bill will probably go through and it can hoover up relay operators. That is they can force you to add/develop tools to eavesdrop on you. Is there any real defense against this bill? IE having a parameter in the torrc that would act like a canary? Paul 137CF322859E400455E457DB920F65FFDD222CDF

7 8

SSH login attempts
by Marcus Wahle 05 Sep '18

05 Sep '18

Dear all, Since 14:00 my logs (middle node) are spamed with around 100 faild ssh login attemps from different ips. Is there anybody else affected? Best regards Marcus

14 14

Multi node management programs/platforms?
by Isaac Grover, Aileron I.T. 04 Sep '18

04 Sep '18

Good evening, For those of you who manage multiple exits and/or relays, what program/platform do you use to manage them? Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" Office: 715-377-0440, Fax:715-690-1029, Web: www.aileronit.com

9 11

9 routing security recommendations for relay operators
by nusenu 04 Sep '18

04 Sep '18

(mostly a copy paste from [0]) 1. Monitor your relay’s BGP prefix for suspicious BGP activity and share alerts with this mailing list. The easiest way to do so is to subscribe to your prefixes using https://bgpmon.net/. You should practically get zero alerts. 2. Check the following properties of the prefixes you use (ideally even before ordering servers): prefix length and IRR state [1] RPKI state [2] 3. Ask your ISP/IP holder to create ROAs [4] for the prefixes you use, if the ROA is currently missing. 4. Ensure the ROA creator is aware of the risks of the maxlength attribute [3] and uses it accordingly (in the best case not at all) 5. Monitor the RPKI validity state of your prefixes (can also be done with bgpmon) 6. Ask your ISP to announce the IP space of your relays in /24 prefixes (/48 for IPv6) to avoid more-specific prefix hijacks (this makes sense even if you have ROAs in place due to the low ROV coverage) 7. If your relay uses IP addresses from the RIPE region: ask your provider to create route(6) objects matching the announcements if they are not present yet. You can use RIPEstat’s prefix routing consistency widget [1] to check the current state (the “In RIS” and “RIPE IRR” columns should both say “yes”). 8. Be aware that “LEGACY” or “ERX” IP space might be less likely to get ROAs by your ISP 9. Enable IPv6 on your relays [0] https://medium.com/@nusenu/how-vulnerable-is-the-tor-network-to-bgp-hijacki… [1] https://stat.ripe.net/widget/prefix-routing-consistency [2] https://rpki-validator.ripe.net/bgp-preview [3] https://www.youtube.com/watch?v=I3Owb0u8Wuk [4] https://www.ripe.net/manage-ips-and-asns/resource-management/certification/… https://www.arin.net/resources/rpki/using_rpki.html -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

relayor v18.1.0 is released
by nusenu 04 Sep '18

04 Sep '18

Hi, relayor v18.1.0 is released. relayor helps you with running relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor Changes since v18.0.0: ------------------------------ - enable NoExec by default on all platforms except CentOS - increase min. ansible version from 2.5.3 to v2.6.2 - fix the ExitPolicy format in the example playbook - change default shipped exit policy (remove POP3, IMAP and kerberos ports) - change the ControlSocket location -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

1 0

Unmeasured - 69D9FF1BE14B9AE77701A6BCBC075FF837F5AFF9
by Dark Matter 03 Sep '18

03 Sep '18

Greetings, my relay 69D9FF1BE14B9AE77701A6BCBC075FF837F5AFF9 (darkmatter) recently (3 days) received an Unmeasured flag and is considered to be offline. I could not detect any issues on my side and wondered if you could help me to resolve this. Best regards, Dark

2 1

Relay operators meetup part #2 @ Onionspace, Berlin
by Vasilis 03 Sep '18

03 Sep '18

Dear Tor friends and relay operators, Next Saturday (25/08/18) a follow-up relay operators meetup will take place at Onionspace, Berlin. The meetup will start at 16:00 and depending on the weather we may move afterwards to the garden. When: Saturday, August 25th, 2018 Start Time: 16:00 / 4:00 PM Where: Gottschedstrasse 4, Entrance 4, 13357 Berlin (U Nauener Platz), Onionspace Map: https://www.openstreetmap.org/#map=18/52.54978/13.36991 Event link: https://blog.torproject.org/events/tor-friends-and-relay-operators-meetup-2… 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 1

Exit in Turkey blocking torproject (komm EA93C), BadExit, Node Subscription Services, Censorship
by grarpamp 03 Sep '18

03 Sep '18

This particular case receiving mentions for at least a few months... D1E99DE1E29E05D79F0EF9E083D18229867EA93C kommissarov 185.125.33.114 The relay won't [likely] be badexited because neither it nor its upstream is shown to be doing anything malicious. Simple censorship isn't enough. And except for such limited censorship, the nodes are otherwise fully useful, and provide a valuable presence inside such regions / networks. Users, in such censoring regimes, that have sucessfully connected to tor, already have free choice of whatever exits they wish, therefore such censorship is moot for them. For everyone else, and them, workarounds exist such as,,, https://onion.torproject.org/ http://yz7lpwfhhzcdyc5y.onion/ search engines, sigs, vpns, mirrors, etc Further, whatever gets added to static exitpolicy's might move out from underneath them or the censor, the censor may quit, or the exit may fail to maintain the exitpolicy's. None of which are true representation of the net, and are effectively censorship as result of operator action even though unintentional / delayed. Currently many regimes do limited censorship like this, so you'd lose all those exits too for no good reason, see... https://ooni.torproject.org/ https://en.wikipedia.org/wiki/Internet_censorship_and_surveillance_by_count… And arbitrarily hamper spirits, tactics, and success of volunteer resistance communities and operators in, and fighting, such regimes around the world. And if the net goes chaotic, majority of exits will have limited visibility, for which exitpolicy / badexit are hardly manageable solutions either, and would end up footshooting out many partly useful yet needed exits as well. If this situation bothers users, they can use... SIGNAL NEWNYM, New Identity, or ExcludeExitNodes. They can also create, maintain and publish lists of whatever such classes of nodes they wish to determine, including various levels of trust, contactability, verification, ouija, etc... such that others can subscribe to them and Exclude at will. They can further publish patches to make tor automatically read such lists, including some modes that might narrowly exclude and route stream requests around just those lists of censored destination:exit pairings. Ref also... https://metrics.torproject.org/rs.html#search/as:AS197328%20flag:exit https://metrics.torproject.org/rs.html#search/country:tr%20flag:exit In the subect situations, you'd want to show that it is in fact the exit itself, not its upstream, that is doing the censorship. Or that if fault can't be determined to the upstream or exit, what would be the plausible malicious benefit for an exit / upstream to block a given destination such that a badexit is warranted... a) Frustrate and divert off 0.001% of Turk users smart enough to use tor, chancing through tor client random exit selection of your blocking exit, off to one of the workarounds that you're equally unlikely to control and have ranked, through your exit vs one of the others tor has open? b) Prop up weird or otherwise secretly bad nodes on the net, like the hundreds of other ones out there, for which no badexit or diverse subscription services yet exist to qualify them? c) ??? Or that some large number of topsites were censored via singular or small numbers of exits / upstreams so as to be exceedingly annoying to the network users as a whole, where no other environment of such / chaotic widespread annoyance is known to exist at the same time.

12 25

Policy Question: Tor Exits at Universities, Corporate Networks, etc
by Nathaniel Suchy 02 Sep '18

02 Sep '18

Recently we've been discussing a Tor Exit in Turkey censoring access to various websites. It's less to some err, disagreements on what should and should not be allowed. I've seen a few opinions: *) It grants an outside view at what Turkey censors *) It could push new tor users away This leads me to question if it's okay for a Tor Exit to be on a censored network are the following scenarios now allowed? *) A Tor Exit behind a Corporate Network and Web Filter *) A Tor Exit behind a University Network and Web Filter Under the logic with the Turkey exit relay it should be right? Cordially, Nathaniel

5 5

Message to devs, please don't change log strings
by gustavo 02 Sep '18

02 Sep '18

Hi In the last few months I started to monitor more closely my relays parsing their logs, but every new update changes the log strings. Can the devs be mindful to relay ops and not change strings needlessly? Here is an example 0.3.3.9 Sep 1 00:01:32 serverhostname tor[15341]: Sep 01 00:01:32.042 [notice] 0.3.something Sep 1 00:01:32 serverhostname Tor[15341]: Sep 01 00:01:32.042 [notice] 0.2.9 Sep 1 00:01:32 serverhostname Tor[15341]: [notice] I'm logging to syslog thanks! -- IRC: gfa GPG: 0X44BB1BA79F6C6333

3 3