In March 2021 we have collected HTTP/3 censorship measurements in Uganda. The tests were run from mobile devices in two different networks: Airtel Uganda (AS37075, 10 repetitions) and MTN (AS20294, 4 repetitions). The test list had 16 hosts.
abbreviation
failure type
TCP-hs-to
TCP handshake timeout
QUIC-hs-to
QUIC handshake timeout
conn-reset
connection reset: TCP RST terminated connection during TLS handshake
conn-refused
connection refused: TCP RST terminated connection after first TCP SYN
conn-to
connection timeout (after handshake)
TLS-hs-err
server-side failure during TLS handshake
ping-to
quicping timed out, i.e. there was no server response to the ping request
In both networks, HTTP/3 endpoints are targeted by censorship.
The blocks in AS20294 and AS37075 have a lot of the same characteristics:
Separate HTTPS and HTTP/3 blocking
Both for HTTPS and HTTP/3 the censors seem to apply multiple different blocking techniques which cause a variety of different failure types when trying to connect to blocked hosts.
Overall, it is very likely that HTTPS and HTTP/3 traffic are handled differently by the censorship system (in contrast to IP endpoint blocking which treats all IP-based traffic the same). A strong indication for this are the conn-refused and conn-reset failures that happen during HTTPS requests: These error types suggest the injection of TCP RST packets which, of course, is only applicable to TCP. Still, these same websites are blocked over QUIC. Since QUIC connections cannot be terminated by TCP RSTs, there needs to be a different mechanism in place to block QUIC.
HTTPSHTTP/3HTTPSHTTP/3Figure 1:Failure rates of hosts tried over HTTPS vs. HTTP/3. Left: AS37075, right: AS2029 (details below).
QUIC connection timeouts
On some days, QUIC connections did not timeout during the handshake but on the working connection. I can think of 2 explanations for this:
a) The censorship system of the ISPs is too slow to interfere immediately during the handshake. This seems unlikely because on other days and. Moreover, such an efficiency issue would be sensitive to different times of day (peak and off-peak traffic volumes) but this sensitivity is not visible in the data.
b) The filter is intentionally only applied to application data. Such an interference could be implemented by keeping state about connections or by applying the filter only to smaller data packets (handshake packets are at least 1200 Bytes).
QUIC Ping
When HTTP/3 transactions time out during the QUIC handshake, these HTTP/3 hosts did also not respond to quicping. This observation indicates that the blocking already happens during the first roundtrip. There is probably no DPI of the payload of the QUIC Initial packet since the blocking also happens with the random payload generated by quicping.
On the other hand, when the blocking only happens after a few roundtrips (conn-to), quicping works (quicping only elicits 1 roundtrip).
HTTP/3quicpingHTTP/3quicpingFigure 2:Failure rates of hosts tried over HTTP/3 vs. pinged with quicping. Left: AS37075, right: AS2029.
No SNI blocking
When changing the SNI to an allowed domain name, the corresponding websites remain blocked.
HTTP/3w/ SNI spoofHTTP/3w/ SNI spoofFigure 3:Failure rates of hosts tried over HTTP/3 vs. HTTP/3 with spoofed SNI. Left: AS37075, right: AS2029.
Temporal variance
There is a rather strong temporal variance of failure types when running HTTPS and HTTP/3 requests in the network of Airtel Uganda (AS37075). The result consistency is low for all measured protocols (HTTPS over TCP, HTTP/3 over QUIC and quicping): Around 50\% of hosts have the same test result in only 80\% or less of measurements.
It's unclear to me why the censorship is this inconsistent. It will take further continuous measurements to find out more about what is going on here.
Figure 4:Cumulative distributions of result consistency, calculated for each host as: no. of measurements with most frequent result / no. of all measurements. Left: AS37075, right: AS20294.
Airtel Uganda, AS37075
HTTPSHTTP/3Figure 5:Failure rates of hosts tried over HTTPS vs. HTTP/3. AS37075.
To each protocol, multiple different blocking methods are applied which cause multiple different error types:
conn-refused and TCP-hs-to indicate that the blocking happened during the TCP handshake (likely no DPI on TLS). These HTTPS error types correspond to QUIC-hs-to failures which also indicate that the blocking happened early on, during the QUIC handshake. While TCP-hs-to and QUIC-hs-to could be caused by the same IP blocking method, this is not true for conn-refused which is caused by an injected TCP RST.
The above described variance of censorship is very striking in AS37075, especially when comparing the measurements from individual, even consecutive, days:
Figure 6:Temporal variance of blocking is the network of Airtel Uganda during March, 3 and March, 15 2022.
MTN Uganda, AS20294
HTTPSHTTP/3Figure 7:Failure rates of hosts tried over HTTPS vs. HTTP/3. AS20294.
For each HTTPS error type, there is a corresponding HTTP/3 error type, i.e. if an HTTPS request failed with the error type A, the corresponding HTTP/3 request to the same URL caused error type B.
Websites that failed over HTTPS with a conn-refused message, where unavailable over HTTP/3 due to a QUIC handshake timeout (QUIC-hs-to). Both error types occur during the first roundtrip. HTTPS conn-reset failures corresponded to HTTP/3 conn-to failures which both indicate that the blocking happened after a few roundtrips.
In March 2021 we have collected HTTP/3 censorship measurements in Uganda. The tests were run from mobile devices in two different networks: Airtel Uganda (AS37075, 10 repetitions) and MTN (AS20294, 4 repetitions). The test list had 16 hosts.
In both networks, HTTP/3 endpoints are targeted by censorship. The blocks in AS20294 and AS37075 have a lot of the same characteristics:
Separate HTTPS and HTTP/3 blocking
Both for HTTPS and HTTP/3 the censors seem to apply multiple different blocking techniques which cause a variety of different failure types when trying to connect to blocked hosts.
Overall, it is very likely that HTTPS and HTTP/3 traffic are handled differently by the censorship system (in contrast to IP endpoint blocking which treats all IP-based traffic the same). A strong indication for this are the conn-refused and conn-reset failures that happen during HTTPS requests: These error types suggest the injection of TCP RST packets which, of course, is only applicable to TCP. Still, these same websites are blocked over QUIC. Since QUIC connections cannot be terminated by TCP RSTs, there needs to be a different mechanism in place to block QUIC.
HTTPS HTTP/3 HTTPS HTTP/3
Figure 1: Failure rates of hosts tried over HTTPS vs. HTTP/3. Left: AS37075, right: AS2029 (details below).
QUIC connection timeouts
On some days, QUIC connections did not timeout during the handshake but on the working connection. I can think of 2 explanations for this:
a) The censorship system of the ISPs is too slow to interfere immediately during the handshake. This seems unlikely because on other days and. Moreover, such an efficiency issue would be sensitive to different times of day (peak and off-peak traffic volumes) but this sensitivity is not visible in the data.
b) The filter is intentionally only applied to application data. Such an interference could be implemented by keeping state about connections or by applying the filter only to smaller data packets (handshake packets are at least 1200 Bytes).
QUIC Ping
When HTTP/3 transactions time out during the QUIC handshake, these HTTP/3 hosts did also not respond to quicping. This observation indicates that the blocking already happens during the first roundtrip. There is probably no DPI of the payload of the QUIC Initial packet since the blocking also happens with the random payload generated by quicping. On the other hand, when the blocking only happens after a few roundtrips (
conn-to), quicping works (quicping only elicits 1 roundtrip).HTTP/3 quicping HTTP/3 quicping
Figure 2: Failure rates of hosts tried over HTTP/3 vs. pinged with quicping. Left: AS37075, right: AS2029.
No SNI blocking
When changing the SNI to an allowed domain name, the corresponding websites remain blocked.
HTTP/3 w/ SNI spoof HTTP/3 w/ SNI spoof
Figure 3: Failure rates of hosts tried over HTTP/3 vs. HTTP/3 with spoofed SNI. Left: AS37075, right: AS2029.
Temporal variance
There is a rather strong temporal variance of failure types when running HTTPS and HTTP/3 requests in the network of Airtel Uganda (AS37075). The result consistency is low for all measured protocols (HTTPS over TCP, HTTP/3 over QUIC and quicping): Around 50\% of hosts have the same test result in only 80\% or less of measurements. It's unclear to me why the censorship is this inconsistent. It will take further continuous measurements to find out more about what is going on here.
Airtel Uganda, AS37075
HTTPS HTTP/3
Figure 5: Failure rates of hosts tried over HTTPS vs. HTTP/3. AS37075.
To each protocol, multiple different blocking methods are applied which cause multiple different error types:
conn-refusedandTCP-hs-toindicate that the blocking happened during the TCP handshake (likely no DPI on TLS). These HTTPS error types correspond toQUIC-hs-tofailures which also indicate that the blocking happened early on, during the QUIC handshake. WhileTCP-hs-toandQUIC-hs-tocould be caused by the same IP blocking method, this is not true forconn-refusedwhich is caused by an injected TCP RST.The above described variance of censorship is very striking in AS37075, especially when comparing the measurements from individual, even consecutive, days:
Figure 6: Temporal variance of blocking is the network of Airtel Uganda during March, 3 and March, 15 2022.
MTN Uganda, AS20294
HTTPS HTTP/3
Figure 7: Failure rates of hosts tried over HTTPS vs. HTTP/3. AS20294.
For each HTTPS error type, there is a corresponding HTTP/3 error type, i.e. if an HTTPS request failed with the error type A, the corresponding HTTP/3 request to the same URL caused error type B. Websites that failed over HTTPS with a
conn-refusedmessage, where unavailable over HTTP/3 due to a QUIC handshake timeout (QUIC-hs-to). Both error types occur during the first roundtrip. HTTPSconn-resetfailures corresponded to HTTP/3conn-tofailures which both indicate that the blocking happened after a few roundtrips.