Доброго времени суток,

Вот и до нас докатились Роскомнадзоровские тренды по блокировке (частичной и полной) TikTok, Twitter, Skype и ВКонтакте. Выражается это в том, что страницы сервисов открываются с огромной задержкой, активное содержимое не подгружается вовсе.

Для тех, кто возможно попытается обойти блокировки при помощи GoodByeDPI - в данный момент это не помогает ни в одном из режимов. Лучше сразу переходите к варианту с использованием VPN-сервисов (не использующих явный OpenVPN-протокол).

Решение: использование VPN-сервисов решает проблему доступов, но есть информация о том, что часть VPN-сервисов также заблокирована.

P.S.: Если кто-то хочет покопаться и посмотреть как устроены блокировки с нашей стороны - могу предоставить необходимый доступ

Can you run this block test on some of the domains to try to determine how they’re being blocked?

Hello, sure, here’s current output for Twitter, Vkontakte and Skype:

And also output for host, which wasn’t blocked (for comparsion):

Update:
Found in one of topics here detailed addresses of twitter subdomains (abs.twimg.com - contain js scripts, pbs - media, video - video files and t.co as shorten links). More logs under spoiler:

Thank you @TheRambotnik, that’s very informative.

We can’t determine whether the ISP DNS resolver lies, since the system resolver tested doesn’t seem to be the one provided by the ISP (different country and AS).

It seems there’s no DNS injection, so using a third-party resolver should bypass DNS-based censorship, if any.

TLS connections seem to be blocked based on the SNI. I would guess packet dropping, causing the timeouts.

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. Or perhaps the government has indeed some advanced equipment.

The HTTP injection seems to be real. Even though those Twitter domains normally return a 404 without a path, they don’t return any content. The HTML you got is likely a block page, and can be used as a fingerprint to detect other blocked websites.

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):

@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.

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

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 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.

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

Блокировки skype и части voip, протоколов openvpn и замедление работы сервисов, вроде twitter и tiktok - всё ещё в силе. Недавно к этому списку добавилась блокировка wechat, но он здесь не особо популярен.

Government registry for personal databases
Interesting that after vk, the list items are empty, and closer to the end the items are there again. Looks like these items were for Facebook, Instagram etc, and got delisted.

20-минутная война закончилась тем, что нашли “главного виновника” блокировок и оперативно всё разблокировали. Из того, что успел зафиксировать находясь в дороге:
1- Блокировки носили частичный характер. Ресурсы не были полностью недоступны, просто был невероятно большой отклик, напоминающий ситуацию с “замедлением” Twitter на территории РФ;
2- Замедление проводилось не на уровне DNS-серверов. Решения, предотвращающие DNS Leakage, никак не влияли на отклик ресурсов;
3- Блокировались не хосты, а целые подсети, из-за чего, список ресурсов, подверженных “замедлению” не ограничивается только перечисленными в статье ресурсами;
4- Многие популярные VPN-сервисы и используемые ими протоколы/методы аутентификации, также, были заблокированы или работали с огромным откликом.

В продолжении темы - немного замеров в сторону всё ещё мёртвого YouTube:

bash measure.sh www.youtube.com
time: Wed Nov  3 17:58:14 UTC 2021
domain: www.youtube.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
  root_nameserver: a.root-servers.net.
  query_error: Could not get response
  analysis: INTERFERENCE - Could not get response
HTTP
  analysis: LIKELY_INTERFERENCE - Unexpected time out when Host is www.youtube.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)

“Uzkomnozorat” restricted access to Telegram, Facebook, Instagram and other social networks

In addition to TikTok, Twitter, VKontakte and Skype, Telegram, Facebook, Odnoklassniki, YouTube and others are included in the register of violators of legislation on personal data in Uzbekistan. The work of these social networks is limited.

Added: The head of Uzkomnazorat was dismissed, access to social networks was restored.

I think this link is supposed to be Shaxsga doir ma’lumotlar bazalarining davlat reyestri | pd.gov.uz.

I don’t see what you mean about the list items being empty. The listing looks uniform to me: WeChat, VKontakte, Skype, TikTok, Twitter. (Archive) Is it something in the structure of the HTML?

It had blank forms at the time when I wrote that post, now everything seems fixed.

Dears, hello again,

Currently, look’s like we have new situation:
At 3rd of November, Uzbektelecom changes something in resolvers and routes. This event caused limitation of access to MS365 cloud services (like Azure, EWA/EWS, etc.) and to some AS from external network. in 4-th of November all was fixed, but after this, we see some kind of bandwith limitations with transfering of big files in MS365 services (for example - letters in outlook without attachments receiving without problems, but if there’s some file attached - time to loading this letter increasing dramatically; same situation with Sharepoint’s instances - data in web-version of Office365 loads correctly and fast, but if we start to use desktop apps (word, excel, PBI, etc.), which retrieving information from MS servers, time to loading increasing dramatically, no matter of file size). Regadring this, can we somehow check for active DPI activity for MS services, because situation similar with Roskomnadzor and Twitter.

Sorry for my bad English, I hope I was able to explain clearly.

This is the summary of Censored Planet and others’ throttling experiments in 2021: Throttling of Twitter in Russia

There are some experiments you can do to test whether there is domain-based throttling. (Probably uses TLS SNI.) Do do this, you can find the URL of a large file on one of these domains, try downloading it with different variations, and see if the speed changes.

• TLS ClientHello segmentation/fragmentation (implemented in GoodbyeDPI and zapret)
• Adding a trailing dot to the SNI
• Prepending client hello records with other TLS records, such as change cipher spec
• TLS ClientHello inflation with padding extension to make it bigger than 1 packet (1500+ bytes)

These are not all easy to implement. You can install GoodbyeDPI or zapret to test Client Hello segmentation.

To test adding a dot to the SNI, you can set the SNI manually using openssl s_client for example. If your test URL is https://example.com/bigfile.attachment, try:

(echo $'GET /bigfile.attachment HTTP/1.1\r\nHost: example.com\r\n\r'; cat) | openssl s_client -connect example.com:443 -servername "example.com." | pv > /dev/null

There are some tips for testing for SNI throttling with curl here: Social networks being slowed down - #2 by stek29

Простите мне мое невежество. А где можно скачать этот скрипт measure.sh?

Не заметил, ссылка есть на этой же странице