search

net4people / bbs

Forum for discussing Internet censorship circumvention
3.21k stars 75 forks source link

Shutdowns, intensified blocking in Iran since 2022-09-21 #125

Open wkrp opened 1 year ago

wkrp commented 1 year ago

There are reports of shutdowns in some mobile ISPs in Iran since about 2022-09-21 16:00 UTC (20:30 Tehran IRDT, about 8 hours ago). I don't know much technical detail yet.

IODA doesn't show a major drop in the country as a whole: https://ioda.inetintel.cc.gatech.edu/country/IR?from=1663135200&until=1663826399 IODA Signals for Iran (Islamic Republic Of), 2022-09-14 to 2022-09-22

But you can see an effect in certain ISPs, like IranCell here: https://ioda.inetintel.cc.gatech.edu/asn/44244?from=1663135200&until=1663826399 pngout

It may be a good idea to review #102, lessons from the January 2022 shutdown in Kazakhstan, and for example do some port scans to see if there are holes in the shutdown.

If you experience a shutdown and are able to get online for even a little while, Access Now has a form to report your experience: https://www.accessnow.org/keepiton/#take-action https://forms.gle/pUh6EPwwtkD65BDY6

Some Twitter posts:

https://twitter.com/OliverLinow/status/1572698570498920449 (archive)

Iran Internet Black Out - 21.09.2022

14:00 UTC: Instagram was blocked 15:45 UTC: Mobile internet operators starting to switch off their networks @DeutscheWelle

https://twitter.com/DougMadory/status/1572657304335716353 (archive)

Internet connectivity for Iran's primary mobile operators were cut in recent hours. #IranProtests2022

Traffic volumes for MCI (AS197207) from @kentikinc:

Internet traffic to MCI (AS197207)

https://twitter.com/CloudflareRadar/status/1572662811951771648 (archive)

Amid #IranProtests2022), #Internet disruptions have been observed at major #mobile carriers in #Iran🇮🇷.

@CloudflareRadar data shows significant drops in traffic at AS57218 (Rightel), AS197207 (MCI), and AS44244 (Irancell), as well as at a country level.

https://radar.cloudflare.com/ir?date_filter=last_24_hours

Internet traffic change in Iran (last 24 hours) Internet traffic change AS57218 - RIGHTEL Internet traffic change AS197207 - MCCI-AS Internet traffic change AS44244 - IRANCELL-AS

wkrp commented 1 year ago

There are some simple network tests that can help find any ways through the shutdown that may exist. During the January 2022 shutdown in Kazakhstan, it was discovered that TCP ports 3875 and 179 worked, when all other ports were blocked. You can try testing these ports in a mobile web browser. portquiz.net is a server that responds with a web page on all ports.

Or, if DNS resolution is blocked:

Here is an Nmap command to run to test all TCP ports. It should run in 11 minutes or less. scanme.nmap.org does not have every port open, but the ports that are not open respond with a RST, so it can still be useful to detect blocking.

nmap -v -v -v -n -Pn -p- --reason -oN 'scanme-allports-%D%T.nmap' --min-rate 100 scanme.nmap.org
nmap -v -v -v -n -Pn -p- --reason -oN 'scanme-allports-%D%T.nmap' --min-rate 100 45.33.32.156

It will be good to know about reachability of DNS resolvers, both of foreign resolvers directly and via domestic ISP resolvers.

dig @185.49.141.38 example.com
dig example.com

On Windows, you can try

nslookup example.com 185.49.141.38
nslookup example.com

I got the address of the resolver 185.49.141.38 from https://dnsprivacy.org/test_servers/; you can try any other resolver. In the output, you are looking for status: NOERROR and an A record response of 93.184.216.34 (at least, that's what I see right now).

wkrp commented 1 year ago

The first major shutdown began about 2022-09-21 16:00 UTC (20:30 IRDT) and ended 6 to 12 hours later, depending on the network.

It was followed by another shutdown that started about 2022-09-22 12:00 UTC (15:30 IRDT) and ended about 8 hours later.

https://twitter.com/CloudflareRadar/status/1573067153036787713 (archive)

After a second set of outages spanning between 6-8 hours, connectivity has once again been restored on Iranian network providers Rightel, Irancell, and MCI.

@Cloudflare data shows that traffic returned at 2025 UTC.

https://radar.cloudflare.com/ir?date_filter=last_24_hours

#KeepItOn #IranProtests2022

Netflow Gbps by ASN

IODA links for exploration:

https://ioda.inetintel.cc.gatech.edu/asn/44244?from=1663221600&until=1663912799 https://ioda.inetintel.cc.gatech.edu/asn/57218?from=1663221600&until=1663912799 https://ioda.inetintel.cc.gatech.edu/asn/197207?from=1663221600&until=1663912799

wkrp commented 1 year ago

At approximately the same time as the start of the shutdowns, there was a large increase of bandwidth at the Snowflake, so much so that it threatens to overwhelm the capacity of the bridge. (This is the bridge that has already had significant engineering and hardware upgrades for scaling.) This is a graph of send/recv bandwidth at the network interface over the past 5 days:

bandwidth on network interface

The big crater on 2022-09-22 is where the server was running out of memory and swapping.

We are in the process of making some changes to the server in response to the increased load. We have already doubled the number of tor instances, which relieved some of the CPU pressure. We are also testing some performance optimizations and hope to deploy them tomorrow.

wkrp commented 1 year ago

A third outage occurred starting 2022-09-23 12:15 UTC (15:45 IRDT) and lasted about 8.5 hours.

A fourth outage started at 2022-09-24 14:00 UTC (17:30 IRDT) and is still ongoing.

https://twitter.com/CloudflareRadar/status/1573429947766562830 (archive)

Connectivity was restored to Irancell, Rightel, and MCI in #Iran at 2030 UTC after an 8.5 hour outage, the third one this week.

Analysis of #HTTP & #TLS version usage suggests that selected #UDP blocking may be occurring on some networks as well.

https://radar.cloudflare.com/ir?date_filter=last_24_hours

Netflow Gbps by ASN

https://twitter.com/CloudflareRadar/status/1573689073268580354 (archive)

For the fourth consecutive day, #Internet shutdowns have been observed at Rightel, Irancell, and MCI in #Iran🇮🇷.

@Cloudflare data shows today's outages began around 1400 UTC.

https://radar.cloudflare.com/asn/44244?date_filter=last_7_days https://radar.cloudflare.com/asn/57218?date_filter=last_7_days https://radar.cloudflare.com/asn/197207?date_filter=last_7_days

#KeepItOn #IranProtests2022

Netflow Gbps by ASN

mrphs commented 1 year ago

A friend just ran the nmap and dig test on AS57218. dig times out. and nmap doesn't get a response back from the host.

All 65535 scanned ports on scanme.nmap.org (45.33.32.156) are in ignored states.
Not shown: 65535 filtered tcp ports (no-response)

_PS: I tweeted about this ticket, hoping more technical folks inside the country would see this and run the tests. I will update the thread if I get any more responses._

wkrp commented 1 year ago

My understanding is that people on mobile ISPs are able to access domestic Iranian services even during a shutdown. It would be helpful to know if there are any domestic DNS resolvers that permit recursive queries of foreign domains and are accessible during a shutdown. The idea is to tunnel through an accessible domestic DNS server to reach the outside world during a shutdown.

There are some lists of public DNS servers in Iran:

You can test whether the resolvers permit recursive queries using a command like the following. Ideally, you run the command on a laptop that is tethered to a mobile phone, during a shutdown.

for res in 213.176.123.5 194.225.62.80 185.161.112.33 2.185.239.136; do dig "@$res" example.com; done

If you don't have a tethered laptop, you can do DNS resolver tests from a mobile phone. You just have to change the system DNS setting (instructions for Android, iPhone) and enter one of the resolver IP addresses above. Then open a browser and try to access any foreign web site, like example.com. It won't work, but you can tell from the error message whether DNS resolution worked.

Error message Meaning
Server not found The DNS resolution failed
Connection timed out The DNS resolution worked
Connection refused The DNS resolution worked
wkrp commented 1 year ago

A friend just ran the nmap and dig test on AS57218. dig times out. and nmap doesn't get a response back from the host.

Thanks for this.

scanme.nmap.org (45.33.32.156)

The fact that both a hostname and an IP address are listed implies that either forward or reverse DNS resolution must have worked. I'm not sure if the test used the hostname scanme.nmap.org or the IP address 45.33.32.156, but even if you only give an IP address, Nmap will do a reverse lookup to get a hostname if possible.

You can test reverse resolution using the -x option of dig:

$ dig -x 45.33.32.156
...
;; ANSWER SECTION:
156.32.33.45.in-addr.arpa. 3357 IN      PTR     scanme.nmap.org.

It would be interesting if reverse but not forward DNS worked during a shutdown. I don't know of any tunnels that use PTR queries and PTR records, but it's not impossible: dnscat2 can use constrained types like TXT, MX, CNAME, A, and AAAA. But let's try to get more confirmation about whether forward recursive queries work or not.

mrphs commented 1 year ago

New OONI report is out: https://ooni.org/post/2022-iran-blocks-social-media-mahsa-amini-protests/

A whole lot of things are blocked now. The networks I had access to are all at 0% connectivity based on what CloudFlare Radar is showing 😣

wkrp commented 1 year ago

New OONI report is out: https://ooni.org/post/2022-iran-blocks-social-media-mahsa-amini-protests/

Besides the shutdowns which started this thread, the report covers:

The blocking of DoH resolvers is interesting to me. It should be superfluous to block DNS resolution if endpoints are already blocked. Maybe the censors are going for defense in depth. Maybe encrypted DNS was being used for tunneling. Maybe it exposes a weakness: some services are blocked only by DNS and not by, e.g., TLS SNI filtering, therefore it is required to block secure DNS. Or possibly there's no specific intention behind it, just a setting on some firewall hardware.

gfw-report commented 1 year ago

New blocking of Apple App Store and Google Play Store in some/more ISPs, since 2022-09-22.

the blocking of Google Play Store and Apple App Store may limit Iranians’ ability to install or update apps.

The blocking of the application stores creates a typical chicken-or-egg problem in censorship circumvention. That is, users need a bootstrapping to get access to the application stores so that they can download other circumvention tools. Fortunately, the bootstrapping channel doesn't have to be very robust or censorship-resistant; it can be a low bandwidth, high latency channel that only works temporarily. Some bootstrapping channels include:

For Android, getting users an APK file should be enough for bootstrapping. It can be done by sharing the APK files via some low profile channels, for example hosting an APK on an uncensored website and share users a link to it.

For iOS, users may have to use the Apple App Store to download the software. One may want to take the advantage of iOS's built-in VPN client that supports IKEv2, IPsec, and L2TP protocols:

  1. Settings -> VPN -> Add VPN Configuration... , configure as follows:
Description: Gate
Type: L2TP (Try changing it to IPSec if it doesn't work)
server: 219.100.37.100 (Try different IP addresses if it doesn't work)
Account: vpn
Password: vpn
Secret: vpn

  1. Save the setting by clicking on the "Done" on the upper-right corner.

  2. Select Gate (unkonwn) and click the Status button to turn on the VPN.

  1. On the server, wget https://get.vpnsetup.net -O vpn.sh && sudo sh vpn.sh. Pay attention to the VPN credential information in the script's output.

  2. On your phone, Settings -> VPN -> Add VPN Configuration... , configure as follows:

Description: myvpn
Type: IPsec
server: 
Account: vpnuser
Password: 
Secret:

  1. Save the setting by clicking on the "Done" on the upper-right corner.

  2. Select myvpn (unkonwn) and click the Status button to turn on the VPN.

fortuna commented 1 year ago

I probed all DNS servers from https://public-dns.info/nameserver/ir.html for the IP of example.com at around 6:39 pm UTC, September 28. I believe that's during the curfew. The results below are resolver_ip, resolver_asn dig_response

$ while IFS=, read -r resolver_ip _ resolver_asn _; do echo -n "$resolver_asn $resolver_ip "; dig +short +time=1 +tries=1 @$resolver_ip unique-$RANDOM.example.com && echo NXDOMAIN; done < <(tail +2 ir.csv | sort -g) | sort -g
6736 194.225.73.141 NXDOMAIN
12880 217.218.127.127 NXDOMAIN
15611 213.176.123.5 ;; connection timed out; no servers could be reached
43754 37.156.145.21 ;; connection timed out; no servers could be reached
43754 37.156.145.229 ;; connection timed out; no servers could be reached
43965 194.225.62.80 ;; connection timed out; no servers could be reached
48715 185.51.200.10 ;; connection timed out; no servers could be reached
48715 185.51.200.50 ;; connection timed out; no servers could be reached
49666 2.189.44.44 NXDOMAIN
50057 185.161.112.33 NXDOMAIN
50057 185.161.112.34 NXDOMAIN
56402 46.224.1.42 NXDOMAIN
56402 46.224.1.43 NXDOMAIN
56547 31.24.234.37 NXDOMAIN
58224 80.191.40.41 ;; connection timed out; no servers could be reached
58303 81.163.3.1 ;; connection timed out; no servers could be reached
60627 185.113.59.253 ;; connection timed out; no servers could be reached
60976 82.99.242.155 ;; connection timed out; no servers could be reached
60976 91.99.101.12 ;; connection timed out; no servers could be reached
202468 185.231.182.126 ;; connection timed out; no servers could be reached
202468 185.97.117.187 ;; connection timed out; no servers could be reached
209596 91.245.229.1 ;; connection timed out; no servers could be reached
212907 185.187.84.15 ;; connection timed out; no servers could be reached

The ASes that returned NXDOMAIN are probably able to access external DNS resolvers.

Edit: In my initial test I was reusing the same domain, which could trigger cached results. It's now using a unique domain per query.

fortuna commented 1 year ago

Looking at Cloudflare radar:

ASes not subject to curfew:

https://radar.cloudflare.com/asn/58224

image

https://radar.cloudflare.com/asn/12880

image

https://radar.cloudflare.com/asn/49666

image

https://radar.cloudflare.com/asn/50057

image

AS that was added to the curfew

https://radar.cloudflare.com/asn/56402

image

ASes subject to curfew

https://radar.cloudflare.com/asn/44244

image

https://radar.cloudflare.com/asn/197207

image
abdallahalsalmi commented 1 year ago

Irancell (owned in part by MTN Group) and MCCI, a state-owned entity, account for over 60% of Iranian mobile phone users, if not more. The internet shutdowns are clearly aimed at mobile networks to stop the protestors from mobilising and organising (and sharing information too).

Fardinak commented 1 year ago

Hi there 👋

I found this thread a couple of days ago when a friend of mine sent me @fortuna's tweet. Since then I have been running some tests (including the port scan). The nmap results would be irrelevant since we haven't had a shutdown since I've started testing. But in the past couple of days I've been witnessing some strange behaviour.

I first noticed that my VPN client was not detecting my location properly a couple of days ago. My initial thought was that this is an internal issue (caching my IP from the other VPNs I've been testing). Tonight I realized it's much more than that.

Right now, on an AS58224 (TCI) connection I'm getting the following results:

https://isbgpsafeyet.com
Your ISP (AS58224) does not implement BGP safely.

https://radar.cloudflare.com/my-connection
IP address: 162.55.57.188
Geolocation: Germany
AS: 24940 (Hetzner Online, DE)

https://browserleaks.com (connection timeout)

https://www.dnsleaktest.com
5.200.200.26
5.200.200.50

$ dig +short whoami.akamai.net
;; communications error to 5.200.200.200#53: timed out
5.200.200.50

Note that the Geolocation and AS detected by Cloudflare is not consistent with the other results.

Switching over to AS197207 (MCCI) using an iPhone's hotspot returns the following results:

https://isbgpsafeyet.com
Your ISP (Mobile Communication Company of Iran, AS197207) does not implement BGP safely.

https://radar.cloudflare.com/my-connection
IP address: 65.108.155.56
Geolocation: Helsinki, Finland
AS: 24940 (Hetzner Online, DE)

https://browserleaks.com/ip
County: Iran
Region: Tehran
Network: AS197207
DNS Leak Test: Found 42 Servers, 6 ISP, 4 Locations

https://www.dnsleaktest.com: Extended test
21 results, 5 ISPs, 5 locations

$ dig +short whoami.akamai.net
195.27.183.45

On the iPhone using the Net Analyzer app shows two 10/8 IPs as DNS servers when using MCCI cellular and 5.200.200.200 when using TCI over Wi-Fi.

The DNS Leak tests return a variable number of servers (between 20 to 60) a few of which (2 or 3) are usually the correct one. But based on these, I'm either getting service from Layer 3, Cloudflare, Google, Vodafone or Lumen and am located anywhere from the UK to Japan!

Anyways, thought this might be of interest. I'm also curious to know what you think about this situation. I'll keep an eye out and run the port scan if there is another shutdown.

p.s. all tests were run on a fresh linux VM with a dedicated USB Wireless card and no manual network configuration.

xhdix commented 1 year ago

@Fardinak, it's not your system or even ISP's problem. It's called anti-sanctions service, but in reality, it's just bandwidth throttling service by DCI. Do you remember the GitHub problem 8 months ago? it's the same technique. they reroute and tunnel specific (/32) IPs.

Fardinak commented 1 year ago

Right on schedule. As reported by Cloudflare Radar there is a shutdown in progress on Iranian mobile carriers.

Here is the portscan for AS197207 (MCCI):

# Nmap 7.92 scan initiated Sat Oct  1 15:25:24 2022 as: nmap -v -v -v -n -Pn -p- --reason -oN scanme-allports-MCCI-%D%T.nmap --min-rate 100 scanme.nmap.org
Warning: Hostname scanme.nmap.org resolves to 2 IPs. Using 45.33.32.156.
Increasing send delay for 45.33.32.156 from 0 to 5 due to 11 out of 32 dropped probes since last increase.
Increasing send delay for 45.33.32.156 from 5 to 10 due to 13 out of 43 dropped probes since last increase.
Increasing send delay for 45.33.32.156 from 10 to 20 due to 25 out of 82 dropped probes since last increase.
Increasing send delay for 45.33.32.156 from 160 to 320 due to 11 out of 24 dropped probes since last increase.
Warning: 45.33.32.156 giving up on port because retransmission cap hit (10).
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up, received user-set (0.43s latency).
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Scanned at 2022-10-01 15:25:33 UTC for 1819s
Not shown: 61883 closed tcp ports (conn-refused), 3646 filtered tcp ports (no-response)
PORT      STATE SERVICE    REASON
21/tcp    open  ftp        syn-ack
22/tcp    open  ssh        syn-ack
80/tcp    open  http       syn-ack
1723/tcp  open  pptp       syn-ack
9929/tcp  open  nping-echo syn-ack
31337/tcp open  Elite      syn-ack

Read data files from: /usr/bin/../share/nmap
# Nmap done at Sat Oct  1 15:55:52 2022 -- 1 IP address (1 host up) scanned in 1828.21 seconds

I'm most curious about AS44244 (IRANCELL) since CF Radar doesn't show a complete shutdown on this AS for the past couple of cycles. AS44244-Oct01

Here is the portscan results from AS44244 (IRANCELL):

# Nmap 7.92 scan initiated Sat Oct  1 16:14:14 2022 as: nmap -v -v -v -n -Pn -p- --reason -oN scanme-allports-IRANCELL-%D%T.nmap --min-rate 100 scanme.nmap.org
Warning: Hostname scanme.nmap.org resolves to 2 IPs. Using 45.33.32.156.
Nmap scan report for scanme.nmap.org (45.33.32.156)
Host is up, received user-set.
Other addresses for scanme.nmap.org (not scanned): 2600:3c01::f03c:91ff:fe18:bb2f
Scanned at 2022-10-01 16:14:15 UTC for 1312s
All 65535 scanned ports on scanme.nmap.org (45.33.32.156) are in ignored states.
Not shown: 65535 filtered tcp ports (no-response)

Read data files from: /usr/bin/../share/nmap
# Nmap done at Sat Oct  1 16:36:07 2022 -- 1 IP address (1 host up) scanned in 1312.14 seconds

Definitely not what I expected.

@xhdix wow, I was not aware of these "anti-sanction services"! TBH I've almost never disconnected my VPN during the past five years, specially since the 2019 shutdown. Basically anything I need for my work or life is either censored or sanctioned!

fortuna commented 1 year ago

@Fardinak that's very helpful information. It looks like those 6 ports may be useful for circumvention on MCCI, but it looks like we're out of luck on Irancell.

I wonder if DNS can get out there.

Fardinak commented 1 year ago

I wonder if DNS can get out there.

Any tests you'd like me to run?

I'm about to setup a VPS to try a bunch of protocols over these ports. SSH not being filtered gives me a lot of hope. Please let me know if you have any suggestions.

wkrp commented 1 year ago

Thank you for running these port scans. My interpretation, however, is that the results unfortunately do not reveal anything useful. The MCCI scan shows no clear signs of blocking: all ports except a few were responsive (6 ports returned SYN/ACK, but 61,883 returned RST; i.e., they were not blocked). The Irancell scan looks like total blocking, with no responsive ports; i.e., it's not a case like in Kazakhstan where a few ports were left unblocked.

Here is the portscan for AS197207 (MCCI):

Not shown: 61883 closed tcp ports (conn-refused), 3646 filtered tcp ports (no-response)
PORT      STATE SERVICE    REASON
21/tcp    open  ftp        syn-ack
22/tcp    open  ssh        syn-ack
80/tcp    open  http       syn-ack
1723/tcp  open  pptp       syn-ack
9929/tcp  open  nping-echo syn-ack
31337/tcp open  Elite      syn-ack

The way to interpret this is not only to look at the 6 open ports (they are simply the 6 ports that are open on the server; a port scan from anywhere would find the same open ports), but also the part 61883 closed tcp ports (conn-refused), 3646 filtered tcp ports (no-response). Most of the ports that were not open still returned a response (conn-refused), which means no blocking. While the 3646 ports that did not receive a response could be the result of selective blocking, it is more likely caused by packet loss. The output messages below are signs of packet loss that could result in a port being falsely classified as filtered.

Increasing send delay for 45.33.32.156 from 0 to 5 due to 11 out of 32 dropped probes since last increase. Increasing send delay for 45.33.32.156 from 5 to 10 due to 13 out of 43 dropped probes since last increase. Increasing send delay for 45.33.32.156 from 10 to 20 due to 25 out of 82 dropped probes since last increase. Increasing send delay for 45.33.32.156 from 160 to 320 due to 11 out of 24 dropped probes since last increase. Warning: 45.33.32.156 giving up on port because retransmission cap hit (10).

wkrp commented 1 year ago

Any tests you'd like me to run?

I'm about to setup a VPS to try a bunch of protocols over these ports. SSH not being filtered gives me a lot of hope. Please let me know if you have any suggestions.

@Fardinak I hope to be able to set up a DNS tunnel for testing at least; but I'm also pretty swamped with the Snowflake bridge amid all the new users and other aspects of this blocking event. If you are technically inclined and want to try it yourself, this is the source code and installation instructions: https://www.bamsoftware.com/software/dnstt/

The tunnel was designed to run over encrypted DNS, but during a shutdown you may only be able to access plaintext UDP port 53 DNS resolvers (you can try the likely accessible resolvers from https://github.com/net4people/bbs/issues/125#issuecomment-1261334701). The tunnel can work with a plaintext UDP port 53 resolver (use the -udp option in the client), but you should be aware that this mode of operation is not covert. Anyone watching the wire or looking at a recorded traffic trace will be able to tell that a tunnel was being used and the IP address of the user (though the actual contents of the tunnel will be encrypted). See Caveats and Protocol.

I'm aware of some third-party Android apps that use the dnstt code. I have never used them and I cannot say whether they are safe. This is not an endorsement. But these third-party apps could provide an easy way to test whether a DNS tunnel can work at all. You will need to activate "dnstt" or "slowdns" mode and enter the resolver you want to use. These are the apps I know about:

Fardinak commented 1 year ago

@wkrp thanks for all the info 🙏 Sorry for getting back to you so late. The recent events at SUT and Zahedan have had us all rattled and busy. I haven't had a chance to jump through the hoops of purchasing a VPS from Iran.

I've had many people contact me during the past couple of days for recommendations on circumvention apps and tactics. But the truth is that I'm running low on options myself. Basically nothing works on mobile carriers. I've only succeeded in using multi-hop ss tunnels (using v2ray) and even then there isn't much bandwidth to work with.

I'll keep you posted when I get a chance to test a DNS Tunnel. Cheers ✌️

wkrp commented 1 year ago

I posted information about troubleshooting Snowflake connectivity and alternate bridge lines to try at #131.

wkrp commented 1 year ago

At https://github.com/net4people/bbs/issues/131#issuecomment-1272479644 it was observed that certain DNS names used by Snowflake did not resolve during a time of shutdown on the Irancell network. I do not know whether this is an isolated incident or whether it is typical. I do not know whether only those names failed to resolve, or if any other name also would have failed.

I would like to know whether anyone else has had the problem of certain domain names not resolving. Are you able to resolve the name stun.uls.co.za? What about www.example.com? It may be something that can be worked around by changing the system's DNS server, possibly to one of the domestic recursive resolvers @fortuna found in https://github.com/net4people/bbs/issues/125#issuecomment-1261334701.

wkrp commented 1 year ago

Team CommUNITY has a blog post from October 11 that summarizes the situation and lists resources.

Internet Freedom Tools, Resources & Actions to Support Iran's Feminist Uprising

Tools and Resources to Circumvent Censorship

Paskoocheh.com

Iranian Internet users can check out Paskoocheh (Farsi for “alley way”), a marketplace that enables easy access to circumvention and privacy tools. Paskoocheh currently offers free Mullvad VPN Vouchers.

irandarkhamooshi.net

Filterbaan offers resources in Persian for internet freedom, specifically tools to prepare for internet shutdowns

Tor Project

The Tor website is now available in Farsi. You can also find the Circumventing Censorship with Tor guide in Farsi.

Google Play store is blocked in Iran, but you still can download Tor by using Tor's official Telegram bots/channels (https://t.me/TorProject)

  • @GetTor_Bot to download Tor Browser
  • @GetBridgesBot to get obfs4 bridges
  • @TorProjectSupportBot for help

Snowflake

Tor is asking that folks outside of Iran download and run Snowflake, which will help them better support folks in Iran bypass censorship.

Check out these digital posters with instructions as well as this detailed article by EFF on how to run Snowflake.

Signal

Signal is also asking people outside of Iran to run a proxy, which will help Iranian users reconnect to Signal.

Tunnelbear

Tunnelbear is providing 100GB of free VPN bandwidth monthly for users in Iran.

Proton VPN

Proton stated their support for the user community in Iran.

Download their free VPN here: https://protonvpn.com/support-form and here https://protonvpn.com/free-vpn/

GreatFire's AppMaker

GreatFire Appmaker is a free circumvention tool.

Instructions: You can create your own Android app to access blocked websites without a VPN on your mobile phone.

It's free and easy to use, only takes 1-2 minutes to create an app.

  1. Name your app as you like.
  2. Put an URL address of the website you create as an app in the "Home Page" box
  3. Choose any image you want to use as an app icon to show on your mobile.
  4. Click to create an app.
  5. Download the APK file and install it on your mobile device.
  6. You can share your app with others by simply sending them its QR code image, download page link, or APK file.

Tips:

  1. You can also browse other blocked websites on the app. It works as a circumvention browser without using a VPN.
  2. You can choose any names and logos for your app to disguise it. For instance, you create an app for "www.twitter.com" but name it as "workout" and use an image of "bike".

Latest Censorship Observations from Iran by WEPN

A series of interviews and investigations with help from people in Iran since the start of the current shutdown/filtering phase. The findings are detailed in this Google Doc: https://go.we-pn.com/state22 This document is being updated "live".

Data

Advocacy

wkrp commented 1 year ago

WEPN is maintaining a document of censorship observations from Iran.

https://go.we-pn.com/state22

One of its topics that we have not discussed on this thread yet is speed throttling.

Speed throttling

During the last 10 days (Since Oct 1th), ISPs have been attempting to throttle down upload speed to IP addresses outside of Iran, to less than 0.1MB/sec. This mechanism essentially only allowed text requests to be sent and prevented uploading of video and files. It seems like this method is being pursued as an alternative to completely shutting down international traffic. It’s not clear if this was done as damaged control or some level of internal pushback.

massoudasadi commented 1 year ago

things got worse now only multi-hub ssh tunneling works on mobile carriers

fortuna commented 1 year ago

It seems TLS to DigitalOcean is being blocked on many networks. My probes get a timeout after the TCP connection is established: https://atlas.ripe.net/measurements/46063338/#probes

However, TLS to DO works from AS41620 (IUSTCC-AS - Iran University Of Science and Technology): https://atlas.ripe.net/measurements/46060594/#probes

TLS to Hetzner Finland server seems to work fine from multiple networks: https://atlas.ripe.net/measurements/46063375/#probes

If you want to use TLS for circumvention, try different providers.

Update: Testing the connection to DigitalOcean again with SNI seems to work: https://atlas.ripe.net/measurements/46063772/#probes

On Irancell:

mehdifirefox commented 1 year ago

VPNs completely disabled Only proxy works well

wkrp commented 1 year ago

There's been some progress in diagnosing TLS fingerprint blocking, as a result of investigating Snowflake connectivity problems. There is strong evidence of an attempt to block the native Go crypto/tls fingerprint, but not all native fingerprints produced by Go programs are blocked. There are (so far) two known dimensions that matter:

These 2 binary dimensions (AES-GCM priority / ChaCha20 priority) and (min = TLS 1.0 / min = TLS 1.2) give rise to 4 combinations, and available evidence says that only one of the combinations is blocked:

compiled with go1.17 (min = TLS 1.0) compiled with go1.18+ (min = TLS 1.2)
AES acceleration (desktop) ok ok
no AES acceleration (mobile) blocked ok

The right way to deal with TLS fingerprinting is to use some form of TLS fingerprint camouflage, such as the uTLS package for Go. uTLS has already been added to trojan-go, and Snowflake. But if you are not able to adopt such a measure in the short term, recompiling client programs with go1.18 may buy some time.

free-the-internet commented 1 year ago

@wkrp , thanks for update. Following the timeline of snowflake https://gitlab.torproject.org/tpo/network-health/metrics/timeline#timeline, now we need to use utls-imitate=hellorandomizedalpn insttead of hellochrome_auto for Iran?

I have some news that the following is not working in Iran. But it's just based on one user. snowflake 192.0.2.3:80 2B280B23E1107BB62ABFC40DDCC8824814F80A72 fingerprint=2B280B23E1107BB62ABFC40DDCC8824814F80A72 url=https://snowflake-broker.torproject.net.global.prod.fastly.net/ front=cdn.sstatic.net ice=stun:stun.voip.blackberry.com:3478,stun:stun.altar.com.pl:3478,stun:stun.antisip.com:3478,stun:stun.bluesip.net:3478,stun:stun.dus.net:3478,stun:stun.epygi.com:3478,stun:stun.sonetel.com:3478,stun:stun.sonetel.net:3478,stun:stun.stunprotocol.org:3478,stun:stun.uls.co.za:3478,stun:stun.voipgate.com:3478,stun:stun.voys.nl:3478 utls-imitate=hellorandomizedalpn

wkrp commented 1 year ago

thanks for update. Following the timeline of snowflake https://gitlab.torproject.org/tpo/network-health/metrics/timeline#timeline, now we need to use utls-imitate=hellorandomizedalpn insttead of hellochrome_auto for Iran?

hellorandomizedalpn is what the team plans to deploy as a default setting in the next release, Tor Browser 11.5.5. If you are setting your own bridge line manually, you can use hellochrome_auto, hellorandomizedalpn, or anything that works.

I have some news that the following is not working in Iran.

Thank you for the report. Are you using Tor Browser 11.5.4? The utls-imitate setting will have no effect on versions 11.5.3 and earlier. Is it on Android or desktop?

Another thing you can try is combining the alternative AMP cache rendezvous url=https://snowflake-broker.torproject.net/ ampcache=https://cdn.ampproject.org/ front=cdn.ampproject.org from https://github.com/net4people/bbs/issues/131#issuecomment-1270782707 with utls-imitate=anything.

free-the-internet commented 1 year ago

@wkrp Yes. It is 11.5.4 A friend told me that neither hellochrome_auto nor hellorandomizedalpn was working on his phone. But the snowflake option itself (without custom bridge) was working! Again, we need more testers, because he is not professional user. We need some other testers. Unfortunately I don't know many of them. I will try to get reports from other sources ASAP.

Will test AMP too.

hexrot commented 1 year ago

@wkrp flakes traffic again at my firefox-LibreWolve instances no traffic at my safari-iCab instances

n8fr8 commented 1 year ago

Orbot for Android 16.6.3-BETA-2-tor.0.4.7.10 with utls enabled, now available here: https://github.com/guardianproject/orbot/releases/tag/16.6.3-BETA-2-tor.0.4.7.10

(arm64 direct APK: https://github.com/guardianproject/orbot/releases/download/16.6.3-BETA-2-tor.0.4.7.10/Orbot-16.6.3-BETA-2-tor.0.4.7.10-fullperm-arm64-v8a-release.apk )

This uses "utls-imitate=hellochrome_auto" - we will add the other options and ability to customize/select in the next update.

This release also has the ability to get Snowflake logs directly from the log window (enable Prefs->DEBUG log, tap on status messages to open log window, tap on snowflake icon to show snowflake log, then share!)

mehdifirefox commented 1 year ago

I tested in Iran. It didn't work

On Thu, 20 Oct 2022, 20:49 Nathan Freitas, @.***> wrote:

Orbot for Android 16.6.3-BETA-2-tor.0.4.7.10 with utls enabled, now available here:

https://github.com/guardianproject/orbot/releases/tag/16.6.3-BETA-2-tor.0.4.7.10

(arm64 direct APK: https://github.com/guardianproject/orbot/releases/download/16.6.3-BETA-2-tor.0.4.7.10/Orbot-16.6.3-BETA-2-tor.0.4.7.10-fullperm-arm64-v8a-release.apk )

This uses "utls-imitate=hellochrome_auto" - we will add the other options and ability to customize/select in the next update.

This release also has the ability to get Snowflake logs directly from the log window (enable Prefs->DEBUG log, tap on status messages to open log window, tap on snowflake icon to show snowflake log, then share!)

— Reply to this email directly, view it on GitHub https://github.com/net4people/bbs/issues/125#issuecomment-1285897627, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF26MY77M5YZXJXZZYC4ZYDWEF5IPANCNFSM6AAAAAAQSTBP2Y . You are receiving this because you commented.Message ID: @.***>

n8fr8 commented 1 year ago

Thank you. Did you enable Snowflake under the Bridges section on the main screen?

Otherwise, if it isn't too much trouble, can you try the following steps, to get some more details from the Snowflake log?

  1. enable "Debug Log" near bottom of the Settings menu
  2. restart Orbot
  3. tap the status line (where it shows the "starting..." etc messages)
  4. tap the snowflake icon next to "Log"
  5. tap the share button

then post that output here, or send the output of that to my email? nathan@guardianproject.info

mehdifirefox commented 1 year ago

I sent an email

I requested a new bridge by email and added it.. when the program started, it got stuck and crashed. I think the beta version is broken for me

On Thu, 20 Oct 2022, 21:56 Nathan Freitas, @.***> wrote:

Thank you. Did you enable Snowflake under the Bridges section on the main screen?

Otherwise, if it isn't too much trouble, can you try the following steps, to get some more details from the Snowflake log?

  1. enable "Debug Log" near bottom of the Settings menu
  2. restart Orbot
  3. tap the status line (where it shows the "starting..." etc messages)
  4. tap the snowflake icon next to "Log"
  5. tap the share button

then post that output here, or send the output of that to my email? @.***

— Reply to this email directly, view it on GitHub https://github.com/net4people/bbs/issues/125#issuecomment-1285969184, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF26MY2ZKOXPUWYUNBZUGKDWEGFEFANCNFSM6AAAAAAQSTBP2Y . You are receiving this because you commented.Message ID: @.***>

n8fr8 commented 1 year ago

Received the log. Thank you very much. If you have a chance to try Snowflake in Orbot instead of obfs4 bridges, please do.

mehdifirefox commented 1 year ago

I thank you for trying Free Internet Whenever you need my help, I am at your service

I don't see the Snowflake option in the bridge section

On Thu, 20 Oct 2022, 22:22 Nathan Freitas, @.***> wrote:

Received the log. Thank you very much. If you have a chance to try Snowflake in Orbot instead of obfs4 bridges, please do.

— Reply to this email directly, view it on GitHub https://github.com/net4people/bbs/issues/125#issuecomment-1285997067, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF26MY76VL3AOLE4VBUJKWLWEGIIVANCNFSM6AAAAAAQSTBP2Y . You are receiving this because you commented.Message ID: @.***>

free-the-internet commented 1 year ago

I thank you for trying to limit the internet Whenever you need my help, I am at your service I don't see the Snowflake option in the bridge section … On Thu, 20 Oct 2022, 22:22 Nathan Freitas, @.> wrote: Received the log. Thank you very much. If you have a chance to try Snowflake in Orbot instead of obfs4 bridges, please do. — Reply to this email directly, view it on GitHub <#125 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AF26MY76VL3AOLE4VBUJKWLWEGIIVANCNFSM6AAAAAAQSTBP2Y . You are receiving this because you commented.Message ID: @.>

You sure? It is very easy to find in Orbot. At the main page there is "Use Brdiges" option: image

and if you tap on it, there are 2 snowflake options: 1. fastly 2: AMP. Choose the first one and go back to main page, then press Start.

n8fr8 commented 1 year ago

On older devices, Android 9 and before, we don't support Snowflake, and those options are not displayed. We are looking into if we can remedy that, but there were issues with the Go code crashing.

hexrot commented 1 year ago

To whom it may concern > Intel Core Server, MacOS 10.15.7 4browsers at once on one account snowflake traffic: Firefox: low firefox-based browser LibreWolf: four times higher ! LibreWolf install may require to tap the option- or control key. Safari: none safari-based browser iCab: low No hunch, whether the results are generalizable.

hexrot commented 1 year ago

Any other n==bie task in which I Might be helpful? ;-))

mysteriousshade commented 1 year ago

How can i find witch UDP ports are open and available in Windows OS.

TOR doesn't work in Iran now, L2TP VPN works on most ISP.

mysteriousshade commented 1 year ago

Maybe government monitor this post so revealing our information maybe against what we are trying to do.

wkrp commented 1 year ago

There is a new report on network effects in Iran since September 2022. It is a collaboration of many contributors: OONI, IODA, Measurement Lab (M-Lab), Cloudflare, Kentik, Censored Planet, ISOC, and Article19.

https://ooni.org/post/2022-iran-technical-multistakeholder-report/

Timeline of events in Iran between 16th September 2022 to 16th October 2022

Summary of key topics:

mehdifirefox commented 1 year ago

گزارش جدیدی درباره اثرات شبکه در ایران از سپتامبر 2022 ارائه شده است. این گزارش با همکاری بسیاری از مشارکت کنندگان است: OONI ، IODA ، آزمایشگاه اندازه گیری (M-Lab) ، Cloudflare ، Kentik ، Censored Planet ، ISOC ، و Article19 .

https://ooni.org/post/2022-report-technical-multistakeholder-iran/

جدول زمانی رویدادها در ایران بین 16 سپتامبر 2022 تا 16 اکتبر 2022

خلاصه موضوعات کلیدی:

* [قطعی شبکه تلفن همراه ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#mobile-network-outages)

* [Regional outages](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#regional-outages)

* [HTTP/3 and QUIC traffic drop](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#http3-and-quic-traffic-drop)

* [اختلال IPv6 در ایرانسل ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#ipv6-disruption-on-irancell)

* [افزایش مسدود کردن DNS رمزگذاری شده ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#increased-blocking-of-encrypted-dns)

* [تاثیر بر تست سرعت اینترنت ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#impact-on-internet-speed-tests)

* [مسدود کردن واتساپ، اینستاگرام، اسکایپ، لینکدین و وایبر ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#blocking-of-whatsapp-instagram-skype-viber-and-linkedin)

* [مسدود کردن فروشگاه Google Play و Apple App Store ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#blocking-of-google-play-store-and-apple-app-store)

* [مسدود کردن مخازن افزونه مرورگر ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#blocking-of-browser-extension-repositories)

* [هزینه اقتصادی تعطیلی ](https://ooni.org/post/2022-iran-technical-multistakeholder-report/#the-economic-impact-of-irans-internet-shutdowns)

Had a lot of effort to write this report One word wrote Iran like China. Or everything was blocked.