I have collected HTTP/3 censorship measurements on a VPS connected to AS45090 repeatedly (21 times) between 14.01. and 21.02.2022. The test list had around 300 entries and The analysis of the measurements suggests that the Chinese firewall does not explicitly handle QUIC traffic but HTTP/3 traffic is nevertheless impaired.
abbreviation
failure type
TCP-hs-to
TCP handshake timeout
TLS-hs-to
TLS handshake timeout
QUIC-hs-to
QUIC handshake timeout
conn-reset
connection reset: TCP RST terminated connection during TLS handshake
conn-to
connection timeout (after handshake)
ping-to
quicping timed out, i.e. there was no server response to the ping request
Not all websites that were blocked over HTTPS were also blocked over HTTP/3. The result figure shows that the Great Firewall uses different methods to block HTTPS connections. Different censorship methods cause different failure types when attempting to connect.
To around 24% of tested websites, not even the TCP handshake could be completed and the connection attempt timed out in the first roundtrip. The same set of websites was also unavailable over HTTP/3.
This observed pattern suggests that the corresponding IP endpoints are blocked: When the Great Firewall detects a blacklisted IP address it seems to block the connection no matter whether the request used TCP or QUIC.
HTTPSHTTP/3Figure 1:Failure rates of hosts tried over HTTPS vs. HTTP/3. AS45090. Endpoints that fail during the TCP handshake when using HTTPS also fail over HTTP/3. Hosts that are blocked with TCP/TLS-specific methods stay available over HTTP/3.
Follow-up measurements with quicping support this assumption: Attempting to ping the unavailable HTTP/3 hosts with quicping failed in nearly all cases which shows that the censorship is independent from the announced QUIC version and not based on any TLS feature in the handshake. Given the correspondence with failing TCP handshakes, it is most likely that the IP endpoints are blocked.
HTTP/3quicpingFigure 2:Failure rates of hosts tried over HTTP/3 vs. pinged with quicping. AS45090. Hosts that time out during an HTTP/3 request do not respond to a QUIC Ping packet either. Thus, the filtering of QUIC connections is not based on TLS properties negotiated in the handshake.
Figure 2:The results consistency of the hosts between multiple measurements was high which means that hosts were either always blocked or always available. I define the result consistency as the percentage of the most frequently encountered measurement result out of all measurements directed at this host.
China applies IP blocking which likely causes the TCP handshake timeouts when using HTTPS. Since both TCP and QUIC run over IP, IP-blocklisted hosts are not available via both protocols.
These findings show that there was no development in regards to HTTP/3 censorship in China since last year (Elmenhorst et al. 2021). A possible explanation: The censor is not motivated to censor QUIC specifically, since browsers mostly use TCP to explore HTTP/3 support anyways which means that it is enough to block HTTP(S).
I have collected HTTP/3 censorship measurements on a VPS connected to AS45090 repeatedly (21 times) between 14.01. and 21.02.2022. The test list had around 300 entries and The analysis of the measurements suggests that the Chinese firewall does not explicitly handle QUIC traffic but HTTP/3 traffic is nevertheless impaired.
Not all websites that were blocked over HTTPS were also blocked over HTTP/3. The result figure shows that the Great Firewall uses different methods to block HTTPS connections. Different censorship methods cause different failure types when attempting to connect.
To around 24% of tested websites, not even the TCP handshake could be completed and the connection attempt timed out in the first roundtrip. The same set of websites was also unavailable over HTTP/3. This observed pattern suggests that the corresponding IP endpoints are blocked: When the Great Firewall detects a blacklisted IP address it seems to block the connection no matter whether the request used TCP or QUIC.
HTTPS HTTP/3 Figure 1: Failure rates of hosts tried over HTTPS vs. HTTP/3. AS45090. Endpoints that fail during the TCP handshake when using HTTPS also fail over HTTP/3. Hosts that are blocked with TCP/TLS-specific methods stay available over HTTP/3.
Follow-up measurements with quicping support this assumption: Attempting to ping the unavailable HTTP/3 hosts with quicping failed in nearly all cases which shows that the censorship is independent from the announced QUIC version and not based on any TLS feature in the handshake. Given the correspondence with failing TCP handshakes, it is most likely that the IP endpoints are blocked. HTTP/3 quicping Figure 2: Failure rates of hosts tried over HTTP/3 vs. pinged with quicping. AS45090. Hosts that time out during an HTTP/3 request do not respond to a QUIC Ping packet either. Thus, the filtering of QUIC connections is not based on TLS properties negotiated in the handshake.
Figure 2: The results consistency of the hosts between multiple measurements was high which means that hosts were either always blocked or always available. I define the result consistency as the percentage of the most frequently encountered measurement result out of all measurements directed at this host.
China applies IP blocking which likely causes the TCP handshake timeouts when using HTTPS. Since both TCP and QUIC run over IP, IP-blocklisted hosts are not available via both protocols. These findings show that there was no development in regards to HTTP/3 censorship in China since last year (Elmenhorst et al. 2021). A possible explanation: The censor is not motivated to censor QUIC specifically, since browsers mostly use TCP to explore HTTP/3 support anyways which means that it is enough to block HTTP(S).