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

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

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

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

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

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

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:

Спойлер

:~$ bash measure.sh vk.com
time: Fri Jul 2 19:36:28 UTC 2021
domain: vk.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: a.root-servers.net.
query_response: status=NOERROR, num_answers=0, num_authorities=13
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: SE
resolver_ip: 156.154.85.144
resolver_as: AS12008 NeuStar, Inc.
response_ips: 87.240.137.158 87.240.139.194 87.240.190.67 87.240.190.72 87.240.190.78 93.186.225.208
ips_from_doh: 87.240.137.158 87.240.139.194 87.240.190.67 87.240.190.72 87.240.190.78 93.186.225.208
analysis: OK - Response IPs [87.240.137.158 87.240.139.194 87.240.190.67 87.240.190.72 87.240.190.78 93.186.225.208] 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)

:~$ bash measure.sh twitter.com
time: Fri Jul 2 19:36:54 UTC 2021
domain: twitter.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: a.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::144
resolver_as: AS12008 NeuStar, Inc.
response_ips: 104.244.42.1 104.244.42.193
ips_from_doh: 104.244.42.129 104.244.42.65
tls_test: ip=104.244.42.1, error=0
analysis: OK - Response IP 104.244.42.1 produced certificate for domain twitter.com
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)

:~$ bash measure.sh skype.com
time: Fri Jul 2 19:37:28 UTC 2021
domain: skype.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: m.root-servers.net.
query_response: status=NOERROR, num_answers=0, num_authorities=13
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: SE
resolver_ip: 156.154.85.146
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 5000 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)

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

Спойлер

:~$ bash measure.sh leagueoflegends.com
time: Fri Jul 2 19:39:50 UTC 2021
domain: leagueoflegends.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: m.root-servers.net.
query_response: status=NOERROR, num_answers=0, num_authorities=13
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: SE
resolver_ip: 156.154.85.144
resolver_as: AS12008 NeuStar, Inc.
response_ips: 18.192.31.68 35.156.105.10
ips_from_doh: 18.192.31.68 35.156.105.10
analysis: OK - Response IPs [18.192.31.68 35.156.105.10] were found on dns.google.com using DNS-over-HTTPS
HTTP
analysis: OK - Got expected response
SNI
analysis: OK - Got TLS ServerHello

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:

Спойлер

:~$ bash measure.sh abs.twimg.com
time: Fri Jul 2 20:02:10 UTC 2021
domain: abs.twimg.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: a.root-servers.net.
query_response: status=NOERROR, num_answers=0, num_authorities=13
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: SE
resolver_ip: 156.154.85.146
resolver_as: AS12008 NeuStar, Inc.
response_ips: 152.199.24.185
ips_from_doh: 152.199.21.141
tls_test: ip=152.199.24.185, error=0
analysis: OK - Response IP 152.199.24.185 produced certificate for domain abs.twimg.com
HTTP
analysis: INTERFERENCE - Got injected response
1c1,11
<

<?xml version="1.0" encoding="iso-8859-1"?> 404 - Not Found

404 - Not Found

SNI
analysis: INCONCLUSIVE - Failed to get TLS ServerHello (curl: (28) Operation timed out after 5000 milliseconds with 0 out of 0 bytes received)

:~$ bash measure.sh pbs.twimg.com
time: Fri Jul 2 20:02:38 UTC 2021
domain: pbs.twimg.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: m.root-servers.net.
query_response: status=NOERROR, num_answers=0, num_authorities=13
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: SE
resolver_ip: 156.154.85.146
resolver_as: AS12008 NeuStar, Inc.
response_ips: 72.21.91.70
ips_from_doh: 192.229.233.50
tls_test: ip=72.21.91.70, error=0
analysis: OK - Response IP 72.21.91.70 produced certificate for domain pbs.twimg.com
HTTP
analysis: INTERFERENCE - Got injected response
1c1,11
<

<?xml version="1.0" encoding="iso-8859-1"?> 404 - Not Found

404 - Not Found

SNI
analysis: OK - Got TLS ServerHello

:~$ bash measure.sh video.twimg.com
time: Fri Jul 2 20:06:02 UTC 2021
domain: video.twimg.com
client_country: UZ
client_as: AS8193 Uzbektelekom Joint Stock Company

DNS_INJECTION
root_nameserver: m.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::143
resolver_as: AS12008 NeuStar, Inc.
response_ips: 68.232.34.217
ips_from_doh: 151.101.84.158
tls_test: ip=68.232.34.217, error=0
analysis: OK - Response IP 68.232.34.217 produced certificate for domain video.twimg.com
HTTP
analysis: INTERFERENCE - Got injected response
1c1,11
<

<?xml version="1.0" encoding="iso-8859-1"?> 404 - Not Found

404 - Not Found

SNI
analysis: OK - Got TLS ServerHello

:~$ bash measure.sh t.co
time: Fri Jul 2 20:07:00 UTC 2021
domain: t.co
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=6
analysis: OK - Received expected response
SYSTEM_RESOLVER
resolver_country: US
resolver_ip: 2610:a1:3040:128::143
resolver_as: AS12008 NeuStar, Inc.
response_ips: 104.244.42.133 104.244.42.197 104.244.42.5 104.244.42.69
ips_from_doh: 104.244.42.133 104.244.42.197 104.244.42.5 104.244.42.69
analysis: OK - Response IPs [104.244.42.133 104.244.42.197 104.244.42.5 104.244.42.69] were found on dns.google.com using DNS-over-HTTPS
HTTP
analysis: OK - Got expected response
SNI
analysis: OK - Got TLS ServerHello

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

Спойлер

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