- tor-relays - lists.torproject.org

Tor 2.6.10 fails to generate fresh DH Keys
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

>Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. > Looks like you have DynamicDHGroups enabled in your torrc file. This is interesting because the recent LogJam research indicates the NSA has probably broken commonly used 1024 bit DH groups, which suggests turning on this parameter. However it was disabled by default some time ago for anti-fingerprinting reasons: https://trac.torproject.org/projects/tor/ticket/5598 AND, it's probably a moot issue now that Ntor handshakes (elliptic curve) have overtaken older RSA connections. So you should delete DynamicDHGroups 1 from torrc and let it be disabled by default.

3 3

Tor 2.6.10 fails to generate fresh DH Keys
by cyb3rwr3ck 01 Aug '15

01 Aug '15

Hi there, after a unsuspected reboot of wr3ck3d0ni0n01 I decided to refresh all the keys. I took the chance to upgrade to 2.6.10 (Debian) and recognized that the relay wont start afterwards. It looks like it is unable to generate the new krypto: Aug 01 11:56:01.000 [notice] Tor 0.2.6.10 (git-71459b2fe953a1c0) opening log file. Aug 01 11:56:01.000 [notice] Generating fresh dynamic DH modulus. This might take a while... Aug 01 11:56:01.000 [err] tor_assertion_failed_(): Bug: ../src/common/crypto.c:1788: crypto_generate_dynamic_dh_modulus: Assertion r == 0 failed; aborting. Aug 01 11:56:01.000 [err] Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. Stack trace: Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x7f892b3b3601] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x9f) [0x7f892b3c0def] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(crypto_set_tls_dh_prime+0x7db) [0x7f892b3cfb1b] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(set_options+0x1ce5) [0x7f892b35ee25] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_string+0x2d3) [0x7f892b35f503] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_torrc+0x1ca) [0x7f892b35f81a] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_init+0x2e2) [0x7f892b2d1202] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_main+0x55) [0x7f892b2d23a5] Aug 01 11:56:01.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f8929bc2ead] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(+0x362ad) [0x7f892b2cd2ad] I wasn’t able to find any known bugs regarding this behaviour. Anyone out there who has seen this before? Best regards! Felix

1 0

Re: [tor-relays] what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Ended up reading rephist.c for awhile. Seems the up/down time is accumulated with downtime discounted %5 every 12 hours. So absolute worst-case age-out for 100% downtime would be something like .95 ^ 76 (35.5 days) to get down it to 2%. Since the outage is not as bad as that, the guard flag should show up sooner. Not interested enough to calculated the exact answer. Will just watch it.

1 0

what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Does anyone know how long it takes for the guard flag to come back after a multi-day relay downtime? Know that WTU (weighted time up) is 98%, and new-relay TK (time known) minimum is eight days. Reading rephist.c the the WTU is calculated from uptime history but rather then spend awhile to fully understand it seemed worth asking. Presently watching a relay that has been around six weeks, has been down four days recently and five total, has 14-day 100% uptime, Globe- calculated 1-month uptime of 85% and 3-month uptime of 90%. Had guard a couple of times but has not seen it return after the last outage.

1 0

my provider null routed my exit. advice?
by Christopher Yeager 31 Jul '15

31 Jul '15

Hello, I run a 100mb exit hosted at server.lu since sometime in late 2013. There have been a couple dozen abuse reports but normally they forward them to me to deal with and nothing much happens. However a week or so ago, while I was travelling, there was an abuse report that made them decide to file a ticket which then led to them suspending my IP as I 'ignored' it while I was gone. So now I'm trying to convince them to turn the system back on and they are pushing back, and after some back and forth they say they want me to run an exit policy consisting of ports 53, 80, and 443. I've been running the suggested reduced exit policy since day one and am very reluctant to pare it down further, and certainly not to just 3 ports. I wrote a short note explaining my point of view and I wonder if any of you would do me the courtesy of telling me if I am likely to convince them to let me leave the exit policy alone. I'm very willing to edit my response as required. I think it bears mentioning that I am several messages in and I did not get a good sense that whoever I am talking to understands Tor very well at all - I was repeatedly asked to find and block my customer, and told I must have logs if I provide a service, etc. I can show you the longer exchange if you think it might be helpful. Thanks in advance and here goes: --- Hello, We have nothing against Tor but IP is listed at 11 blacklists including Spamhaus ZEN. So we have to ask you block all ports except 80, 53 and 443 to prevent scan, spam and other infringing activity from your IP. Hope such proposal will be suitable for you. Regards, ROOT S.A. --- Hello again, I would rather not block any more ports that are already blocked. The system is already set up to use the reduced exit policy detailed at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy which allows as many Internet services as possible while still blocking the majority of TCP ports. Currently, the policy allows approximately 65 ports. I am reluctant to further reduce the ports because there is vastly more to the internet than just the world wide web. Email, chat, remote desktop, cache, and vpn services are all valid uses of the network that would not be allowed by such a restrictive exit policy. I'm also afraid that it will not help much in getting this IP off the various blocklists that it is on, as 2/3rds of the abuse reports I've been sent were due to traffic on ports 80 or 443. Several of the lists such as SECTOOR and Dans TOREXIT and related are simply reporting to the world that this system is a Tor node. The system is only in the Spamhaus Zen list due to its listing in the CBL for being "infected with, or is NATting for a machine infected with s_vawtrak" which is a Microsoft Windows virus that connected to their sinkhole IP on port 80. Being on blocklists is something that happens when you are running a Tor exit node and supporting Tor means putting up with them and explaining why Tor is worth supporting even though abuse is guaranteed to happen. Naturally if you require this change I will be forced to make it. I hope, however, that you can be persuaded that it is not helpful to Tor and will not solve the problem of abuse and blacklists even if it were. Thanks again. -- Thanks for getting this far. I await your replies with interest. :)

