tango
May 2, 2022, 4:52pm
29
Kathrin Elmenhorst, an author of “Web Censorship Measurements of HTTP/3 over QUIC” , has a repository with further tests of QUIC blocking, derived from OONI measurements. One thread of investigation is about Russia, and it has some interesting observations.
opened 12:00PM - 29 Mar 22 UTC
Reports suggest that Russia started to block HTTP/3 traffic nationwide on the 4t… h of March 2022. With the increasing restrictions of media since the beginning of the invasion of Ukraine, [internet censorship in Russia is rapidly changing and getting more restrictive](https://ooni.org/post/2022-russia-blocks-amid-ru-ua-conflict/). In this context, people reported that HTTP/3 doesn't work anymore.
* https://ntc.party/t/http-3-quic/1823/
* https://github.com/net4people/bbs/issues/108
We were able to run 2 rounds of HTTP/3 measurements in a mobile (PJSC MegaFon Yota, AS31213), and a landline network (PJSC Rostelecom, AS12389) in Russia, on March 27 and 31. The test list contained 11 websites, i.e. 11 HTTPS endpoints and 11 HTTP/3 endpoints were measured.
____
| abbreviation | failure type |
|:------|:-------|
| QUIC-hs-to | QUIC handshake timeout |
| conn-reset | connection reset: TCP RST terminated connection during TLS handshake |
_____
## Yota, AS31213
**HTTPS** **HTTP/3**
**Figure 1:** Failure rates of hosts tried over HTTPS vs. HTTP/3. AS31213.
| _experiment<br/> destination IP<br/> SNI<br/> QUIC version_ | HTTPS<br/>target<br/>target<br/>- | h3 urlgetter<br/>target<br/>target<br/>1 | h3 urlgetter<br/>target<br/>`vk.com`<br/>1 | h3 urlgetter<br/>`vk.com`<br/>target<br/>1 | quicping<br/>target IP<br/>-<br/>[0xbabababa](https://www.rfc-editor.org/rfc/rfc9000.html#versions) |
|:----|:----|:---|:---|:---|:---|
| quic.nginx.org, 35.214.218.230 | ✔️| ❌ | ❌ | ✔️| ✔️|
| cloudflare-quic.com, 172.67.9.235 | ✔️ | ❌ | ❌ | ✔️ | ✔️|
| cloudflare-quic.com, 104.22.9.38 | ✔️ |❌ | ❌ | ✔️| ✔️|
| example.com, 93.184.216.34 _(n = 1)_ | ✔️ |❌ | ❌ | ✔️| ✔️|
| vk.com, 93.186.225.208 | ✔️ | ✔️| - | - | ✔️ |
| vk.com, 87.240.139.194 | ✔️ | ✔️ | - | - | ✔️ |
| navalny.com, 188.114.97.7 |❌ |❌ | ❌ | ❌ | ✔️|
| navalny.com, 188.114.96.7 |❌ | ❌ | ❌ | ❌ | ✔️|
| ww<span>w.facebook.com</span>, 157.240.210.35 |❌ |❌ | ❌ | ❌ | ✔️|
| censor.net, 104.22.72.106|❌| ❌ | ❌ | ❌ | ✔️|
| censor.net, 172.67.42.195|❌| ❌ | ❌ | ❌ | ✔️|
| ww<span>w.instagram.com</span>, 157.240.210.174 |❌ |❌ | ❌ | ❌ | ✔️|
**Table 1** Summary of the results.
### HTTP/3 overblocking
The second column of Table 1 shows that all tested websites, except for `vk.com` were blocked over HTTP/3. The first column shows that only 4 websites (6 endpoints) were blocked over HTTPS. This observation is consistent with reports saying that [all foreign websites would be blocked over HTTP/3](https://ntc.party/t/http-3-quic/1823/).
### Immediate timeouts
HTTP/3 blocking appears as timeouts during the QUIC handshake. The timeout always occurs during the very first roundtrip, i.e. the client never receives any response from the server and doesn't read a single byte.
### quicping works
[quicping](https://github.com/ooni/spec/blob/master/nettests/ts-031-quicping.md) works in all measured cases which means that the blocking method is more fine grained than just blocking UDP endpoints (see the fifth column). Explanation: **If** the UDP endpoint was blocked, quicping (which only elicits one roundtrip) should also be affected by the blocking because the blocking of HTTP/3 traffic happens during the very first roundtrip.
So why is quicping not impaired? Most likely, quicping packets pass the filter because they do not have the most commonly used QUIC version (`1`). Instead, they carry special version strings which are [reserved for version negotiation](https://www.rfc-editor.org/rfc/rfc9000.html#versions). Supporting this consideration, users in Russia have experienced that HTTP/3 works in some networks when they [disabled QUIC version 1 and used QUIC version draft-29 instead](https://ntc.party/t/http-3-quic/1823/12).
### SNI blocking (?)
We measured all failed endpoints again, this time with the SNI set to `vk.com` (see the third column). Blocked endpoints remain blocked when using an allowed SNI. In contrast, users from other networks in Russia have [reported](https://ntc.party/t/http-3-quic/1823/) that blocked hosts become available when using a fake SNI which shows that HTTP/3 blocking varies between ISPs.
Lastly, we used the domain names of the blocked HTTP/3 hosts as SNI in requests to `vk.com` (see the fourth column). Unexpectedly, `vk.com` was suddenly unavailable when using one of the following blocked domain names as SNI: `navalny.com, www.instagram.com, censor.net, www.facebook.com` - which is precisely the set of hosts that are also blocked over HTTPS. This indicates that certain SNIs trigger blocking and that the censor parses the Initial QUIC packet in order to inspect the SNI. However, since using a fake SNI is not enough to evade blocking in Yota's network, there is probably an additional layer of censorship which drops packets to unwanted destination endpoints regardless of the SNI.
### QUIC version filter as an indication for DPI
QUIC uses Initial encryption which means that Initial packets in the handshake are already encrypted. While this is better than no encryption, it is only a weak protection because the keys can be derived from the connection IDs and the used QUIC version, so an observer of the connection can decrypt Initial packets.
It's possible that censors in Russia use a shortcut to decrypt and parse QUIC Initials by assuming that most traffic is using QUIC version 1. When they apply the decryption algorithm to a QUIC packet of version draft-29 rather than version 1, the decryption fails. This would explain the observation that `draft-29` packets do not trigger the filter and that quicping works.
### Blocking scenario
A possible blocking scenario which would explain the above described observations is the following:
- The ISP manages a blacklist of SNIs. Given the measurements, we assume that at least `navalny.com, www.instagram.com, censor.net, www.facebook.com` are on the blacklist.
- All HTTP/3 requests with version 1 are null routed. Either, there is a whitelist to this rule, excluding the IP endpoints of at least `vk.com` from the blocking, or, this null routing is only applied to international network traffic.
- There is a second filter inspecting the SNI which seems to be applied to all HTTP/3 traffic (national and international): If the SNI of a given packet is on the blacklist, it cannot pass the filter.
## Rostelecom, AS12389
**HTTPS** **HTTP/3**
**Figure 2:** Failure rates of hosts tried over HTTPS vs. HTTP/3. AS12389.
In particular, on Yota (AS 31213), there appears to be a two-layer filter. One layer blocks all QUIC version 1, except to specific servers; and a second layer blocks QUIC version 1 with with specific SNI values, no matter the server. This is interesting because the second layer means they are decrypting the initial packet protection on the packet containing the Client Hello.
The evidence for this comes from observing what happens when accessing different servers using different SNI values.
condition
result
Access foreign server with correct SNI
blocked
Access foreign server with vk.com SNI
blocked
Access vk.com server with vk.com SNI
works
Access vk.com server with www.facebook.com SNI
blocked