Частичные и полные блокировки сервисов Twitter, Tik-Tok, ВКонтакте, Skype в Узбекистане

Thank you @fortuna for your interest and workaround tips!

Also, our government ISP’s block native VPN-connections by protocol (OpenVPN, L2TP, PPTP without cloacking into HTTPS), so I want to ask - can Outline Manager cloack VPN tunnel somehow?
For example, if I buy VPS in foreign hosting and install Outline Manager software on them, can I somehow mask protocol of VPN connection from client?

Yes, Outline (https://getoutline.org) uses Shadowsocks, which was designed to be hard to detect. It should work very well there.

Another option is to try Intra (https://getintra.org). Intra is faster than a VPN and you don’t need a server. It uses encrypted DNS and does SNI splitting, similar to GoodbyeDPI. The downside is that it’s Android-only and doesn’t protect against HTTP blocking (though most blocked sites support HTTPS).

Understood, thank you, will try both of them.

UPD: Sorry, there’s was huge mistake from my side - I forgot about I’ve changed of DNS in my router to Verisign (currently Neustar) public DNS. Add additional log for skype.com when I use both DNS (native ISP’s DNS and foreign from Verisign):

Спойлер

// Native ISP’s DNS:

:~$ bash measure.sh skype.com
time: Sat Jul 3 16:06:03 UTC 2021
domain: skype.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: j.root-servers.net.
query_response: status=NOERROR, num_answers=0, num_authorities=13
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: UZ
resolver_ip: 185.74.5.5
resolver_as: AS202660 Uzbektelekom Joint Stock Company
response_ips: 104.40.50.126 23.102.255.237 40.115.34.155 40.121.80.200
ips_from_doh: 104.40.50.126 23.102.255.237 40.115.34.155 40.121.80.200
analysis: OK - Response IPs [104.40.50.126 23.102.255.237 40.115.34.155 40.121.80.200] were found on dns.google.com using DNS-over-HTTPS
HTTP
analysis: OK - Got expected response
SNI
analysis: INCONCLUSIVE - Failed to get TLS ServerHello (curl: (28) Operation timed out after 5000 milliseconds with 0 out of 0 bytes received)

// After DNS changed:

:~$ bash measure.sh skype.com
time: Sat Jul 3 16:13:40 UTC 2021
domain: skype.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: e.root-servers.net.
query_response: status=NOERROR, num_answers=0, num_authorities=13
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: US
resolver_ip: 2610:a1:3040:128::145
resolver_as: AS12008 NeuStar, Inc.
response_ips: 104.40.50.126 23.102.255.237 40.115.34.155 40.121.80.200
ips_from_doh: 104.40.50.126 23.102.255.237 40.115.34.155 40.121.80.200
analysis: OK - Response IPs [104.40.50.126 23.102.255.237 40.115.34.155 40.121.80.200] were found on dns.google.com using DNS-over-HTTPS
HTTP
analysis: LIKELY_INTERFERENCE - Unexpected time out when Host is skype.com (curl: (28) Operation timed out after 5001 milliseconds with 0 bytes received)
SNI
analysis: INCONCLUSIVE - Failed to get TLS ServerHello (curl: (28) Operation timed out after 5001 milliseconds with 0 out of 0 bytes received)

@TheRambotnik Thanks for the updated runs.

It seems that the ISP resolver is not implementing any block after all. At least for skype.com.

PS: tip for sharing the output: put it in a “preformatted text” block and it should display cleanly.

@fortuna Thank you for your time and useful tips!

It turns out you can measure some censorship from outside the network:

$ curl --connect-to ::84.54.113.66: https://laborrights.org -D -             
curl: (35) error:1400410B:SSL routines:CONNECT_CR_SRVR_HELLO:wrong version number

$ curl --connect-to ::84.54.113.66: https://example.com -D -    
curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

I took a look at the Censored Planet data and was able to come up with a list of sites blocked by SNI in AS8193 Uzbektelekom. They seem to block porn, gambling, circumvention tools, but also Signal, Yahoo groups, Human Rights sites and religious sites.

This is the result of my aggregation of the CP data. Click on the domains at your own risk. Unfortunately CP didn’t have data on the blocked sites listed on this post.

Domain Unexpected Count Record Count Unexpected Rate
laborrights.org 8 8 100%
www.eurogrand.com 7 7 100%
www.luckynugget.com 7 7 100%
www.scientology.org 7 7 100%
groups.yahoo.com 7 7 100%
www.xvideos.com 7 7 100%
surfshark.com 7 7 100%
www.ilhr.org 7 7 100%
www.jmarshall.com 7 7 100%
bongacams.com 7 7 100%
www.khilafah.com 7 7 100%
opera.com 7 7 100%
chaturbate.com 7 7 100%
www.geocities.com 7 7 100%
www.liveleak.com 7 7 100%
www.spinpalace.com 7 7 100%
www.pornhub.com 7 7 100%
www.scribd.com 7 7 100%
www.hizb-ut-tahrir.org 7 7 100%
youporn.com 7 7 100%
beeg.com 7 7 100%
xhamster.com 7 7 100%
www.purevpn.com 7 7 100%
pornhub.com 7 7 100%
www.frontlinedefenders.org 7 7 100%
www.sex.com 7 7 100%
www.usacasino.com 7 7 100%
www.ihf-hr.org 7 7 100%
www.casinotropez.com 7 7 100%
adultfriendfinder.com 7 7 100%
hola.org 7 7 100%
www.fidh.org 7 7 100%
www.hushmail.com 7 7 100%
www.clubdicecasino.com 7 7 100%
ikhwanonline.com 7 8 100%
www.privateinternetaccess.com 7 7 100%
signal.org 7 7 100%
www.anonymizer.ru 7 7 100%
www.betfair.com 7 7 100%
www.proxyweb.net 7 7 100%
www.anonymizer.com 7 7 100%
xnxx.com 7 7 100%
proxify.com 7 7 100%
livejasmin.com 7 7 100%
www.opensocietyfoundations.org 7 7 100%
xvideos.com 7 7 100%
securevpn.com 7 7 100%
www.pokerstars.com 7 7 100%
www.amnestyusa.org 7 7 100%
www.tunnelbear.com 7 7 100%
www.torproject.org 7 7 100%
www.europacasino.com 7 7 100%
livestream.com 7 7 100%
infobae.com 7 7 100%
www.f-secure.com 7 7 100%
www.crazyshit.com 7 7 100%
scribd.com 7 7 100%
bridges.torproject.org 7 7 100%
www.youporn.com 7 7 100%
xanga.com 7 7 100%
khilafah.net 7 7 100%
www.slotland.com 7 7 100%
ooni.torproject.org 7 7 100%
anonymouse.org 7 7 100%
www.change.org 7 7 100%
krishna.com 7 7 100%
nordvpn.com 7 7 100%
www.megaproxy.com 7 7 100%
www.roxypalace.com 7 7 100%
www.ipvanish.com 7 7 100%
www.adventist.org 7 7 100%
guardster.com 7 7 100%
www.888casino.com 6 6 100%
www.hidemyass.com 6 7 86%
www.jesussaves.cc 6 7 86%
spankbang.com 2 2 100%

Yup, this is an old list of web-sites, which was blocked at 2010 and later. External VPN services, also, blocked by protocols - PPTP, L2TP and IPSec, not only by ip/hostnames. And yes, we have crazy censorship system, based on illogical rules)

I can’t detect censorship of the 4 sites you mentioned from outside the network:

$ curl --connect-to ::84.54.113.66: https://skype.com -D -
curl: (60) SSL: no alternative certificate subject name matches target host name 'skype.com'
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

That suggests that there are two separate mechanisms at play.

I’m also getting a different result for signal.org, which may be yet another mechanism:

$ curl --connect-to ::84.54.113.66: https://www.signal.org -D -
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.signal.org:443 

@TheRambotnik can you try the measure script on www.signal.org?

@fortuna sure, here’s log:

    :~$ bash measure.sh www.signal.com
time: Sat Jul  3 17:53:12 UTC 2021
domain: www.signal.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
  root_nameserver: e.root-servers.net.
  query_response: status=NOERROR, num_answers=0, num_authorities=13
  analysis: OK - Received expected response
SYSTEM_RESOLVER
  resolver_country: UZ
  resolver_ip: 185.74.5.210
  resolver_as: AS202660 Uzbektelekom Joint Stock Company
  response_ips: 34.206.39.153
  ips_from_doh:  34.206.39.153
  analysis: OK - Response IPs [34.206.39.153] were found on dns.google.com using DNS-over-HTTPS
HTTP
  analysis: OK - Got expected response
SNI
  analysis: OK - Got TLS ServerHello

This is for www.signal.com, please do www.signal.org :slight_smile:

Oh, sry, my bad. New logs:

:~$ bash measure.sh www.signal.org
time: Sat Jul  3 18:05:15 UTC 2021
domain: www.signal.org
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
  root_nameserver: l.root-servers.net.
  query_response: status=NOERROR, num_answers=0, num_authorities=6
  analysis: OK - Received expected response
SYSTEM_RESOLVER
  resolver_country: UZ
  resolver_ip: 185.74.5.210
  resolver_as: AS202660 Uzbektelekom Joint Stock Company
  response_ips: 13.32.123.28 13.32.123.33 13.32.123.43 13.32.123.56
  ips_from_doh:  13.32.123.28 13.32.123.33 13.32.123.43 13.32.123.56
  analysis: OK - Response IPs [13.32.123.28 13.32.123.33 13.32.123.43 13.32.123.56] were found on dns.google.com using DNS-over-HTTPS
HTTP
  analysis: OK - Got expected response
SNI
  analysis: INCONCLUSIVE - Failed to get TLS ServerHello (curl: (28) Operation timed out after 5001 milliseconds with 0 out of 0 bytes received)

@fortuna, I confirm your measurements of laborrights.org, example.com, and skype.com. For me, the test of www.signal.org times out (I waited over 30 s) rather than returning a SSL_connect: SSL_ERROR_SYSCALL error.

$ curl --connect-to ::84.54.113.66: https://laborrights.org -D -
curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number
$ curl --connect-to ::84.54.113.66: https://example.com -D -
curl: (60) SSL: no alternative certificate subject name matches target host name 'example.com'
$ curl --connect-to ::84.54.113.66: https://skype.com -D -
curl: (60) SSL: no alternative certificate subject name matches target host name 'skype.com'
$ curl --connect-to ::84.54.113.66: https://www.signal.org -D -
^C

I agree with your assessment:

  • Some domains (like laborrights.org) can be measured from the outside (and therefore appear as anomalies in Censored Planet’s data).
  • @TheRambotnik experiences an SNI block of skype.com from inside Uzbekistan that apparently cannot be measured externally (and so would likely not appear in Censored Planet’s data).
  • www.signal.org is a special case that exhibits anomalous behavior from both inside and outside (and it therefore also appears on the Censored Planet list).

OONI measurements from Uzbekistan:
https://explorer.ooni.org/country/UZ

Web Connectivity tests from AS8193 in the past 60 days:
https://explorer.ooni.org/search?probe_cc=UZ&probe_asn=AS8193&test_name=web_connectivity&since=2021-05-04&until=2021-07-04

There are a few domains that also appear in the list of Censored Planet list; unfortunately OONI tests the HTTP versions, not the HTTPS versions, so it’s not directly comparable. Some examples:

  • www.jmarshall.com - unknown_failure: Get “http://www.jmarshall.com/tools/cgiproxy/”: net/http: HTTP/1.x transport connection broken: malformed HTTP status code “not”
  • www.usacasino.com - unknown_failure: Get “http://www.usacasino.com/”: net/http: HTTP/1.x transport connection broken: malformed HTTP status code “not”
  • guardster.com - http_parser_invalid_constant

I wonder if the malformed HTTP status code "not" error is picking up the second word in a “404 not found” injection. (The HTTP injection in Частичные и полные блокировки сервисов Twitter, Tik-Tok, ВКонтакте, Skype в Узбекистане - #4 by TheRambotnik looks different, however: actually well-formed HTTP.)

OONI also has a Signal-specific test:
https://explorer.ooni.org/search?probe_cc=UZ&probe_asn=AS8193&test_name=signal&since=2021-05-04&until=2021-07-04

The Signal test does not measure www.signal.org, but it does textsecure-service.whispersystems.org, storage.signal.org, api.directory.signal.org, cdn.signal.org, cdn2.signal.org, sfu.voip.signal.org. In a recent (2021-06-29) measurement from AS8193, all these domains fail with generic_timeout_error after the tls_handshake_start operation.

@tango I believe the error is due to a non-HTTP response with the text “Object not found”:

% curl --connect-to ::84.54.113.66:443 http://www.jmarshall.com -D -
Object not found

I see the same for guardster.com. The different error messages may be due to different OONI probe implementations.

This is a control for comparison:

% curl --connect-to ::84.54.113.66:443 http://www.example.com -D -
HTTP/1.1 400 Bad Request
Server: nginx
Date: Sat, 03 Jul 2021 19:52:07 GMT
Content-Type: text/html
Content-Length: 264
Connection: close

<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body bgcolor="white">
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>

I observed four methods of TLS blocking. The most common is that ‘Object not found’ plain text reply (with the IP ID=0x3412) to a Client Hello Message having an ‘eerie’ SNI. The second type - RSTing a TCP connection after its first SYN segment - is probably reserved for some more ‘malicious’ IPv4 addresses like these of bridges.torproject.org. The third blocking technique works only inside Teredo tunnels, where all incoming TCP segments are vanishing forever after a ‘wrong’ Server Certificate Message (I used TLS 1.2 for testing). (Teredo is not reliable, so I quite carefully retested this to exclude any protocol-related arthefact.) The forth one was also noticed only inside Teredo tunnels where my SNI-less TLS connection to a ‘bad’ IPv6 address becomes stalled for some ‘good’ 80 seconds.

Для тех, кто возможно попытается обойти блокировки при помощи GoodByeDPI - в данный момент это не помогает ни в одном из режимов.

I’m surprised that GoodbyeDPI doesn’t work, since it’s supposed to help with SNI-based blocking. It would be nice to collect evidence on whether GoodByeDPI works. Perhaps you need to combine it with a third party DNS resolver to make it work.

GoodbyeDPI with -4 mode and --set-ttl setting somewhat works for Twitter and VK.
By default Twitter is slow/very slow and images won’t load at all (if page loads in the end), VK is very slow, page starts to load after several minutes (with images).
With GoodbyeDPI and --set-ttl VK is fast as before, Twitter is a little slow, but everything loads.
Without --set-ttl it doesn’t helps even with -1 mode.

At first day GoodbyeDPI wasn’t works. Seems like something was changed in blocking settings from Uzbektelecom’s side, because now measures to t.co and other Twitter’s subdomains show not the same info.
About ttl - from the evening of yesterday it works with ttl = 7 and ttl = 8.

This time it is a massive middlebox-induced packet lost being triggered by a ‘bad’ Server Name extension of the Client Hello message. I managed to find a node in Twitter’s web server farm that supports both TLS 1.0 SNI-less connections, and TLS 1.3 ones. The difference is amazing. When downloading the same image a TLS 1.0 SNI-less connection lasts for 0.5-0.6 seconds, while a TLS 1.3 one continues for 200-300 seconds! (FINing the later takes the most of the time.) I can confirm that packets are being lost in both directions.

Actually, the “404 - Not Found” XHTML reported in post 4 may not be an injected block page—I get the same for abs.twimg.com (but I get no content for pbs.twimg.com and video.twimg.com).

curl output for {abs,pbs,video}.twimg.com
$ curl http://abs.twimg.com/ -D -
HTTP/1.1 404 Not Found
Content-Type: text/html
Date: Fri, 30 Jul 2021 01:06:37 GMT
Server: ECAcc (dna/62BC)
Content-Length: 345

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
        <head>
                <title>404 - Not Found</title>
        </head>
        <body>
                <h1>404 - Not Found</h1>
        </body>
</html>
$ curl http://pbs.twimg.com/ -D -
HTTP/1.1 400 Bad Request
Accept-Ranges: bytes
Age: 52
cache-control: no-cache, no-store, max-age=0
Date: Fri, 30 Jul 2021 01:06:40 GMT
Last-Modified: Fri, 30 Jul 2021 01:05:48 GMT
Server: ECS (dna/63AA)
strict-transport-security: max-age=631138519
timing-allow-origin: https://twitter.com, https://mobile.twitter.com
X-Cache: MISS
x-connection-hash: edf3e6110f73a1c7d9af9ff94e0d40cf3da324da449abf11c06e154d12b1e495
X-Content-Type-Options: nosniff
x-tw-cdn: VZ
x-tw-cdn: VZ
Content-Length: 0

$ curl http://video.twimg.com/ -D -
HTTP/1.1 400 Bad Request
cache-control: no-cache, no-store, max-age=0
date: Fri, 30 Jul 2021 01:06:52 UTC
server: tsa_a
x-connection-hash: 438e11344cdde2769e30d2bc13be8d41a8dace4f96233ee63324b4ae5365afe4
X-Content-Type-Options: nosniff
x-tw-cdn: VZ
x-tw-cdn: VZ
Content-Length: 0

With this, it’s not clear to me whether plain HTTP blocking is happening for the newly domains. (It’s clear that they are blocked by TLS SNI, and for the historically blocked domains found in post 11 it’s clear that both HTTP and HTTPS get the Object not found\r\n\r\n injection.) vk.com and twitter.com had the expected HTTP response, skype.com had a timeout, and *.twimg.com had a 404 that is possibly not anomalous. With the ISP’s own DNS, skype.com also had the expected HTTP response.

post domain DNS HTTP analysis
post 3 vk.com Verisign OK - Got expected response
post 3 twitter.com Verisign OK - Got expected response
post 3 skype.com Verisign LIKELY_INTERFERENCE - Unexpected time out
post 4 abs.twimg.com Verisign XHTML 404 - Not Found (possibly expected)
post 4 pbs.twimg.com Verisign XHTML 404 - Not Found (possibly expected)
post 4 video.twimg.com Verisign XHTML 404 - Not Found (possibly expected)
post 8 skype.com ISP OK - Got expected response
post 8 skype.com Verisign LIKELY_INTERFERENCE - Unexpected time out

Блокировки всё ещё сохраняются, или это было временное явление?