- tor-relays - lists.torproject.org

zwiebeln@online.de relays: MyFamily update required (was: [OrNetRadar] Contact: "<zwiebeln at online de>")
by nusenu 05 Jan '17

05 Jan '17

Hi zwiebeln, thanks for running so many tor exit instances and adding so many yesterday. Please do not forget to add your new relays to your MyFamily, your "old" relays had a proper MyFamily configuration. thanks, nusenu https://raw.githubusercontent.com/ornetstats/stats/master/o/potentially_dan… +---------------------+-----------------+---------------+------+ | first_seen | IP | MyFamilyCount | exit | +---------------------+-----------------+---------------+------+ | 2016-04-11 21:00:00 | 178.17.170.179 | 25.0000 | 1 | | 2016-05-14 15:00:00 | 195.123.209.184 | 25.0000 | 1 | | 2016-07-03 15:00:00 | 178.17.170.179 | 25.0000 | 1 | | 2016-08-28 12:00:00 | 37.157.193.161 | 25.0000 | 1 | | 2016-09-10 14:00:00 | 37.157.193.161 | 25.0000 | 1 | | 2016-09-16 21:00:00 | 89.221.209.100 | 25.0000 | 1 | | 2016-09-18 12:00:00 | 37.157.196.97 | 25.0000 | 1 | | 2016-09-27 10:00:00 | 37.157.196.97 | 25.0000 | 1 | | 2016-09-27 10:00:00 | 89.221.209.100 | 25.0000 | 1 | | 2016-11-12 21:00:00 | 144.217.60.211 | 25.0000 | 1 | | 2016-11-12 23:00:00 | 213.32.55.239 | 25.0000 | 1 | | 2016-11-14 12:00:00 | 149.202.238.204 | 25.0000 | 1 | | 2016-11-15 15:00:00 | 144.217.60.239 | 25.0000 | 1 | | 2016-11-15 15:00:00 | 158.58.170.150 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.212 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.27 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.212 | 25.0000 | 1 | | 2016-11-28 17:00:00 | 178.17.170.27 | 25.0000 | 1 | | 2016-12-05 16:00:00 | 51.15.53.83 | 25.0000 | 1 | | 2016-12-05 16:00:00 | 46.182.18.29 | 25.0000 | 1 | | 2016-12-05 16:00:00 | 51.15.53.83 | 25.0000 | 1 | | 2016-12-05 17:00:00 | 46.182.18.29 | 25.0000 | 1 | | 2016-12-05 17:00:00 | 46.182.18.214 | NULL | 1 | | 2016-12-16 20:00:00 | 88.151.99.224 | NULL | 1 | | 2016-12-18 18:00:00 | 185.14.29.129 | NULL | 0 | | 2016-12-18 22:00:00 | 149.202.238.204 | NULL | 0 | | 2016-12-18 22:00:00 | 144.217.60.239 | NULL | 0 | | 2016-12-18 22:00:00 | 144.217.60.211 | NULL | 0 | | 2016-12-18 22:00:00 | 213.32.55.239 | NULL | 0 | | 2016-12-18 23:00:00 | 158.58.170.150 | NULL | 0 | +---------------------+-----------------+---------------+------+ ornetradar(a)riseup.net: > 2016-12-18 > ----------------------------------------------------------------------------------------------------------------------- > Up|Ext|JoinTime| IP | AS | CC | ORp | Dirp | OS | Version | Nickname | eFamlen > ----------------------------------------------------------------------------------------------------------------------- > 1 | 0 | 21:41:51 | 149.202.238.204 | OVH SAS | fr | 444 | 81 | Linux | 0.2.8.11 | alsaceonionb | 1 > 1 | 0 | 21:26:02 | 144.217.60.239 | OVH SAS | ca | 444 | 81 | Linux | 0.2.8.11 | quebeconionb | 1 > 1 | 0 | 21:31:09 | 144.217.60.211 | OVH SAS | ca | 444 | 81 | Linux | 0.2.8.11 | montrealonionb | 1 > 1 | 0 | 21:36:53 | 213.32.55.239 | OVH SAS | fr | 444 | 81 | Linux | 0.2.8.11 | strasbourgonionb | 1 > 1 | 0 | 22:24:55 | 158.58.170.150 | Seflow S.N.C. D | it | 444 | 81 | Linux | 0.2.8.11 | milanoonionb | 1 > 1 | 0 | 17:42:44 | 185.14.29.129 | Serverius Holdi | nl | 9001 | 9030 | FreeBSD | 0.2.8.11 | humboldt | 1

