#1

Unusual behavior of initializing process. Stucking on
[NOTICE] Bootstrapped 5% (conn): Connecting to a relay
[NOTICE] Bootstrapped 10% (conn_done): Connected to a relay
Also some issues with connecting to bridges(obfs4, and meek-azure), just stucking on this step.
This have observed on different devices, and networks. Such as Kazakhtelecom(AS9198) and Tele2(AS48503), on different Tor clients(Tor browser(10.5.2 Linux), Tor browser(10.0.18 Android), Orbot(with Tor v0.4.4.6-openssl1.1.1g). All of them have similar issues with connections.
P.S How i can make more reliable and trusty probes?

#2

image
image1039×73 6.16 KB

Taken from OONI

#3

So, yeah. OONI indicates that Tor is likely blocked :frowning:

#4

AS48716, работают только недефолтные мосты, причём у них это давно, блокируют хендшейк + встроенные мосты (как минимум)

#5

Thanks for this report.

Is this Tor blocking something new, i.e. Tor worked for you before, and today it does not work? Or, did you try Tor for the first time today?

My understanding is that plain Tor, and the default obfs4 bridges, have been blocked in Kazakhstan for several years. You need a private obfs4 bridge, or meek, or these days Snowflake may also work. Here is some documentation on Tor blocking in Kazakhstan I am aware of:

Here are some things you can try:

The Tor anti-censorship team has a tool called emma that tests default bridges, Tor directory authorities, web sites, and relays. If you can compile a Go program, you can run emma to get a report about Tor blocking on your network.

#6

BTW here are graphs of Tor user counts from KZ over the past few years. It looks like nothing has changed recently. The number of obfs4 users is small and decreasing, while the number of non-bridge users is small but slowly increasing. (I don’t have a good explanation for the latter observation.) Unfortunately the graphs do not distinguish default and non-default obfs4 bridges.

If you happen to know an explanation for any of the sudden jumps in the graphs, let me know and I can add the information to the Tor Metrics Timeline.

https://people.torproject.org/~dcf/metrics-country.html?start=2016-01-01&end=2021-07-30&country=kz

userstats-relay-country-kz-2016-01-01-2021-07-30-off

userstats-bridge-country-kz-2016-01-01-2021-07-30

userstats-bridge-combined-kz-2016-01-01-2021-07-30

#7

It’s something new, i had used Tor without bridges everyday, without any issues with bootstrapping. Except using Snowflake bridge, it didn’t work.

Sure, i can.

#8

Increased popularity of Tor from second half 2017 to 2019 might be explained by regular blocking services such as Telegram, Facebook, Instagram, Youtube, usually it was blocks from 20:00 to 23:00. I can’t tell exactly period of time, when it’s started, and when it stopped, this topic didn’t have covered well in local newspapers, but you can try figure out it with social media(oh there was many memes about this).
I can’t see clearly from graph, but some peaks maybe correlated with shutdowns and massive blocking of internet. In 2019 when was inauguration process, in Astana many websites, social media, simply didn’t work.
But graph after 2019 looks so weird. Zero thoughts about explanation.

#9

Hmm, how about peak in 2018? Probably, government tried get all bridge addresses, and after that just block them. It might explain gap after peak. Also, directly connected graph didn’t have any peaks or increases in the same time(except peak at gap, all users just started using vanilla tor).

#10

emma’s output:

Testing default bridges:
  ✓ 38.229.1.78:80                       233ms
  ✓ 38.229.33.83:80                      211ms
  ✗ 192.95.36.142:443                    198ms  error: dial tcp 192.95.36.142:443: connect: connection refused
  ✓ 37.218.245.14:38224                  114ms
  ✓ 85.31.186.98:443                     119ms
  ✓ 85.31.186.26:443                     122ms
  ✓ 144.217.20.138:80                    196ms
  ✓ 193.11.166.194:27015                 123ms
  ✓ 193.11.166.194:27020                 113ms
  ✓ 193.11.166.194:27025                 110ms
  ✓ 209.148.46.65:443                    245ms
  ✓ 146.57.248.225:22                    219ms
  ✓ 45.145.95.6:27015                    128ms
  ✗ [2a0c:4d80:42:702::1]:27015            2ms  error: dial tcp [2a0c:4d80:42:702::1]:27015: connect: network is unreachable
  ✓ 51.222.13.177:80                     204ms
Testing websites:
  ✓ torproject.org                       1.33s
  ✗ archive.org                         30.019s  error: Get "https://archive.org/details/@gettor": dial tcp 207.241.224.2:443: i/o timeout
  ✓ accounts.google.com                  577ms
  ✓ gitlab.com                           628ms
  ✓ mail.riseup.net                      1.08s
  ✓ bridges.torproject.org               483ms
  ✓ gettor.torproject.org                544ms
  ✓ ajax.aspnetcdn.com                  3.137s
  ✓ drive.google.com                     1.15s
  ✓ github.com                           815ms
Testing directory authorities:
  ✓ 128.31.0.39:9131                     211ms
  ✗ [2001:858:2:2:aabb:0:563b:1526]:443    2ms  error: dial tcp [2001:858:2:2:aabb:0:563b:1526]:443: connect: network is unreachable
  ✓ 86.59.21.38:80                       135ms
  ✓ 45.66.33.45:80                       129ms
  ✓ 66.111.2.131:9030                    216ms
  ✗ [2001:638:a000:4140::ffff:189]:443     2ms  error: dial tcp [2001:638:a000:4140::ffff:189]:443: connect: network is unreachable
  ✓ 131.188.40.189:80                    129ms
  ✗ [2001:678:558:1000::244]:443           2ms  error: dial tcp [2001:678:558:1000::244]:443: connect: network is unreachable
  ✓ 193.23.244.244:80                    110ms
  ✗ [2001:67c:289c::9]:80                  2ms  error: dial tcp [2001:67c:289c::9]:80: connect: network is unreachable
  ✓ 171.25.193.9:443                      94ms
  ✓ 154.35.175.225:80                    231ms
  ✓ 199.58.81.140:80                     187ms
  ✗ [2620:13:4000:6000::1000:118]:443      2ms  error: dial tcp [2620:13:4000:6000::1000:118]:443: connect: network is unreachable
  ✓ 204.13.164.118:80                    280ms
Testing relays:
  ✓ 193.11.166.196:443                   121ms
  ✓ 81.7.18.7:9001                       135ms
  ✓ 31.31.73.222:9002                    133ms
  ✓ 162.247.74.7:443                     185ms
  ✗ 62.102.148.68:443                   10.002s  error: dial tcp 62.102.148.68:443: i/o timeout
  ✓ 185.220.100.253:9000                 127ms
2021/07/31 11:06:05 Wrote output to: /dev/stdout
#11

Wow, it’s very different from yesterday results.
Yesterday’s Kazakhtelecom results and today’s result from OONI
Yesterday’s Tele2 results and today’s results from OONI
P.S. it is my probes.

#13

Actually, the peak in bridge users in 2018 affected many countries, not only Kazakhstan. The cause is unknown, but there is an entry for it in the timeline. The increase in obfs4 in 2016 was the result of plain Tor being blocked by TLS fingerprint.

start date end date places protocols description links ?
2018-05-23 2018-07-01 bridge Sharp increase in bridge users in many unrelated countries, affecting even the global aggregate. Relay users unaffected. The graphs reach a peak around 2018-06-07 and then begin falling again. An incomplete sampling of affected countries: Bangladesh Chile Indonesia Morocco Venezuela. relay graph bridge graph X
2016-06-01 kz obfs4 Kazakhstan blocks vanilla Tor TLS. Users mostly switch to obfs4. ticket

This is a good thought, but for me the dates do not align. The change in Tor users happens on 2019-04-28, but the inauguration was on 2019-06-12, and I read that the social media blocks started that day.

This is interesting. I hadn’t heard of such “curfew”-style shutdowns in Kazakhstan before. If it’s safe for you to do so, you may want to send any information to the Freedom on the Net maintainers. The list of contributors for 2020 doesn’t name a contributor for Kazakhstan (“researchers wished to remain anonymous”) but it might be possible to contact their general address. The 2020 report for Kazakhstan does mention some shutdowns:

…emergency situations and unauthorized political gatherings were accompanied by localized internet shutdowns…

In February 2020, a local internet shutdown was recorded in the Korday district…

#14

Thank you for running these tests. It’s very valuable. I guess now, we can just watch and see if anything changes. I’ll put this thread on the agenda for this week’s meeting of the Tor anti-censorship team (2021-08-05).