[tor-talk] New release: Tor 0.4.1.2-alpha
There's a new alpha Tor release! Because it's an alpha, you should only run it if you're ready to find more bugs than usual, and report them on trac.torproject.org. The source code is available from https://www.torproject.org/download/tor/ ; if you build Tor from source, why not give it a try? And if you don't build Tor from source, packages should be ready over the coming days, with a Tor Browser alpha release likely some time next week. Here's what's new: Changes in version 0.4.1.2-alpha - 2019-06-06 Tor 0.4.1.2-alpha resolves numerous bugs--some of them from the previous alpha, and some much older. It also contains minor testing improvements, and an improvement to the security of our authenticated SENDME implementation. o Major bugfixes (bridges): - Consider our directory information to have changed when our list of bridges changes. Previously, Tor would not re-compute the status of its directory information when bridges changed, and therefore would not realize that it was no longer able to build circuits. Fixes part of bug 29875. - Do not count previously configured working bridges towards our total of working bridges. Previously, when Tor's list of bridges changed, it would think that the old bridges were still usable, and delay fetching router descriptors for the new ones. Fixes part of bug 29875; bugfix on 0.3.0.1-alpha. o Major bugfixes (flow control, SENDME): - Decrement the stream-level package window after packaging a cell. Previously, it was done inside a log_debug() call, meaning that if debug logs were not enabled, the decrement would never happen, and thus the window would be out of sync with the other end point. Fixes bug 30628; bugfix on 0.4.1.1-alpha. o Major bugfixes (onion service reachability): - Properly clean up the introduction point map and associated state when circuits change purpose from onion service circuits to pathbias, measurement, or other circuit types. This may fix some instances of introduction point failure. Fixes bug 29034; bugfix on 0.3.2.1-alpha. o Minor features (authenticated SENDME): - Ensure that there is enough randomness on every circuit to prevent an attacker from successfully predicting the hashes they will need to include in authenticated SENDME cells. At a random interval, if we have not sent randomness already, we now leave some extra space at the end of a cell that we can fill with random bytes. Closes ticket 26846. o Minor features (continuous integration): - When running coverage builds on Travis, we now set TOR_TEST_RNG_SEED, to avoid RNG-based coverage differences. Part of ticket 28878. o Minor features (maintenance): - Add a new "make autostyle" target that developers can use to apply all automatic Tor style and consistency conversions to the codebase. Closes ticket 30539. o Minor features (testing): - The circuitpadding tests now use a reproducible RNG implementation, so that if a test fails, we can learn why. Part of ticket 28878. - Tor's tests now support an environment variable, TOR_TEST_RNG_SEED, to set the RNG seed for tests that use a reproducible RNG. Part of ticket 28878. - When running tests in coverage mode, take additional care to make our coverage deterministic, so that we can accurately track changes in code coverage. Closes ticket 30519. o Minor bugfixes (configuration, proxies): - Fix a bug that prevented us from supporting SOCKS5 proxies that want authentication along with configured (but unused!) ClientTransportPlugins. Fixes bug 29670; bugfix on 0.2.6.1-alpha. o Minor bugfixes (controller): - POSTDESCRIPTOR requests should work again. Previously, they were broken if a "purpose=" flag was specified. Fixes bug 30580; bugfix on 0.4.1.1-alpha. - Repair the HSFETCH command so that it works again. Previously, it expected a body when it shouldn't have. Fixes bug 30646; bugfix on 0.4.1.1-alpha. o Minor bugfixes (developer tooling): - Fix pre-push hook to allow fixup and squash commits when pushing to non-upstream git remote. Fixes bug 30286; bugfix on 0.4.0.1-alpha. o Minor bugfixes (directory authority): - Move the "bandwidth-file-headers" line in directory authority votes so that it conforms to dir-spec.txt. Fixes bug 30316; bugfix on 0.3.5.1-alpha. o Minor bugfixes (NetBSD): - Fix usage of minherit() on NetBSD and other platforms that define MAP_INHERIT_{ZERO,NONE} instead of INHERIT_{ZERO,NONE}. Fixes bug 30614; bugfix on 0.4.0.2-alpha. Patch from Taylor Campbell. o Minor bugfixes (out-of-memory handler): - When purging the DNS cache because of an out-of-memory condition, try purging just the older entries at first. Previously, we would always purge the whole
Re: [tor-talk] Surge in Users
Take into account that statistics are number of unique user's IPs connected to bridges per day. My cellular provider change my local GPRS IP exactly every hour and my external IP also changed to random value of provider's pool. Each time IP was changed my Tor rebuild 3 new circuits to introduction points of mounted HS. So one mobile app with HS can generate 24*3 connecting events per day. BR, Van. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Surge in Users
no secure TLS or onion connection to the website, first insecurity note. Van Gegel: > Maybe after publication on popular Russian resource Habr: > https://habr.com/ru/post/448856/ > This is Android app for talking over Tor: > http://torfone.org/download/Torfone.apk > http://torfone.org/download/Torfone_Android_howto.pdf > https://github.com/gegel/torfone > https://github.com/gegel/torfone/blob/master/white.pdf > BR, Van Gegel > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Surge in Users
On Tue, 04 Jun 2019 19:14:12 +0300 Van Gegel wrote: > Maybe after publication on popular Russian resource Habr: > https://habr.com/ru/post/448856/ > This is Android app for talking over Tor: > http://torfone.org/download/Torfone.apk > http://torfone.org/download/Torfone_Android_howto.pdf > https://github.com/gegel/torfone > https://github.com/gegel/torfone/blob/master/white.pdf > BR, Van Gegel Cool development, but it is unlikely to be the reason, the Habr article currently has 28k views, and Russia's user count now fluctuates by 150k users, following a strong correlation with workday schedule. https://metrics.torproject.org/userstats-relay-country.html?start=2019-05-01=2019-06-10=ru=points Extra 100 to 150 thousand users during Monday to Friday (May 13-17, 20-24, 27-31), then dropping during weekends. A massive botnet on office PCs? -- With respect, Roman -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Surge in Users
Maybe after publication on popular Russian resource Habr: https://habr.com/ru/post/448856/ This is Android app for talking over Tor: http://torfone.org/download/Torfone.apk http://torfone.org/download/Torfone_Android_howto.pdf https://github.com/gegel/torfone https://github.com/gegel/torfone/blob/master/white.pdf BR, Van Gegel -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor Browser Android 8.5.1 obfs4 Bridges Problem
Dear Tor Volunteers and Engineers, Hope you are fine. You know i had wrote an email about TB Android's built-in bridges and few days later you released new build with new changes. I installed TB 8.5.1 and tried again. I waited for minutes but no luck. Respectfully nothing is changed. I captured two (2) screenshots of TB Android. I attached those and also uploaded. https://share.riseup.net/#XPnjRD_0eeveNMVq_XO9eQ https://share.riseup.net/#87nFB3buzwydBx9MF3kmDQ Thank you in advance. Kind Regards, Lotta -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How long does it take for websites to discover new exit nodes?
> On 19/05/2019 00:38, jiggytwi...@danwin1210.me wrote: > It is likely true that many sites that block Tor do so due to the > detection of a single abuse event. When you have ~2 million "A single abuse event" isn't it. At all. I've been running Tor nodes for decades and I support it for various reasons but I also run quite a few websites and I totally and fully understand Why someone would just want to not deal with the Constant Bombardment of Abuse that is coming from the Tor network. It's not some guy using Tor posing some abusive comment that's causing website owners to just block tor; it's a Constant Stream of Bots doing POST requests & looking for exploits. It's not something you see once or twice every now and then, it's 20+ requests per hour for things like wp-login.php, wp-comments.php, manager/FCKeditor/fckconfig.js, utility/convert/data/config.inc.php, /db.sql, /backupsite.sql and a whole lot of other files used that don't exist which may be used by some exploitable CMS system. A lot of the abusive bots coming from Tor are just stupid, they don't care if you're using WordPress or not, they will just constantly send POST requests anyway. This is obviously not just a Tor exit node problem. And it's possible to deal with it in better ways than using a Tor exit node blacklist. However, I do understand why someone would just say "I'll just ban that Tor thing, from my perspective it's one big abusive botnet" - that's essentially what it is from a pure web hosting providers perspective. That's probably what I'd do if I weren't familiar with Tor. -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk