net4people / bbs

Forum for discussing Internet censorship circumvention
3.26k stars 77 forks source link

OONI report on attempts to block Signal Private Messenger #91

Open wkrp opened 2 years ago

wkrp commented 2 years ago

OONI has posted a report that examines the results of its new test for the reachability of Signal Private Messenger since April 2021.

How countries attempt to block Signal Private Messenger App around the world Maria Xynou and Arturo Filastò 2021-10-21

OONI's new Signal test checks for blocking of various HTTPS endpoints used by the Signal Private Messenger app. The test makes a number of HTTPS GET requests using a pinned CA certificate, and reports an anomaly if any of the requests fails.

An anomalous measurement does not necessarily mean that Signal is actually blocked—besides the possibility of transient network failures, Signal employs built-in censorship circumvention under certain conditions that does not directly access the endpoints tested by the OONI test. A consistent pattern of anomalous measurements is needed to be meaningful, and even then shows only that a censor has tried to block Signal, not necessarily that the block was effective.

OONI analysts looked for countries with a high proportion of anomalous measurements from the Signal test. After removing countries with few total measurements or whose anomalies looked like false results, they did deeper investigation of four countries that have a pattern of Signal blocking: China, Cuba, Iran, and Uzbekistan. Besides these, there are signs of blocking in the UAE, Oman, and Qatar, though there are not enough measurements from these countries to make a confident statement.

China

There is a high density of OONI measurements in several networks in China, with the majority of measurements showing blocking.

Blocking is done by DNS injection, according to the a pattern that is familiar in China: responses contain fake IP addresses drawn from a large pool. In this sample measurement, the injected address is one that belongs to Facebook.

{
  "engine": "system",
  "failure": null,
  "hostname": "textsecure-service.whispersystems.org",
  "query_type": "A",
  "resolver_hostname": null,
  "resolver_port": null,
  "resolver_address": "",
  "t": 0.164493958,
  "answers": [
    {
      "asn": 32934,
      "as_org_name": "Facebook, Inc.",
      "answer_type": "A",
      "ipv4": "69.171.239.11",
      "ttl": null
    }
  ]
}

Cuba

There was a large fraction of anomalous measurements in Cuba starting on 2021-07-12 and lasting for about a week thereafter. The blocking coincides with protests that were happening at that time, during which much social media was reported to be blocked. Before this time, there were not many OONI measurements from Cuba to compare to. After this time, the Signal servers became mostly accessible, though there was still a low level of anomalous results.

While it was happening, blocking was done by resetting TCP connections, likely in reaction to the TLS SNI. Here is a sample measurement:

{
  "cipher_suite": "",
  "failure": "connection_reset",
  "negotiated_protocol": "",
  "no_tls_verify": false,
  "peer_certificates": null,
  "server_name": "textsecure-service.whispersystems.org",
  "t": 0.293198802,
  "tags": null,
  "tls_version": ""
}

Iran

There is a large number of OONI measurements from Iran, which show near-total blocking of Signal endpoints across many networks.

Blocking is done by DNS injection. DNS queries for the tested signal.org names receive a response of 10.10.34.35, which is well known to be the address of a server that serves a blockpage in Iran. See a sample measurement:

{
  "engine": "system",
  "failure": null,
  "hostname": "api.directory.signal.org",
  "query_type": "A",
  "resolver_hostname": null,
  "resolver_port": null,
  "resolver_address": "",
  "t": 0.031100216,
  "answers": [
    {
      "answer_type": "A",
      "ipv4": "10.10.34.35",
      "ttl": null
    }
  ]
}

Uzbekistan

There were few measurements available from Uzbekistan—only 30 total from 8 ASes—but every one was anomalous.

The symptom of blocking in Uzbekistan is that connections time out at some point after the client send the first data packet in the TLS handshake. See a sample measurement:

{
  "operation": "connect",
  "address": "173.194.220.121:443",
  "proto": "tcp",
  "t": 0.474921823,
  "failure": null
},
{
  "operation": "tls_handshake_start",
  "t": 0.47523901,
  "failure": null
},
{
  "operation": "write",
  "num_bytes": 288,
  "t": 0.478659219,
  "failure": null
},
{
  "operation": "read",
  "t": 10.477152913,
  "failure": "generic_timeout_error"
},
{
  "operation": "tls_handshake_done",
  "t": 10.47733385,
  "failure": "generic_timeout_error"
},

I found a more recent measurement that had a couple of successful "read" events after the first "write" event, before starting to time out:

{
  "operation": "connect",
  "address": "76.223.92.165:443",
  "proto": "tcp",
  "t": 0.259690886,
  "failure": null
},
{
  "operation": "tls_handshake_start",
  "t": 0.259772552,
  "failure": null
},
{
  "operation": "write",
  "num_bytes": 307,
  "t": 0.262190208,
  "failure": null
},
{
  "operation": "read",
  "num_bytes": 517,
  "t": 3.775013176,
  "failure": null
},
{
  "operation": "read",
  "num_bytes": 831,
  "t": 3.77526703,
  "failure": null
},
{
  "operation": "read",
  "t": 10.28804083,
  "failure": "generic_timeout_error"
},
{
  "operation": "tls_handshake_done",
  "t": 10.288115725,
  "failure": "generic_timeout_error"
},