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”
The Signal test does not measure www.signal.org, but it doestextsecure-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.
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>
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 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?
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.
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
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: