AFAIK QUIC traffic is impossible to attack using MITM techniques. So I wonder how the GFW handles it. Do they block it entirely or still filter it somehow?

You don't need QUIC, TLS and other encrypted channels have the same protection.

It's not hard to identify those channels and block them. A connection used to interact with websites has completely different traffic patterns compared to a user sending all of their traffic over one specific connection.

Add to that the fact that large video streaming services such as YouTube, where you may see large quantities of data being exchanged over persistent connections, are already blocked in China, and your VPN becomes quite obvious without seeing even a byte of plaintext.

Of course for common protocols like QUIC they have their own custom solution (linked in a sibling comment), but the point is that even with encrypted SNI you will need dedicated anti-GFW protocols to stand a chance against censorship. No protocol that works well for most consumers is going to protect against the analysis a dedicated firewall with decent funding can come up with.

According to https://gfw.report/publications/usenixsecurity25/en/#3 they sniff the SNI out of the handshake like for TLS.

Why would QUIC be any more or less MITM attackable than say HTTP1.1 or 2?

AFAIK, the only thing that stops an MITM attack (where they respond as if they’re the remote server and then relay to the real remote server) are certificates.

If an authority requires you trust their root certificate so they can spy on you, QUIC will not make any difference.

Typically they rely on metadata like the IP you're connecting to, or downgrade attacks. Until every server supports QUIC they can just pretend the server doesn't support QUIC.

You might think IP checks are safe because everything's on Cloudflare and they can't block Cloudflare, but you'd be wrong. Even Spain blocks Cloudflare (yes, entirely) during football games.

That's not true. QUIC's encrypted traffic does not protect against MITM.