Ограничение HTTP/3 (QUIC)

bolvan · March 26, 2022, 1:52pm

Есть еще одна мысль. Недавно такая проблема вскрылась.
Если в linux настроен сложный policy routing. Несколько аплинков, таблиц маршрутизации, ip rule , основанные на source address, то пакеты, высланные через raw socket-ы могут уходить не с того интерфейса. Что от nfqws, что от nping. При этом обычные пакеты уходят нормально.
Если это ваш случай, то надо убедиться, что пакеты идут действительно в нужный интерфейс и правильно заменяется source адрес , если используется NAT.
Пока что самое эффективное лечение этой ситуации - вносить ip rule, базированные на fwmark, который выставляет nfqws

Elevator · April 15, 2022, 11:29am

Skynet, СПб
Блочится http3 до инстаграмма и фейсбука, но до гугла пропускает. Похоже стали расшифровывать заголовки.
Причем по http2 пропускает тоже. К слову у skynet нет dpi, блок идет на транзитном провайдере, скорее всего МТС

http3 до инсты

./curl -4Iv -m 5 --http3 https://instagram.com
*   Trying 31.13.72.174:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* Connect socket 5 over QUIC to 31.13.72.174:443
* Sent QUIC client Initial, ALPN: h3,h3-29,h3-28,h3-27
* After 2493ms connect time, move on!
* connect to 31.13.72.174 port 443 failed: No error
* Failed to connect to instagram.com port 443 after 2507 ms: Couldn't connect to server
* Closing connection 0
curl: (28) Failed to connect to instagram.com port 443 after 2507 ms: Couldn't connect to server

http3 до инсты через vpn