3 2

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Welcome. This event led to my discovering the Unmeasured=1 flag in the cached-*consensus files (was wondering where it was). That new BWauth is badly needed. See about 460 unmeasured relays and from an unscientific sample it seems like many of them are stuck-at-20 exit nodes--valuable resources that should be utilized. At 15:17 7/30/2015 -0500, you wrote: >On 30 July 2015 at 12:14, Tom Ritter <tom(a)ritter.vg> wrote: >> Thanks for the heads up! >> >> A fifth bwauth is expected to start >> voting "real soon now", and I'm >> not sure why maatuska didn't vote >> on bwauth data last vote, but I've >> pinged some folks so hopefully we >> can get this resolved quickly. > >Aaaand we're back! =) Sorry for the outage. > >Bandwidth scanner status > >maatuska 6890 Measured values in w lines >gabelmoo 6444 Measured values in w lines >moria1 6754 Measured values in w lines > >-tom

1 0

Re: [tor-relays] BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 30 Jul '15

30 Jul '15

Much of Tor traffic is from long-term circuits moving bulk data, so apparently it will take many hours or even days for rebalancing to fully take effect. Is not clear whether it will cause serious trouble or not. My thought is that one BWauth in a consensus is better than self-measure, as BWauths are trusted entities and a single rouge BWauth in some kind of attack taking out the rest would be dealt with via manual intervention or the closing down of Tor. Perhaps the self-measure cap of 10k should be raised as well. Was an anti-gaming mitigation from the pre- BWauth days and may have even preceded the arrival of super-fast relays. At 12:14 7/30/2015 -0500, you wrote: >Thanks for the heads up! > >A fifth bwauth is expected to start voting "real >soon now", and I'm not sure why maatuska didn't >vote on bwauth data last vote, but I've pinged >some folks so hopefully we can get this resolved >quickly. > >-tom > >On 30 July 2015 at 12:04, <starlight.2015q2(a)binnacle.cx> wrote: >> FYI list >> >> https://trac.torproject.org/projects/tor/ticket/16696 >> >> Description >> >> At present both 'longclaw' and 'maatuska' have >> dropped out of the BW consensus ('longclaw' >> is restarting with new version, not sure >> about 'maatuska'). >> >> This has caused the BW consensus logic to revert >> to using relay self-measurement for BW weightings >> due to fewer than three BW authorities participating. >> >> The 10000 cap placed on self-measure values >> is causing super-fast relays serious demotion >> and slower relays corresponding promotion >> in the consensus weighting. >> >> Possibly this may result in network >> unbalance issues. Some adjustment >> of the logic seems in order. >>

1 0

Giving away some "pre-warmed" relay keys for adoption
by Roman Mamedov 29 Jul '15

29 Jul '15

Hello, If anyone is planning to spin up a new VM or dedi to run a Tor relay and want it to be put instantly into good use (without wasting couple of weeks to a month for the whole "unmeasured relay/measured/guard/stable" cycle to complete) or if you are having trouble with your current relay being measured properly, in a few days I'm considering to give away several fingerprints+keys from my relays that I will be shutting down. If you install Tor on a new machine and unpack one of these into your /var/lib/tor, it starts up something like this (see below); i.e. in a couple of hours to a full 100% utilization. eth0 16:59 ^ t | t t rt rt rt rt | rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt | rt rt rt rt rt rt rt rt rt rt rt -+---------------------------------------------------------------------------> | 17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) h rx (KiB) tx (KiB) 17 0 0 01 0 0 09 34135840 34964598 18 0 0 02 0 0 10 37991652 38890814 19 0 0 03 0 0 11 38710878 39749495 20 0 0 04 0 0 12 39168357 40164982 21 0 0 05 50433 1472 13 42351426 43626118 22 0 0 06 10904079 10927593 14 42826283 43928095 23 0 0 07 15691530 15839439 15 41240931 42507372 00 0 0 08 27079433 27403035 16 41941981 43139517 Drop me an E-Mail if you want one of these (probably about 2-3 available for now). -- With respect, Roman