2 5

Current pluggable transport recommendation
by Alexander Dietrich 05 Jan '17

05 Jan '17

Hi, the obfs2 pluggable transport was deprecated a while ago since it was easy to detect, but obfs3 was still considered safe, IIRC. Has anything changed here? I was just wondering if new bridges should only run obfs4, or if it's fine to run obfs3 at the same time. Best regards, Alexander -- PGP Key: https://dietrich.cx/pgp | 0x52FA4EE1722D54EB

2 1

High conntrack session count
by Sec INT 04 Jan '17

04 Jan '17

Hi Just had an issue on a 60mbps exit where conntrack sessions went over the usual 30000 limit - is this possible for a normal operating exit relay? Is there any default limit set on this or indeed is there a setting intorrc to control the number of sessions? Cheers Mark B Snaptor.co.uk (non commercial)

2 2

Tor Cloud
by Scott Ainslie 04 Jan '17

04 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello, I'm in the midst of relaunching Tor Cloud. I renamed it Onion Cloud as per a Tor Cloud suggestion. It's built upon Ubuntu 16.04.1 LTS (Xenial Xerus). I might add support for Ubuntu 14.04.5 LTS (Trusty Tahr) but in the meantime I'm concentrating upon supporting Ubuntu 16.04.1 LTS (Xenial Xerus). I prioritized reducing the amount of needless unsecured communication aside from inheriting all the properties of the original and ensuring that it's up-to-date. I added support to the Amazon Machine Images (AMI) for HTTP Secure protocol-supporting repositories because the repositories Canonical maintains don't support it. I hope Canonical adds support to its repositories in due time. Tor Cloud didn't support HTTP Secure protocol-supporting repositories but I feel it's crucial to add explicit support for it and adopt a defense-in-depth attitude in addition to reliance upon GnuPG detached digital signatures. I'm updating the default GnuPG configuration to add Transport Layer Security support. I plan to add support for Microsoft Azure and Google Compute Engine. Microsoft Azure has a command-line interface that I can use to add support for it as does Google Compute Engine. I'm afraid the cost of Microsoft Azure or Google Compute Engine is outright prohibiting being able to add support at this time. I also bought a domain name and set up 3 Domain Name Servers for it. It supports Internet Protocol version 4 and Internet Protocol version 6 and its Domain Name Server zone is also signed using Domain Name System Security Extensions. I'm still in the process of debugging and updating the original shell scripts and I'd like to be certain that it's robust. I'm intending to publish the shell scripts on GitHub in a fortnight but I'm hoping I can publish it before long. I'm eager to begin encouraging contributors to help refine it! - -- Scott Ainslie <scott(a)scottainslie.me.uk> -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYbOJOAAoJEM18vpeSzTzCHUEP/12tjHqbAF2SYSKrtk/c7B0f BvvXuOn7ZDSbC48RHiKar8PsGTtbk8ofjSSi85sZhkJY0CgIjC6G31Hh5YUOM+EI GyKt2FBtPcbO6n3aJLKLB2nXHm3kxkXShFNhyz3TNDYre5jrHRUNmxTeRh+yDcQm +t3xacR2BOfeblS3SzFjXPGyoSeuW7n+LiOwjm7g50if2Vb8eqV2TzfzA5Q721Jc m+0Yg7GuXLrye70wAIYMdEFvvpeacQkGSamYNpF6gCVe/zkfsXxJBxWeMW9Vp2G7 C0W1FKtol/HXpw7SdFirM8/54D8ZUXoDLlLHYFYZ32iOslVXugE/BRePb4Yw7jAZ eMsHr7jxPVid6iK5Ez+YSw3uDaubYjri/3WEmUaO4/QzztW5LmEuF1XcIRFriN3G mZZ4HQ09+IZC6qtIcB3R+8s+1lHHZzKjgAueu1yeCd4evs9Ski+MgDdogFppi9Yh EeevgIv5XSwdez/C0r25G8Repm2AkTstTBaF5/Lc5rEFYb4CEQEICXFCMYZbk78d IV6zAF31sCtbYvSCWz+0RBszimyWoOHPCFIvQ43yYouZvZq3MMjn7RAj0oVhwvcW +lrpaqMCjsm7dnRyqKkYAh4DmSBmFFSQgB4bXA6eZJgApGZodK/IAQlFIcB/k2hb SqCvYuSMGDW61ZiRnCK9 =MJdn -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Speed up of reconnections after IP Address change
by balbea16 03 Jan '17

