China is apparently blocking all HTTPS traffic that uses TLS 1.3’s ESNI. The folks at the Geneva project have a detailed report about what triggers the censorship.
With previous version of TLS, although the traffic between a computer and a server would be encrypted, the Server Name Indication (SNI) field allowed ISPs to determine which website the user was communicating with.
TLS 1.3 fixes that by introducing Encrypted SNI (ESNI), so that it is impossible for ISPs or other entities to see what website the user is trying to access. As the report notes,
ESNI has the potential to complicate nation-states’ abilities to censor HTTPS content; rather than be able to block only connections to specific websites, ESNI would require censors to block all TLS connections to specific servers. We do confirm that this is now happening in China!
. . .
Comparing the traffic captured on both endpoints, we find the GFW [Great Firewall] blocks ESNI connections by dropping packets from clients to servers.
This has two differences from how the GFW censors other commonly-used protocols. First, the GFW censors (non-encrypted) SNI and HTTP by injecting forged TCP RSTs to both server and client; conversely, we have observed no injected packets from the GFW to censor ESNI traffic. Second, the GFW drops traffic from server to client to block Tor and Shadowsocks servers; however, it drops only client-to-server packets when censoring ESNI.
We further note the GFW does not distinguish the flags of TCP packets when dropping them. (This is different from some censorship systems in Iran which do not drop packets with RST or FIN flags.)
The Geneva project report goes on to describe a number of strategies to evade this censorship.