8 14

Re: [tor-relays] pinning relay keys to IPs (or not)
by starlight.2015q2＠binnacle.cx 29 Jul '15

29 Jul '15

>(where a lot of IPs changed their AS from >IANA to Digital Ocean) A couple of minor notes regarding ASNs: 1) many IPs fall under a hierarchy of ASs where a large core-network provider (e.g. Level3) advertises a block and a second client leaf-AS advertises a sub- block. Sometimes the core AS advertises the smaller blocks though that has diminished with the CIDR route consolidation initiative. Also some ASs advertise bocks and sub-blocks. This shows up often with the CYMRU lookup data dig +short D.C.B.A.origin.asn.cymru.com txt and DNS will rotate the multiple advertisements, so one should sort the list by CIDR size and select the smallest block (i.e. largest CIDR "/" value). Possibly MaxMind takes care of all this in their data. 2) one can likely ignore AS changes when the IP has not changed, thus avoiding problems caused by network restructuring 3) perhaps many dynamic allocations where the IP changes to different AS can be detected by examining the AS owner identifiers and looking for a match I agree guards are special and perhaps should not be allowed to change ASs at all without loosing the flag, maybe even should stay glued to one IP to avoid any failed client connections and the negative impact that may have on anonymity. It seems reasonable to allow dynamic-IP middle and exit relays.

2 2

pinning relay keys to IPs (or not)
by nusenu 29 Jul '15

29 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [split from 'Giving away some "pre-warmed" relay keys for adoption'] > I'm of the opinion that it may be worth adding code to pin relay > identities to IP addresses on the DirAuth side so that consensus > weight and flag assignment gets totally reset if the ORPort IP > changes, but if there's too much churn already it may cause more > trouble than it's worth. I hope such code will not be added, because it renders relays on dynamic IPs basically useless. In the past ~week only there were >1000 fingerprints (<3% cw fraction) using more than one IP address (in that timeframe) > I'm somewhat torn on the whole key pinning thing, because I think > an individual operator moving their relay around is sort of ok > (though in an ideal world the consensus weight should get reset and > rapidly re-measured), but giving away the private component of a > relay's identity key is putting users at risk, and is behavior that > should be discouraged if not outright prohibited if possible (and > key pinning would be a heavy handed way to rule out this sort of > stupidity). -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVtOqsAAoJEFv7XvVCELh0N2oQAJYXVGM0hHJzBl3i7tkfZx8E hEd9PgyX0v+nXnlAU06lsFltK12VaCkXp9Gft8TlmshP6NqsdHk+KPrtumUE7IA4 MmYmmVi5Tb8AyN241nr/RbYOUS+9nz2VvtkhaikkvbFxwzua678I13P1PC/QPki3 S4KwQ0YYYlUrG529GhLaGkm5byX3N+MAdGQn04xzCDzBW/j3GxbZYBj4+tqgHONR 9iAs5/p00MFVGp3Ex8xJKBVRW0NRT//fKRrZtRDBaNxduUg7F0EccO4zlPjTUBAM e+g8tergT4ICixddhRih0iGA3ysw3/mI1KyvOMegZXkUQ0Yo+puR4O7S2w4WoWRh 1tkkbcFWAh4sCKDPLlD/sqWKFDkHLtP3AOG+KGgybkhULNU1GgAftV39QVrsABx/ oP/dhC9d+MablSZg6qS8dxTV3L+E5EdE2RX226+BPjRkUSqphojEYjDpiaR3/COU 2BmACmPIuiS60DfaiqygKQaCwvgDl6q96o5oZEmPHem2SIxh5o3DD1wLJgKKEsiL WgmoRHTLfqc2Uq0442oi7KMhgGcIffS8xKbb1xw/9yIF2WiKrluFFWau5k6cQYA2 0buDAz7WWi7kxUCnn39NcyrtWoOWMziRH+rjv5esoRN7W5k2GNtBcylZ6kyzcudr hy7j6rYMLpUHsVc2NHKd =8W7p -----END PGP SIGNATURE-----

5 9