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?
So, yeah. OONI indicates that Tor is likely blocked 
AS48716, работают только недефолтные мосты, причём у них это давно, блокируют хендшейк + встроенные мосты (как минимум)
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:
- Probing default obfs4 bridges in 2016–2017. At that time, it was possible to make a TCP connection to the bridges, but it was not possible to bootstrap a full obfs4 connection.
- OONI censorship wiki on KZ from 2016–2017, documents the above bridge blocking, also HTTP blocking.
Here are some things you can try:
- Get a bridge from Moat. In the Tor Browser settings, click “Request a bridge…” and solve a captcha to get a non-default obfs4 bridge that may not be blocked.
- Send an email to bridges@torproject.org from a gmail.com address.
- With Tor Browser 10.5, you can try Snowflake, which is a newer pluggable transport.
Snowflake moving to stable in Tor Browser 10.5 | The Tor Project
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.
- The Tor Project / Anti-censorship / emma · GitLab
- GitHub - NullHypothesis/emma (if the other link is blocked)
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
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.
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.
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).
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
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.
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…
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).