./curl -4Iv -m 5 --http3 https://instagram.com
*   Trying 31.13.72.174:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* Connect socket 5 over QUIC to 31.13.72.174:443
* Sent QUIC client Initial, ALPN: h3,h3-29,h3-28,h3-27
*  subjectAltName: host "instagram.com" matched cert's "instagram.com"
* Verified certificate just fine
* Connected to instagram.com () port 443 (#0)
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: instagram.com]
* h2h3 [user-agent: curl/7.83.0-DEV]
* h2h3 [accept: */*]
* Using HTTP/3 Stream ID: 0 (easy handle 0x560fda7c27d0)
> HEAD / HTTP/3
> Host: instagram.com
> user-agent: curl/7.83.0-DEV
> accept: */*
>
< HTTP/3 405
HTTP/3 405

http2 до инсты

./curl -4Iv -m 5 --http2 https://instagram.com
*   Trying 31.13.72.174:443...
* Connected to instagram.com (31.13.72.174) port 443 (#0)
* ALPN: offers http/1.1
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN: server accepted http/1.1

http3 до гугла

./curl -4Iv -m 5 --http3 https://google.com
*   Trying 64.233.162.100:443...
*  CAfile: /etc/ssl/certs/ca-certificates.crt
*  CApath: none
* Connect socket 5 over QUIC to 64.233.162.100:443
* Sent QUIC client Initial, ALPN: h3,h3-29,h3-28,h3-27
*  subjectAltName: host "google.com" matched cert's "google.com"
* Verified certificate just fine
* Connected to google.com () port 443 (#0)
* h2h3 [:method: HEAD]
* h2h3 [:path: /]
* h2h3 [:scheme: https]
* h2h3 [:authority: google.com]
* h2h3 [user-agent: curl/7.83.0-DEV]
* h2h3 [accept: */*]
* Using HTTP/3 Stream ID: 0 (easy handle 0x55ae3ae897d0)
> HEAD / HTTP/3
> Host: google.com
> user-agent: curl/7.83.0-DEV
> accept: */*
>
< HTTP/3 301
HTTP/3 301

bolvan · April 15, 2022, 12:16pm

Они писали на форуме, что на разных тарифах разные фильтры стоят. На lite “более сильный DPI”
А может быть от адреса подключения зависит
У меня тариф “Земля”. Все нормально и по v4, и по v6

ValdikSS · April 18, 2022, 2:09pm

Разработчики СКАТ DPI (VAS Experts) выпустили статью о работе с QUIC в своём блоге.

0ka · April 19, 2022, 9:38am

На мобильном мегафоне возможно тоже такое есть: пришлось сменить симку в модеме на сим с другим тарифом, и прошлые настройки zapret перестали работать

tango · May 2, 2022, 4:52pm

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.

github.com/kelmenhorst/quic-censorship

Broad blocking of HTTP/3 traffic in Russia (AS31213, AS12389)

opened 12:00PM - 29 Mar 22 UTC

kelmenhorst

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** ![tcp_quic_AS31213_sankey pdf](https://user-images.githubusercontent.com/45046038/160615226-c2e9968b-f721-4863-877a-dfbbff3c6943.png) **Figure 1:** Failure rates of hosts tried over HTTPS vs. HTTP/3. AS31213. |                                              _experiment                                          destination IP                                                            SNI                                          QUIC version_ | HTTPS target target - | h3 urlgetter target target 1 | h3 urlgetter target `vk.com` 1 | h3 urlgetter `vk.com` target 1 | quicping target IP - [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 |❌ | ❌ | ❌ | ❌ | ✔️| | www.facebook.com, 157.240.210.35 |❌ |❌ | ❌ | ❌ | ✔️| | censor.net, 104.22.72.106|❌| ❌ | ❌ | ❌ | ✔️| | censor.net, 172.67.42.195|❌| ❌ | ❌ | ❌ | ✔️| | www.instagram.com, 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** ![tcp_quic_AS12389_sankey pdf](https://user-images.githubusercontent.com/45046038/160615378-444c7a4d-6a3a-482f-b65a-3defd7220b3e.png) **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

anonymous28 · May 20, 2022, 8:26am

Всё ещё наблюдается?
Сколько пакетов пропускает до блокировки (на картинке сквозная нумерация, число неочевидно)? Сохранились дампы?

bolvan · May 20, 2022, 9:10am

Наблюдается. Там хаотичное поведение. 1-2 сессии могут пройти, 3 - застрять
сколько пакетов я не считал
2 провайдера с ТСПУ дают одинаковое поведение

anonymous28 · May 21, 2022, 7:11am

Система может расшифровать QUIC_V1 и декодировать SNI.

Если ограничиться тестовым набором или соблюдать тестовые размеры, тогда всё работает: SNI декодируется и принимается решение.

Система не может или не хочет достать SNI из пакета, который генерирует Firefox. Возможно дело в размерах (например для структур далее по стеку). Недоступный SNI триггерит блокировку.

ValdikSS · May 21, 2022, 9:07am

Приведите пример пакетов, которые фильтруются и не фильтруются. Выложите pcap’ы или содержимое пакетов.

anonymous28 · May 21, 2022, 9:51am

blocked_firefox.bin (1.3 KB)
works_quictls.bin (1.2 KB)

bolvan · May 21, 2022, 4:22pm

Еще раз проверил на своем провайдере с ТСПУ
Ничего не поменялось. Нет никаких признаков в пользу предположения о декодировании SNI
Действительно, blocked_firefox.bin не проходит, а works_quictls.bin проходит
Оба они от example.com. Подозреваю, там стоит фильтр по некоторым полям или длинам без декодирования, который почему-то не срабатывает в одном случае
Пробовал curl с quiche на свой vps с разными SNI, в том числе vk.com. Ничего не проходит
На белосписочные IP от vk проходит все

./curl -4 --connect-to ::vk.com:443 --http3 https://example.com
curl: (55) SSL: no alternative certificate subject name matches target host name 'example.com'

При пробивании нулевым фейком или пакетом works_quictls.bin идентичное поведение. Хаотичный вис при загрузке сайтов

anonymous28 · May 21, 2022, 4:46pm

facebook_quictls.bin (1.2 KB)
Этот проходит?

ValdikSS · May 21, 2022, 5:25pm

Есть, как минимум, проверка целостности: если изменить хоть один байт в works, то пакет не доходит.
Планирую провести детальные исследования, но если кто-то готов перехватить эстафету, буду только рад.

bolvan · May 21, 2022, 6:52pm

Нет

Значит, все же расшифровывают. В QUIC initial нет никаких контрольных сумм, там используется GCM для аутентификации. Это AEAD шифр. Authenticated Encryption with Associated Data.
Шифрование и аутентификация завязаны в том числе и на нешифрованный хедер, чтобы любое изменение порождало неверный atag. И только полная дешифровка с проверкой atag позволяет отсечь коррупцию в любом байте пакета.
Однако, в остальных предложенных вариантах с этим тоже все в порядке.
Значит они или ориентируются на расшифрованный блок (почему не секут тогда SNI ?), или расшифровывают исключительно для проверки целки, а блочат по другим признакам типа длины
Или может быть в некоторых случаях они могут просечь SNI и блочат по нему, а в других случаях не могут (несовершенство парсера дешифрованного блока ?) и блочат, если IP не в white list
nfqws может распарсить все предложенные бинарики

anonymous28 · May 22, 2022, 5:37am

Воспроизводится для гугла при запросе из curl+quictls, не воспроизводится для запросов из Firefox. (Внешнее различие в размерах пакетов, у Firefox они больше, а гугл-сервер в выборе размера пакетов ориентируется, в том числе, на размер QUIC initial клиента.)

До принятия решения о блокировке проходит в среднем 15 входящих пакетов. (Возможно применяется скользящее окно, поэтому не следует ориентироваться на число пакетов с начала сеанса). Выглядит как статистический анализ? Ложно триггерит правило блокировки psiphon или иного протокола (не связанного с QUIC)?

Не понятно столь широкое применение правила, возможно есть ограничение на адреса/порты/паттерны_inside.

This.

Возможно SNI успешно извлекается везде, а за блокировку по неизвестным паттернам из расшифрованного QUIC initial отвечает другое правило.

Можно сравнить пакеты от Firefox, quictls и quiche.
В коллекцию следует добавить legal_sni_quiche.bin

bolvan · May 22, 2022, 5:53am

Возможно используется отложенный процессинг. Расшифровка - задача потенциально тяжелая
Видим initial, временно разрешаем, отдаем в отдельный поток, когда поток возвращает результат - принимаем решение.
Отдельный поток может ориентироваться на текущую загрузку DPI и отказываться от тяжелых операций при необходимости

anonymous28 · May 22, 2022, 8:20am

Заполнение нулями (наружное) QUIC initial триггерит блокировку. В Firefox такое применяется. В quictls внутренний с финальными 1200 байтами. В quiche – у меня нет данных (не собирается ржавчина).

anonymous28 · May 22, 2022, 6:07pm

Хаотичные зависания могут быть вызваны большими (1400+) QUIC пакетами в середине сеанса, которые триггерят блокировку. В моем случае это был механизм pmtud на QUIC клиенте, после отключения зависаний нет. К проблемам с mtu это не имеет отношения, блокировка по тестируемым парам адреса:порты наблюдается на хопе с ТСПУ.

У Firefox нет механизма pmtud, но он может быть на сервере.

UPD:
Большой размер пакета похоже так не важен, дело в другом.

Есть скрипт, который возможно воспроизводит блокировку.

Активация блокировки:
Запрос, ответ, запрос.
Нет ответа – нет блокировки.
Размер запросов и ответа учитывается, но точно неизвестно.

anonymous29 · May 24, 2022, 8:24am

UPD: Код бредовый. Удалил. Вызывает блокировку потому что нарушает RFC.