- tor-relays - lists.torproject.org

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

>BWauths are continuously pairing relays for >measurements, and perhaps metrics from that >could be mapped to autonomous system numbers . . .scratch AS, geo-location is better and MaxMind specializes in that Pinging a FiOS relay in LA takes 75ms while a close-by relay takes 8ms. Both are in AS 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 22:17:54 UTC 2015 by Mike Perry mikeperry at torproject dot org > >In some instances where I have not selected >my guards manually, Tor Browser is unbearably >slow. Like really, really painfully slow. >The whole time. Until I reinstall it. > >This makes me think that the performance of >people who pick guards from the tail is much >much worse than the performance of the top >guards, and this property likely is acting as >a deterrent to adoption. > Perhaps the guard-selection algorithm could be enhanced to consider some sort of distance/reachability metric generated by BWauths? BWauths are continuously pairing relays for measurements, and perhaps metrics from that could be mapped to autonomous system numbers (from MaxMind) in a useful way without requiring tremendous effort? Matrix analysis comes to mind. If one's guard is on the other side of the world, network latency and random congestion will hurt. I've read some path selection research is under way with an eye toward reducing passive traffic correlation exposure--this seems like it would help performance in a similar way.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Many under-utilized and never-utilized exits relays back online with BWauth outage. Unscientific sample out of 234 previously Unmeasured=1 exit relays, but almost all of the ones checked are like these https://atlas.torproject.org/#details/0D7739DEF50470356744440435FED9E1F57EF… https://atlas.torproject.org/#details/1E014CF541F32F377A116E78B76A603B8346A… https://atlas.torproject.org/#details/2316E6F012ACA52FDB09C745B0F5B41E78C23… https://atlas.torproject.org/#details/2A63402166192D66018D3FCB1ED8DE740CE71… https://atlas.torproject.org/#details/37C49200E04C8FE70799430718B10CEA5DBFB… https://atlas.torproject.org/#details/47BDCB56A9CCDAAAA71D74549E388C8EA1265…

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Poking around Blutmagie, I suspect the number of relays with chopped bandwidth weightings might be more like in the range of 25-45. Perhaps the PID-controller algorithm should be adjusted to bias somewhat less toward super-fast relays.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 20:16:17 UTC 2015 by Jannis Wiese mail at janniswiese.com >Strange thing: My relay [0] is speeding up since then >significantly (finally!!) That's because with no BWauth quorum the consensus algorithm reverts to using self-measured bandwidth with a ceiling of 10000. This causes the weight super-fast relays to drop substantially and provides a corresponding boost to middle and slower relays. Also puts most of the 450 Unmeasured=1 relays back in the game. In addition, this state eliminates all the crazy-stupid-buggy behavior of the BWauths that has been vexing operators so much. Only losers are the folks with huge bandwidth + CPU + tweaking in their relays, but the drop is not all that terrible. I've been watching this for two-plus days now and the Tor network rather runs better this way. Looks like no more than 50-100 relays are in the category where the weight is cut substantially, and plenty of unused capacity exists in the other 3000 or useable relays to make up the difference. Unfortunately the BWauths will likely be back due to the problem of adversarial gaming of the self-measure values. Even with a cap of 10000 someone will figure out ways to abuse the old pre-2009 approach of balancing the network. One can only hope that enough of the bugs have been worked out that BWauths will be behaving better going forward.

1 0

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q2＠binnacle.cx 04 Aug '15

04 Aug '15

FYI list https: // torstatus DOT blutmagie DOT de is registering relays running 0.2.7.2 as having zero bandwidth. I believe this is because the write-history read-history lines in extra-info have moved from the top down to the middle of the document. Many super-fast relays running 0.2.7.2 are showing zero bandwidth and have dropped to the bottom of the ranking as a result. Might be a bug in 'metrics-db' or it might be a bug in a Blutmagie customization. Seems that the code at https://gitweb.torproject.org/torstatus.git/ retrieves advertised (self-measure) bandwidth rather than consumed bandwidth, so it's hard to say without a deep-dive into the code. I'm going by the fact that the new https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc shows advertised bandwidth and presumably runs code from the GIT repository. Sent an e-mail to Olaf Selke advising him of this issue. Not sure if he still maintains it, but the message did not bounce.

3 5

Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
by torrry＠Safe-mail.net 03 Aug '15

03 Aug '15

> debugging the old Blutmagie Perl scripts I found all routers like > splitDNA running Tor 0.2.7.2 sending two hash values in the > extra-info-digest. I suppose this isn't expected by the script parsing > the data. > > GETINFO desc/name/splitDNA > 250+desc/name/splitDNA= > router splitDNA 62.210.82.44 21 0 143 > [...] > extra-info-digest D6F7A98078BDA327D388D918EBA92D0FC9EDC487 > nMA7WhPSpQmquUdYpwIdQtdcKvTAcvNDnXleiPBia0U It shouldn't be expected by the script: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt ------------------------------------------------------------------ "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) ------------------------------------------------------------------- Fetching descriptors via: http://<DIR_SERVER>/tor/server/all has 2 values for extra-info-digest as well.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >I wonder if you could just run sslyze (or another >TLS scanning tool) on the OR ports of all the >relays, and see what ciphersuites they accept. The info would be indicative, but it would not reflect client-only Tor, which represents the majority of installations. Is why I think collecting connection statistics a good idea.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

Of course! This is implicit in my posting. What I am saying is that, like old v1/v2 handshakes, Tor should be moving in the direction of eliminating DHE. The way to approach that is to *count* the number of DHE handshakes and other TLS session attributes. This is currently begin done for TOR/NTOR handshakes but is not for TLS negotiations. 0.2.7 will not build/run with openssl 0.9.8, so once 0.2.7 is widely deployed DHE can be forcibly disabled. BUT, as with v1/v2 handshakes, one would not want to do that prematurely so counting them is a good idea. That suggesting is the principle idea of the thread. At 20:01 8/2/2015 +0300, you wrote: >I think that is to maintain a backward >compatibility. Tor tries as hard as possible to >maintain backward compatibility with older >versions, unless something critical which requires >deprecation regardless some relays will disappear >from the consensus. > >I guess this is the reason we currently prefer >ECDHE but do not reject DHE. In the future, when >we are certain everyone upgraded to new enough >OpenSSL, we can safely reject DHE all the time. >

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >It also may not tell you their ordering >preference (but it might! again, >you'd have to look at the code.) That "openssl s_client" test I ran was against my 0.2.6.10 with openssl 1.0.2 relay. It's certain that ECDHE is preferred over DHE, but my thought is that, especially with 0.2.7 dropping openssl 0.9.8 (no ECDHE), that relays should refuse to accept DHE connections entirely. We've seen many downgrade attacks and who knows for certain if none remain buried in the openssl? Seems prudent to kill-off DHE.

2 1