03 Jan '17

'tor service start' disconnects all connections, START uses the new IP address. Which is important. I am not sure if Sighup does the same. I assume it only reloads the config file. Any ideas?

1 0

consensus-health
by Felix 03 Jan '17

03 Jan '17

https:// consensus-health.torproject.org/ (observed 2017-01-03 16:00:00 and 2017-01-03 17:00:00) shows * dannenberg: Missing entirely from consensus * faravahar: Missing Signature! Valid-after time of auth's displayed consensus: 2017-01-03 15:00:00 * moria1: Sees only 2620 relays running Is https:// lists.torproject.org/pipermail/tor-consensus-health/2017-January/date.html ok ? -- imho - like always

2 1

Re: [tor-relays] Speed up of reconnections after IP Address change
by balbea16 03 Jan '17

03 Jan '17

Hi ThereI've just written a simple bash script which verifies (in a while loop) every 2 minutes if the OR address has been changed by my ISP. If so, it stops and then restarts the Tor service again. Then it sleeps for 24 hours and starts the 2 minute loop again. Not very sophisticated, but it might work. Mike

2 1

how to generate relay keys manually (before actually running the relay)
by nusenu 03 Jan '17

03 Jan '17

>> Tipp: If you are planing to grow beyond your 31 relays I recommend >> you preemptively generate the keys for your upcoming relays so you >> don't have to touch all other relays everytime you add a single >> relay (to the MyFamily line). > How do you pregenerate keys? Id be interested as Im spinning up > quite a few soon create a folder per tor instance: mkdir future-relay1 future-relay2 ... then invoke tor manually (this will just generate keys and exit after that): tor --PublishServerDescriptor 0 --orport auto --list-fingerprint --datadirectory future-relay1 --Log "err stdout" tor --PublishServerDescriptor 0 --orport auto --list-fingerprint --datadirectory future-relay2 --Log "err stdout" ... In these folders you will then find the fingerprint that you can use in MyFamily, so you don't have to touch your existing relays anymore once you actually use these generated keys on new relays. Make sure you take care of filesystem permissions when using these keys on the actual relay.

2 1

Container tor relay
by Sec INT 03 Jan '17

03 Jan '17

Had a search but cant find much info on running tor relays in containers specifically by proxmox lxc containers - I have a free server atm but dont really want to spinup a load of vms when I could do containers instead - its a load test for me but would mean quite a few relays running with gbps network card (all their own ip's) Anyone tried this yet? Cheers Mark B Snaptor.co.uk (non commercial)

1 0

what to expect with baby exitnodes?
by stinkyonion＠sigaint.org 03 Jan '17

03 Jan '17

well the subject sums it up really I couldn't find a solid explanation. I believe it was ARMA that explained the life cycle of a relay, so I'm curious does this apply for exit nodes? thanks for the clarification

2 1