I have discovered seemingly systematic HTTP/3 blocking in AS133694. AS133694 is downstream from an ISP belonging to previously government-owned ISP Tata Communications (AS4755). The measurements were taken using a VPN, and the input list of 226 HTTPS and 226 HTTP/3 endpoints was tested 8 times between the 21st and 25th of February.
abbreviation
failure type
QUIC-hs-to
QUIC handshake timeout
EOF-err
End-Of-File error, connection was closed early
HTTPSHTTP/3
Nearly all requests that were blocked over HTTPS were also blocked over HTTP/3. In fact, more requests failed over HTTP/3 than HTTPS so there is some over-blocking of QUIC traffic.
HTTPS requests to unwanted hosts terminate after the TCP connect handshake, during the TLS handshake, and the client receives an End-of-File error. The EOF-err causes the TCP connection to terminate immediately.
The HTTP/3 blocking occurs as a QUIC handshake timeout failure and it is already applied during the very first roundtrip, which means that the client does not receive any response from the server (0 bytes read). Since the QUIC client re-transmits the Initial packets, it takes several seconds (quic-go has a default handshake idle timeout of 5 seconds) until the client quits. Thus, the censor has to continue blocking every single retransmit packet until the client gives up.
Inconsistency
QUIC blocking was, in comparison to HTTPS, rather unstable which means that usually blocked HTTP/3 hosts were sometimes, randomly it seems, unblocked.
No SNI blocking
We changed the SNI in the TLS ClientHello to an allowed domain and measured the HTTP/3 hosts again: There is no difference in the results. While some requests were suddenly successful, this was in the scope of the general inconsistency of HTTP/3 blocking described above. Additionally, when we measured uncensored endpoints and changed the SNI to the names of censored hosts, the requests were successful 100% of the time. It's therefore safe to say that there is no parsing of the SNI in HTTP/3 traffic.
UDP endpoint blocking
When HTTP/3 fails, quicping also fails (even though quicping results do have the same level of inconsistency as HTTP/3 results).
Since HTTPS requests to blocked hosts do not timeout but are actively blocked (EOF-err), the two protocols are most likely handled differently by the censor. Thus, IP blocking is not probable.
If IP blocking is not in place the failures of quicping can best be explained by UDP endpoint blocking targeting HTTP/3 traffic.
We re-ran follow-up measurements after all HTTP/3 requests that failed:
I have discovered seemingly systematic HTTP/3 blocking in AS133694. AS133694 is downstream from an ISP belonging to previously government-owned ISP Tata Communications (AS4755). The measurements were taken using a VPN, and the input list of 226 HTTPS and 226 HTTP/3 endpoints was tested 8 times between the 21st and 25th of February.
HTTPS HTTP/3
Nearly all requests that were blocked over HTTPS were also blocked over HTTP/3. In fact, more requests failed over HTTP/3 than HTTPS so there is some over-blocking of QUIC traffic.
HTTPS requests to unwanted hosts terminate after the TCP connect handshake, during the TLS handshake, and the client receives an End-of-File error. The
EOF-errcauses the TCP connection to terminate immediately.The HTTP/3 blocking occurs as a QUIC handshake timeout failure and it is already applied during the very first roundtrip, which means that the client does not receive any response from the server (0 bytes read). Since the QUIC client re-transmits the Initial packets, it takes several seconds (quic-go has a default handshake idle timeout of 5 seconds) until the client quits. Thus, the censor has to continue blocking every single retransmit packet until the client gives up.
Inconsistency
QUIC blocking was, in comparison to HTTPS, rather unstable which means that usually blocked HTTP/3 hosts were sometimes, randomly it seems, unblocked.
No SNI blocking
We changed the SNI in the TLS ClientHello to an allowed domain and measured the HTTP/3 hosts again: There is no difference in the results. While some requests were suddenly successful, this was in the scope of the general inconsistency of HTTP/3 blocking described above. Additionally, when we measured uncensored endpoints and changed the SNI to the names of censored hosts, the requests were successful 100% of the time. It's therefore safe to say that there is no parsing of the SNI in HTTP/3 traffic.
UDP endpoint blocking
When HTTP/3 fails, quicping also fails (even though quicping results do have the same level of inconsistency as HTTP/3 results). Since HTTPS requests to blocked hosts do not timeout but are actively blocked (
EOF-err), the two protocols are most likely handled differently by the censor. Thus, IP blocking is not probable. If IP blocking is not in place the failures of quicping can best be explained by UDP endpoint blocking targeting HTTP/3 traffic.destination
SNI
QUIC version
target
uncensored
1
uncensored
target
1
target IP
-
0xbabababa
✔️ 15.9%
✔️ 99.7%
✔️ 19.3%