Russia blocks TLS v1.2 requests to cloudflare edges

Website, Application, Performance Security
1

There is a lot of reports about connection issues from russia when:

a) Connecting to a cloudflare-proxied website that has TLS v1.3 explicitly disabled in cloudflare dashboard (examples: app.plex.tv, vrchat.com)
b) Using specific network stacks like .NET’s http library while allowing only TLS v1.2 connections to any domain behind cloudflare proxy

Probable cause is a TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ciphersuite in 4th place of the ClientHello’s ciphersuites list

How to reproduce (requires curl with openssl, not with libressl and a russian ISP connection):

curl -v https://bo0om.ru --tls-max 1.2 --ciphers ECDHE-RSA-AES128-GCM-SHA256

More info (in russian): Блокировка шифра в сторону Cloudflare на ТСПУ - Russia - NTC

4 Likes
3

How does it look:

  1. Client sends ClientHello with an affected ciphersuite
  2. Server returns ServerHello
  3. Connection gets blackholed, no further packets are allowed
4

Rarjpeg with .pcap

bo0om.ru_cf_aes128gcmsha256_block_01.04.2024_rarjpg
bo0om.ru_cf_aes128gcmsha256_block_01.04.2024_rarjpg629×571 142 KB

5

The reason, it seems, is not entirely in the client cipher. Most likely, the censoring system doesn’t like something about the server’s response, not something about the client’s request. I reproduced the problem on my server (not Cloudflare IP) by proxying requests to Cloudflare.

This explains why there is no problem with TLS 1.3 (TLS 1.2 and 1.3 have significantly different responses), and why changing the Ciphers fixes the problem (the server response changes, perhaps just comparing certain bytes in certain places).

Requesting this domain (community.cloudflare.com) also does not trigger the issue, as this domain uses different certificate chain (not Google Trust Services LLC).

6

The block has been lifted.

1 Like
7

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.